Date: Mon, 24 Apr 2023 15:05:16 -0600 From: Warner Losh <imp@bsdimp.com> To: Mark Millard <marklmi@yahoo.com> Cc: "Simon J. Gerraty" <sjg@juniper.net>, 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: <CANCZdfoZiUMuCMzoMMHkjEn_0YYjpj1q5WtbcSP6xLyy2OawVQ@mail.gmail.com> In-Reply-To: <F264E524-FC65-41D2-9CDC-CF3E9CC512BE@yahoo.com> References: <5B26AB25-075F-4630-86C1-886E6082CDCF.ref@yahoo.com> <5B26AB25-075F-4630-86C1-886E6082CDCF@yahoo.com> <90353.1682307584@kaos.jnpr.net> <CANCZdfq=%2Br9kzg-Uge4JBDk-=xpHOgGoaov1-v2SO8yZG9kFcA@mail.gmail.com> <F264E524-FC65-41D2-9CDC-CF3E9CC512BE@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000e2e31b05fa1b5d05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 23, 2023 at 10:22=E2=80=AFPM Mark Millard <marklmi@yahoo.com> w= rote: > [Warner answered my specific question separately. This is about > something else.] > > On Apr 23, 2023, at 20:57, Warner Losh <imp@bsdimp.com> wrote: > > > On Sun, Apr 23, 2023 at 9:40=E2=80=AFPM Simon J. Gerraty <sjg@juniper.n= et> > 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 ru= n > >> a tool on the host to generate something. > >> When trying to build 14.0 on a 13.1 host each of those tools failed wi= th > >> 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. > > For the kernel's vers.c generation, git is used but > does not get a build of its own under buildworld or > buildkernel as far as I know: not a bootstrap or > staged tool. > Correct. The host's git is assumed to always be good and always executing in a sane env. And you can just remove / take git out of the path if you hit problems here= . > > 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. > > git use is not covered by buildworld or kernel-toolchain > staging activities as far as I know. > > Is git the only example of such for things used by buildworld > or buildkernel ? > buildkernel is the only place I know that git is used to get the tip of git branch for messages. I think that reproducible builds omit this. Warner > >> AFAIK the non-DIRDEPS_BUILD build does a separate pass through the tre= e > >> 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 thing= s, > >> ideally those tools would be built in a subdirectory of sh, csh etc, s= o > >> 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). > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > > --000000000000e2e31b05fa1b5d05 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 10:22=E2=80= =AFPM Mark Millard <<a href=3D"mailto:marklmi@yahoo.com">marklmi@yahoo.c= om</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex= ">[Warner answered my specific question separately. This is about<br> something else.]<br> <br> On Apr 23, 2023, at 20:57, Warner Losh <<a href=3D"mailto:imp@bsdimp.com= " target=3D"_blank">imp@bsdimp.com</a>> wrote:<br> <br> > On Sun, Apr 23, 2023 at 9:40=E2=80=AFPM Simon J. Gerraty <<a href= =3D"mailto:sjg@juniper.net" target=3D"_blank">sjg@juniper.net</a>> wrote= :<br> >> Mark Millard <<a href=3D"mailto:marklmi@yahoo.com" target=3D"_b= lank">marklmi@yahoo.com</a>> wrote:<br> >> > I will not get into why, but I executed a git built for 14000= 82<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 "__lib= c_start1@FBSD_1.7"<br> >> <br> >> This is a symptom of trying to run a prog built for target on a ho= st<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 t= o 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 faile= d with<br> >> the above issue until actually built for the host.<br> > <br> > Your path is messed up then. We always run (a copy of) the host's = binaries<br> > for these tools.<br> <br> For the kernel's vers.c generation, git is used but<br> does not get a build of its own under buildworld or<br> buildkernel as far as I know: not a bootstrap or<br> staged tool.<br></blockquote><div><br></div><div>Correct. The host's gi= t is assumed to always be good and always executing in a sane env.</div><di= v>And you can just remove / take git out of the path if you hit problems he= re.</div><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"= > > If you were running the 14 binaries on 13 as part of the<br> > build process, the path is messed up. I'm not surprised for dirdep= <br> > since it doesn't do all the staging activities that buildworld.<br= > <br> git use is not covered by buildworld or kernel-toolchain<br> staging activities as far as I know.<br> <br> Is git the only example of such for things used by buildworld<br> or buildkernel ?<br></blockquote><div><br></div><div>buildkernel is the onl= y place I know that git is used to get the tip of git branch for messages. = I think that reproducible builds omit this.</div><div><br></div><div>Warner= </div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p= x 0px 0px 0.8ex;border-left:1px solid 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> > <br> > Yes and no... We copy the host's tools when we can, and build a ma= tched set of<br> > binary and libraries when the host one isn't good enough. I think = it's a path<br> > issue you are seeing...<br> > <br> > Also, "copy" isn't a physical copy because macos hates c= opied binaries due to security concerns.<br> >=C2=A0 <br> >> <br> >> The DIRDEPS_BUILD uses a pseudo MACHINE "host" to deal w= ith such things,<br> >> ideally those tools would be built in a subdirectory of sh, csh et= c, 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 no= t.<br> > <br> > Yea, buildworld deals with this by creating new binaries and installin= g them in<br> > a special directory, which is somewhat similar (though we always build= <br> > them rather than on demand like dirdep hopes to do). <br> <br> <br> =3D=3D=3D<br> Mark Millard<br> marklmi at <a href=3D"http://yahoo.com" rel=3D"noreferrer" target=3D"_blank= ">yahoo.com</a><br> <br> <br> </blockquote></div></div> --000000000000e2e31b05fa1b5d05--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoZiUMuCMzoMMHkjEn_0YYjpj1q5WtbcSP6xLyy2OawVQ>