ntpd fails on recent -current/arm64
Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, some change in the kernel has made ntpd stop working on my arm64 test box. (My amd64 test box is a couple of days behind so I'm not sure if it's arm-specific). What I've identified so far: * The problem is in the kernel, not userland. * The impact seems to be limited to ntpd (in particular, ntpdate works). * ntpd appears to be correctly exchanging NTP packets with peers. * ntpd is not responding to "ntpq -p" queries * ntp_gettime and ntp_adjtime both return TIME_ERROR to ntptime I've looked through the commits and, beyond much of netinet being roto-tilled, I can't see anything obvious. Is anyone else seeing anything similar? Can anyone suggest where to look next? -- Peter Jeremy signature.asc Description: PGP signature
RE: ntpd fails on recent -current/arm64
Peter Jeremy write on
Date: Sun, 23 Apr 2023 11:47:01 UTC :
> Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed,
I see the problem at main-n262371-72ef722b2a34-dirty (aarch64),
in the middle of your range. So in the smaller range is:
Thu, 20 Apr 2023
. . .
• git: 607bc91d90a3 - main - vmrun.sh: Fix a typo in usage() Mateusz
Piotrowski
• Re: git: 373b95976bce - main - netstat: document that PCB information
can't be read from corefiles tuexen_at_freebsd.org
• git: de1dde5dfea4 - main - network.subr: adjust regex for wlans_x
rc.conf entries Bjoern A. Zeeb
• Re: git: 8dcf3a82c54c - main - libc: Implement bsort(3) a bitonic type of
sorting algorithm. Brooks Davis
• git: 7db7bfe1a7b9 - main - iwlwifi: quieten more compiler warnings Bjoern
A. Zeeb
• git: 35f7fa4ac1ae - main - LinuxKPI: 802.11: improve assertion and tkip
code Bjoern A. Zeeb
• git: fdb987bebddf - main - inpcb: Split PCB hash tables Mark Johnston
• git: 3e98dcb3d574 - main - inpcb: Move inpcb matching logic into separate
functions Mark Johnston
• git: 7b92493ab1d4 - main - inpcb: Avoid inp_cred dereferences in
SMR-protected lookup Mark Johnston
• git: 5fd1a67e885e - main - inpcb: Release the inpcb cred reference before
freeing the structure Mark Johnston
• git: dd9059b3e9a1 - main - makefs: set cd9660 Rock Ridge timestamps for .
and .. Ed Maste
• git: 0df4d8ad7a1b - main - Add jobs.mk to allow for target-jobs Simon J.
Gerraty
• git: d1f4c44aa8af - main - x86: Move i386 ppireg.h to x86 Dmitry Chagin
• git: de4da6cd04bf - main - x86: Move i386 timerreg.h to x86 Dmitry Chagin
• git: 8fe4f8f7a75f - main - Fix building host tools for host Simon J.
Gerraty
• git: bb8e8e230d94 - main - Revert "libc: Implement bsort(3) a bitonic
type of sorting algorithm." Hans Petter Selasky
• Re: git: bb8e8e230d94 - main - Revert "libc: Implement bsort(3) a bitonic
type of sorting algorithm." Jessica Clarke
• Re: git: bb8e8e230d94 - main - Revert "libc: Implement bsort(3) a bitonic
type of sorting algorithm." Brooks Davis
• git: 1a149d65baed - main - dtrace: get rid of uchar_t types Mark Johnston
• git: 080e56a6c98c - main - dtrace: expose dtrace_instr_size() to userland
and implement it for riscv Mark Johnston
• git: 75081b9ed8e6 - main - dtrace: use dtrace_instr_size() in the riscv
dtrace_subr.c Mark Johnston
• git: 1fef7abdc76b - main - dtrace: add register bindings for RISC-V Mark
Johnston
• Re: git: bb8e8e230d94 - main - Revert "libc: Implement bsort(3) a bitonic
type of sorting algorithm." Hans Petter Selasky
• Re: git: bb8e8e230d94 - main - Revert "libc: Implement bsort(3) a bitonic
type of sorting algorithm." Hans Petter Selasky
• git: 47e888f8363d - main - Remove a few more references to riscv64sf.
John Baldwin
• git: 048606bec11f - main - perfmon(4): Use a C89 function definition for
a SYSINIT. John Baldwin
• git: bf043855213c - main - arm: Use C89 function declaration for
db_read_bytes. John Baldwin
• Re: git: c1e813d12309 - main - hwpmc: Correct selection of Intel fixed
counters. Alexander Motin
• git: 72ef722b2a34 - main - dpaa2: add console support for FDT based
systems Bjoern A. Zeeb
. . .
> some change in the kernel has made ntpd stop working on my arm64 test
> box. (My amd64 test box is a couple of days behind so I'm not sure if
> it's arm-specific).
>
> What I've identified so far:
> * The problem is in the kernel, not userland.
See below for the truss output oddity of doing
2 sendto's (no recvfrom) instead of sendto then
recvfrom. From an machine with an older context
that works:
. . .
socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) = 3 (0x3)
connect(3,{ AF_INET 127.0.0.1:123 },16) = 0 (0x0)
sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) = 12 (0xc)
select(4,{ 3 },0x0,0x0,{ 5.00 }) = 1 (0x1)
recvfrom(3,"\^V\M^A\0\^A\^F\^X\0\0\0\0\0\^X"...,516,0,NULL,0x0) = 36 (0x24)
fstat(1,{ mode=crw--w ,inode=138,size=0,blksize=4096 }) = 0 (0x0)
ioctl(1,TIOCGETA,0x735a71d98c58) = 0 (0x0)
>
> * The impact seems to be limited to ntpd (in particular, ntpdate works).
> * ntpd appears to be correctly exchanging NTP packets with peers.
> * ntpd is not responding to "ntpq -p" queries
I noticed that "ntpq -c as" end up doing:
. . .
open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 3 (0x3)
fstat(3,{ mode=-rw-r--r-- ,inode=14579,size=72600,blksize=72704 }) = 0 (0x0)
lseek(3,0x0,SEEK_CUR) = 0 (0x0)
lseek(3,0x0,SEEK_SET) = 0 (0x0)
read(3,"#\n# Network services, Internet "...,72704) = 72600 (0x11b98)
close(3) = 0 (0x0)
socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) = 3 (0x3)
connect(3,{ AF_INET 127.0.0.1:123 },16) = 0 (0x0)
sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) = 12 (0xc)
select(4,{ 3 },0x0,0x0,{ 5.00 }) = 0 (0x0)
sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) = 12 (0xc)
select(4,{ 3 },0x0,0x0,{ 5.00 }) = 0 (0x0)
localhost: timed out, nothing received
write(2,"localho
Re: ntpd fails on recent -current/arm64
On 23 Apr 2023, at 6:47, Peter Jeremy wrote: > Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, > some change in the kernel has made ntpd stop working on my arm64 test > box. (My amd64 test box is a couple of days behind so I'm not sure if > it's arm-specific). > > What I've identified so far: > * The problem is in the kernel, not userland. > * The impact seems to be limited to ntpd (in particular, ntpdate works). > * ntpd appears to be correctly exchanging NTP packets with peers. > * ntpd is not responding to "ntpq -p" queries > * ntp_gettime and ntp_adjtime both return TIME_ERROR to ntptime I updated an amd64 system yesterday, and it is broken too. > I've looked through the commits and, beyond much of netinet being > roto-tilled, I can't see anything obvious. The netinet changes seem likely to be the culprit. ntpd seems to be receiving the requests but isn’t responding. Trivial testing indicates that named is working, so UDP isn’t completely broken. > Is anyone else seeing anything similar? Can anyone suggest where > to look next? Mark may have an idea. Finding a simpler example would be helpful, but I’m not sure what we’re looking for. Mike
Re: ntpd fails on recent -current/arm64
On Apr 23, 2023, at 05:29, Mark Millard wrote:
> Peter Jeremy write on
> Date: Sun, 23 Apr 2023 11:47:01 UTC :
>
>> Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed,
>
> I see the problem at main-n262371-72ef722b2a34-dirty (aarch64),
> in the middle of your range. So in the smaller range is:
>
> Thu, 20 Apr 2023
> . . .
>• git: 607bc91d90a3 - main - vmrun.sh: Fix a typo in usage() Mateusz
> Piotrowski
>• Re: git: 373b95976bce - main - netstat: document that PCB information
> can't be read from corefiles tuexen_at_freebsd.org
>• git: de1dde5dfea4 - main - network.subr: adjust regex for wlans_x
> rc.conf entries Bjoern A. Zeeb
>• Re: git: 8dcf3a82c54c - main - libc: Implement bsort(3) a bitonic type
> of sorting algorithm. Brooks Davis
>• git: 7db7bfe1a7b9 - main - iwlwifi: quieten more compiler warnings
> Bjoern A. Zeeb
>• git: 35f7fa4ac1ae - main - LinuxKPI: 802.11: improve assertion and tkip
> code Bjoern A. Zeeb
>• git: fdb987bebddf - main - inpcb: Split PCB hash tables Mark Johnston
>• git: 3e98dcb3d574 - main - inpcb: Move inpcb matching logic into
> separate functions Mark Johnston
>• git: 7b92493ab1d4 - main - inpcb: Avoid inp_cred dereferences in
> SMR-protected lookup Mark Johnston
>• git: 5fd1a67e885e - main - inpcb: Release the inpcb cred reference
> before freeing the structure Mark Johnston
>• git: dd9059b3e9a1 - main - makefs: set cd9660 Rock Ridge timestamps for
> . and .. Ed Maste
>• git: 0df4d8ad7a1b - main - Add jobs.mk to allow for target-jobs Simon J.
> Gerraty
>• git: d1f4c44aa8af - main - x86: Move i386 ppireg.h to x86 Dmitry Chagin
>• git: de4da6cd04bf - main - x86: Move i386 timerreg.h to x86 Dmitry
> Chagin
>• git: 8fe4f8f7a75f - main - Fix building host tools for host Simon J.
> Gerraty
>• git: bb8e8e230d94 - main - Revert "libc: Implement bsort(3) a bitonic
> type of sorting algorithm." Hans Petter Selasky
>• Re: git: bb8e8e230d94 - main - Revert "libc: Implement bsort(3) a
> bitonic type of sorting algorithm." Jessica Clarke
>• Re: git: bb8e8e230d94 - main - Revert "libc: Implement bsort(3) a
> bitonic type of sorting algorithm." Brooks Davis
>• git: 1a149d65baed - main - dtrace: get rid of uchar_t types Mark
> Johnston
>• git: 080e56a6c98c - main - dtrace: expose dtrace_instr_size() to
> userland and implement it for riscv Mark Johnston
>• git: 75081b9ed8e6 - main - dtrace: use dtrace_instr_size() in the riscv
> dtrace_subr.c Mark Johnston
>• git: 1fef7abdc76b - main - dtrace: add register bindings for RISC-V Mark
> Johnston
>• Re: git: bb8e8e230d94 - main - Revert "libc: Implement bsort(3) a
> bitonic type of sorting algorithm." Hans Petter Selasky
>• Re: git: bb8e8e230d94 - main - Revert "libc: Implement bsort(3) a
> bitonic type of sorting algorithm." Hans Petter Selasky
>• git: 47e888f8363d - main - Remove a few more references to riscv64sf.
> John Baldwin
>• git: 048606bec11f - main - perfmon(4): Use a C89 function definition for
> a SYSINIT. John Baldwin
>• git: bf043855213c - main - arm: Use C89 function declaration for
> db_read_bytes. John Baldwin
>• Re: git: c1e813d12309 - main - hwpmc: Correct selection of Intel fixed
> counters. Alexander Motin
>• git: 72ef722b2a34 - main - dpaa2: add console support for FDT based
> systems Bjoern A. Zeeb
> . . .
>
>> some change in the kernel has made ntpd stop working on my arm64 test
>> box. (My amd64 test box is a couple of days behind so I'm not sure if
>> it's arm-specific).
>>
>> What I've identified so far:
>> * The problem is in the kernel, not userland.
>
> See below for the truss output oddity of doing
> 2 sendto's (no recvfrom) instead of sendto then
> recvfrom. From an machine with an older context
> that works:
>
> . . .
> socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) = 3 (0x3)
> connect(3,{ AF_INET 127.0.0.1:123 },16) = 0 (0x0)
> sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) = 12 (0xc)
> select(4,{ 3 },0x0,0x0,{ 5.00 }) = 1 (0x1)
> recvfrom(3,"\^V\M^A\0\^A\^F\^X\0\0\0\0\0\^X"...,516,0,NULL,0x0) = 36 (0x24)
> fstat(1,{ mode=crw--w ,inode=138,size=0,blksize=4096 }) = 0 (0x0)
> ioctl(1,TIOCGETA,0x735a71d98c58) = 0 (0x0)
>
>>
>> * The impact seems to be limited to ntpd (in particular, ntpdate works).
>> * ntpd appears to be correctly exchanging NTP packets with peers.
>> * ntpd is not responding to "ntpq -p" queries
>
> I noticed that "ntpq -c as" end up doing:
>
> . . .
> open("/etc/services",O_RDONLY|O_CLOEXEC,0666) = 3 (0x3)
> fstat(3,{ mode=-rw-r--r-- ,inode=14579,size=72600,blksize=72704 }) = 0 (0x0)
> lseek(3,0x0,SEEK_CUR) = 0 (0x0)
> lseek(3,0x0,SEEK_SET) = 0 (0x0)
> read(3,"#\n# Network services, Internet "...,72704) = 72600 (0x11b98)
> close(3) = 0 (0x0)
> socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) = 3 (0x3)
> connect(3,{ AF_INET 127.0.0.1:123 },16) = 0 (0x0)
> sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =
Re: ntpd fails on recent -current/arm64
On 4/23/23 07:47, Peter Jeremy wrote: Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, some change in the kernel has made ntpd stop working on my arm64 test box. (My amd64 test box is a couple of days behind so I'm not sure if it's arm-specific). [ .. snip .. ] While I can't suggest a fix, I discovered this workaround until one is found; edit /etc/ntp.conf to include .. interface ignore wildcard interface listen lo0 interface listen em0 .. or whichever interfaces are required on the host, Michael
Re: ntpd fails on recent -current/arm64
On Sun, Apr 23, 2023 at 07:34:45AM -0500, Mike Karels wrote: > On 23 Apr 2023, at 6:47, Peter Jeremy wrote: > > > Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, > > some change in the kernel has made ntpd stop working on my arm64 test > > box. (My amd64 test box is a couple of days behind so I'm not sure if > > it's arm-specific). > > > > What I've identified so far: > > * The problem is in the kernel, not userland. > > * The impact seems to be limited to ntpd (in particular, ntpdate works). > > * ntpd appears to be correctly exchanging NTP packets with peers. > > * ntpd is not responding to "ntpq -p" queries > > * ntp_gettime and ntp_adjtime both return TIME_ERROR to ntptime > > I updated an amd64 system yesterday, and it is broken too. > > > I've looked through the commits and, beyond much of netinet being > > roto-tilled, I can't see anything obvious. > > The netinet changes seem likely to be the culprit. ntpd seems to > be receiving the requests but isn’t responding. Trivial testing > indicates that named is working, so UDP isn’t completely broken. > > > Is anyone else seeing anything similar? Can anyone suggest where > > to look next? > > Mark may have an idea. Finding a simpler example would be helpful, > but I’m not sure what we’re looking for. I can reproduce the problem. A small example would still be useful, so that we can turn it into a regression test case.
Re: ntpd fails on recent -current/arm64
On Sun, Apr 23, 2023 at 09:47:01PM +1000, Peter Jeremy wrote: > Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, > some change in the kernel has made ntpd stop working on my arm64 test > box. (My amd64 test box is a couple of days behind so I'm not sure if > it's arm-specific). > > What I've identified so far: > * The problem is in the kernel, not userland. > * The impact seems to be limited to ntpd (in particular, ntpdate works). > * ntpd appears to be correctly exchanging NTP packets with peers. > * ntpd is not responding to "ntpq -p" queries > * ntp_gettime and ntp_adjtime both return TIME_ERROR to ntptime > > I've looked through the commits and, beyond much of netinet being > roto-tilled, I can't see anything obvious. > > Is anyone else seeing anything similar? Can anyone suggest where > to look next? This patch fixes the problem for me: https://reviews.freebsd.org/D39771
/lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ?
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 ? Just curious about the criteria. Executing newer on older is not my normal type of activity: usually avoided. 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 ?
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
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 ?
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 ?
[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 ?
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
