Date: Sun, 23 Apr 2023 21:22:01 -0700 From: Mark Millard <marklmi@yahoo.com> To: Warner Losh <imp@bsdimp.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: <F264E524-FC65-41D2-9CDC-CF3E9CC512BE@yahoo.com> In-Reply-To: <CANCZdfq=%2Br9kzg-Uge4JBDk-=xpHOgGoaov1-v2SO8yZG9kFcA@mail.gmail.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>
next in thread | previous in thread | raw e-mail | index | archive | help
[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.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 : >> >=20 >> > ld-elf.so.1: /usr/local/bin/git: Undefined symbol = "__libc_start1@FBSD_1.7" >>=20 >> This is a symptom of trying to run a prog built for target on a host >> which is not the same. >>=20 >> I hit this a lot recently while updating Makefile.depend files for >> userland. >>=20 >> 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. >=20 > 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. >=20 > 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... >=20 > Also, "copy" isn't a physical copy because macos hates copied binaries = due to security concerns. > =20 >>=20 >> 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. >=20 > 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).=20 =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F264E524-FC65-41D2-9CDC-CF3E9CC512BE>