Date: Sun, 23 Apr 2023 21:57:06 -0600 From: Warner Losh <imp@bsdimp.com> To: "Simon J. Gerraty" <sjg@juniper.net> Cc: Mark Millard <marklmi@yahoo.com>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, Current FreeBSD <freebsd-current@freebsd.org> Subject: Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ? Message-ID: <CANCZdfq=%2Br9kzg-Uge4JBDk-=xpHOgGoaov1-v2SO8yZG9kFcA@mail.gmail.com> In-Reply-To: <90353.1682307584@kaos.jnpr.net> References: <5B26AB25-075F-4630-86C1-886E6082CDCF.ref@yahoo.com> <5B26AB25-075F-4630-86C1-886E6082CDCF@yahoo.com> <90353.1682307584@kaos.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000cf90b005fa0d0062 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 23, 2023 at 9:40=E2=80=AFPM Simon J. Gerraty <sjg@juniper.net> = wrote: > Mark Millard <marklmi@yahoo.com> wrote: > > I will not get into why, but I executed a git built for 1400082 > > in a 1400081 world context and got what was to me a surprise, > > given that /lib/libc.so.7 is part of 13.2-RELEASE : > > > > ld-elf.so.1: /usr/local/bin/git: Undefined symbol "__libc_start1@FBSD_1= .7 > " > > This is a symptom of trying to run a prog built for target on a host > which is not the same. > > I hit this a lot recently while updating Makefile.depend files for > userland. > > There are a number of makefiles (eg for sh, csh, awk) which need to run > a tool on the host to generate something. > When trying to build 14.0 on a 13.1 host each of those tools failed with > the above issue until actually built for the host. > Your path is messed up then. We always run (a copy of) the host's binaries for these tools. If you were running the 14 binaries on 13 as part of the build process, the path is messed up. I'm not surprised for dirdep since it doesn't do all the staging activities that buildworld. > AFAIK the non-DIRDEPS_BUILD build does a separate pass through the tree > to do the target build-tools to build these things. > Yes and no... We copy the host's tools when we can, and build a matched set of binary and libraries when the host one isn't good enough. I think it's a path issue you are seeing... Also, "copy" isn't a physical copy because macos hates copied binaries due to security concerns. > The DIRDEPS_BUILD uses a pseudo MACHINE "host" to deal with such things, > ideally those tools would be built in a subdirectory of sh, csh etc, so > that one can choose to build only that tool if desired - sometimes you > want to build the app (eg awk) for the host as well but usually not. > Yea, buildworld deals with this by creating new binaries and installing them in a special directory, which is somewhat similar (though we always build them rather than on demand like dirdep hopes to do). Warner --000000000000cf90b005fa0d0062 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Sun, Apr 23, 2023 at 9:40=E2=80=AF= PM Simon J. Gerraty <<a href=3D"mailto:sjg@juniper.net" target=3D"_blank= ">sjg@juniper.net</a>> wrote:<br></div><blockquote class=3D"gmail_quote"= style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= adding-left:1ex">Mark Millard <<a href=3D"mailto:marklmi@yahoo.com" targ= et=3D"_blank">marklmi@yahoo.com</a>> wrote:<br> > I will not get into why, but I executed a git built for 1400082<br> > in a 1400081 world context and got what was to me a surprise,<br> > given that /lib/libc.so.7 is part of 13.2-RELEASE :<br> > <br> > ld-elf.so.1: /usr/local/bin/git: Undefined symbol "__libc_start1@= FBSD_1.7"<br> <br> This is a symptom of trying to run a prog built for target on a host<br> which is not the same.<br> <br> I hit this a lot recently while updating Makefile.depend files for<br> userland.<br> <br> There are a number of makefiles (eg for sh, csh, awk) which need to run<br> a tool on the host to generate something.<br> When trying to build 14.0 on a 13.1 host each of those tools failed with<br= > the above issue until actually built for the host.<br></blockquote><div><br= ></div><div>Your path is messed up then. We always run (a copy of) the host= 's binaries</div><div>for these tools. If you were running the 14 binar= ies on 13 as part of the</div><div>build process, the path is messed up. I&= #39;m not surprised for dirdep</div><div>since it doesn't do all the st= aging activities that buildworld.<br></div><div>=C2=A0<br></div><blockquote= class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so= lid rgb(204,204,204);padding-left:1ex"> AFAIK the non-DIRDEPS_BUILD build does a separate pass through the tree<br> to do the target build-tools to build these things.<br></blockquote><div><b= r></div>Yes and no... We copy the host's tools when we can, and build a= matched set of</div><div class=3D"gmail_quote">binary and libraries when t= he host one isn't good enough. I think it's a path</div><div class= =3D"gmail_quote">issue you are seeing...</div><div class=3D"gmail_quote"><b= r></div><div class=3D"gmail_quote">Also, "copy" isn't a physi= cal copy because macos hates copied binaries due to security concerns.<br><= /div><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote class=3D"gmail= _quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204= ,204);padding-left:1ex"> The DIRDEPS_BUILD uses a pseudo MACHINE "host" to deal with such = things,<br> ideally those tools would be built in a subdirectory of sh, csh etc, so<br> that one can choose to build only that tool if desired - sometimes you<br> want to build the app (eg awk) for the host as well but usually not.<br></b= lockquote><div><br></div><div>Yea, buildworld deals with this by creating n= ew binaries and installing them in</div><div>a special directory, which is = somewhat similar (though we always build</div><div>them rather than on dema= nd like dirdep hopes to do).=C2=A0</div><div><br></div><div>Warner<br></div= ></div></div> --000000000000cf90b005fa0d0062--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfq=%2Br9kzg-Uge4JBDk-=xpHOgGoaov1-v2SO8yZG9kFcA>