Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ?
On Sun, Apr 23, 2023 at 10:22 PM Mark Millard wrote: > [Warner answered my specific question separately. This is about > something else.] > > On Apr 23, 2023, at 20:57, Warner Losh wrote: > > > On Sun, Apr 23, 2023 at 9:40 PM Simon J. Gerraty > wrote: > >> Mark Millard 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. > > 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 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). > > > === > Mark Millard > marklmi at yahoo.com > > >
Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ?
Warner Losh wrote: > > 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. > Your path is messed up then. We always run (a copy of) the host's binaries I wasn't using the targets you are refering to. But the point I was making was that trying to run a target binary on a host which is not the same, will result in the errror observed, and is thus a likely explaination. --sjg
Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ?
[Warner answered my specific question separately. This is about something else.] On Apr 23, 2023, at 20:57, Warner Losh wrote: > On Sun, Apr 23, 2023 at 9:40 PM Simon J. Gerraty wrote: >> Mark Millard 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. 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. > 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 ? >> 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). === Mark Millard marklmi at yahoo.com
Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ?
On Sun, Apr 23, 2023 at 9:09 PM Mark Millard 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" > > Does this mean that a /lib/libc.so.8 is pending? Or do the > criteria for the likes of /lib/libc.so.7 allow for new > symbols over time without a name change, even after a > release contains a /lib/libc.so.7 ? > We offer backwards compatibility in libc (so new libc will work with an old binary) but not forward compatibility (so new binary old libc may not work). This policy allows us to add symbols to libc, but never delete them. It also lets us have new versions of old symbols (like stat). > Just curious about the criteria. Executing newer on older is > not my normal type of activity: usually avoided. > Yea. New binary on old libc isn't supported. Similar rules apply to the kernel, but there's a "window" for forward compat when it impacts the upgrade path. Warner > FYI: Checking 13.2-RELEASE shows it is using /lib/libc.so.7 : > > # uname -apKU > FreeBSD generic 13.2-RELEASE FreeBSD 13.2-RELEASE > releng/13.2-n254617-525ecfdad597 GENERIC arm64 aarch64 1302001 1302001 > > # ldd -a `which git` > /usr/local/bin/git: > libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0 (0x6a226ba02000) > libz.so.6 => /lib/libz.so.6 (0x6a226c8fb000) > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x6a226cc81000) > libthr.so.3 => /lib/libthr.so.3 (0x6a226d429000) > libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000) > /usr/local/lib/libpcre2-8.so.0: > libthr.so.3 => /lib/libthr.so.3 (0x6a226d429000) > libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000) > /lib/libz.so.6: > libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000) > /usr/local/lib/libintl.so.8: > libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000) > /lib/libthr.so.3: > libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000) > > === > Mark Millard > marklmi at yahoo.com > > >
Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ?
On Sun, Apr 23, 2023 at 9:40 PM Simon J. Gerraty wrote: > Mark Millard 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
Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ?
Mark Millard 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. AFAIK the non-DIRDEPS_BUILD build does a separate pass through the tree to do the target build-tools to build these things. 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. --sjg
