On Apr 27, 2025, at 23:50, Michal Meloun <meloun.mic...@gmail.com> wrote:
> On 28.04.2025 0:39, Mark Millard wrote: >> On Apr 27, 2025, at 11:34, Mark Millard <mark...@yahoo.com> wrote: >>> On Apr 27, 2025, at 09:21, Mark Millard <mark...@yahoo.com> wrote: >>> >>>> [I've also dropped mmel@ from the To: list.] >>>> >>>> Why does building lang/gcc14 work on each of: >>>> >>>> 14.1-Release >>>> 14.2-Release >>>> 14.2-Stable >>>> >>>> but not on main [so: 15]? >>> >>> To be more explicit . . . >>> >>> For all the combinations of: >>> >>> FreeBSD 14.2-* vs. main and lang/gcc13 vs. lang/gcc14 >>> >>> the only combination that fails is: >>> >>> FreeBSD main building lang/gcc14 . >>> >>> So changes to both FreeBSD and to lang/gcc* are involved. >>> >>> mell@ noted that -static-libgcc use (and, so, libgcc_eh.a >>> use) in the build of lang/gcc14 is involved, something >>> lang/gcc13 does not use at what is the lang/gcc14 failure >>> point. >>> >>> I've not managed isolate what contributing difference >>> in FreeBSD 14.2 vs. FreeBSD main is also involved. >>> >>>> Only main has armv7 lang/gcc14* build failures >>>> on the official builders. Seems odd if it is just >>>> lang/gcc1[45]* 's problem. >>>> >>>> main gets a failure where the config.log shows >>>> that it found but rejected a hidden symbol: >>>> >>>> configure:3479: /wrkdirs/usr/ports/lang/gcc14/work/.build/./prev-gcc/xgcc >>>> -B/wrkdirs/usr/ports/lang/gcc14/work/.build/./prev-gcc/ >>>> -B/usr/local/armv7-portbld-freebsd15.0/bin/ -B/usr/local/armv7-portbl >>>> d-freebsd15.0/bin/ -B/usr/local/armv7-portbld-freebsd15.0/lib/ -isystem >>>> /usr/local/armv7-portbld-freebsd15.0/include -isystem >>>> /usr/local/armv7-portbld-freebsd15.0/sys-include -fno-checking -o confte >>>> st -g -O2 -fno-checking -gtoggle -mcpu=cortex-a7 -DLIBICONV_PLUG >>>> -static-libstdc++ -static-libgcc conftest.c >&5 >>>> /usr/local/bin/ld: warning: libunwind.o: missing .note.GNU-stack section >>>> implies executable stack >>>> /usr/local/bin/ld: NOTE: This behaviour is deprecated and will be removed >>>> in a future version of the linker >>>> /usr/local/bin/ld: conftest: hidden symbol `__aeabi_unwind_cpp_pr0' in >>>> /wrkdirs/usr/ports/lang/gcc14/work/.build/./prev-gcc/libgcc_eh.a(unwind-arm.o) >>>> is referenced by DSO >>>> /usr/local/bin/ld: final link failed: bad value >>>> collect2: error: ld returned 1 exit status >>>> >>>> Per mmel@: Note the -static-libgcc is involved, >>>> something that only happens for lang/gcc1[45]* . >>>> (This explains lang/gcc13 building on main.) >>>> >>>> Official 14.1R builder success logs include: >>>> >>>> https://pkg-status.freebsd.org/ampere3/data/141releng-armv7-default/a66c1b68c862/logs/gcc14-14.2.0_3.log >>>> >>>> ---Begin OPTIONS List--- >>>> ===> The following configuration options are available for gcc14-14.2.0_3: >>>> GRAPHITE=off: Support for Graphite loop optimizations >>>> ====> Options available for the radio BOOTSTRAP: you can only select none >>>> or one of them >>>> LTO_BOOTSTRAP=off: Build using a full LTO bootstrap >>>> STANDARD_BOOTSTRAP=on: Build using a full bootstrap without LTO >>>> ===> Use 'make config' to modify these settings >>>> ---End OPTIONS List--- >>>> >>>> https://pkg-status.freebsd.org/ampere3/data/141releng-armv7-default/a66c1b68c862/logs/gcc14-devel-14.2.1.s20250308,1.log >>>> >>>> ---Begin OPTIONS List--- >>>> ===> The following configuration options are available for >>>> gcc14-devel-14.2.1.s20250308,1: >>>> GRAPHITE=off: Support for Graphite loop optimizations >>>> ====> Options available for the single BOOTSTRAP: you have to select >>>> exactly one of them >>>> LTO_BOOTSTRAP=off: Build using a full LTO bootstrap >>>> STANDARD_BOOTSTRAP=on: Build using a full bootstrap without LTO >>>> ===> Use 'make config' to modify these settings >>>> ---End OPTIONS List--- >>>> >>>> Note: armv7 has not had much build time in 2025-Apr so far, thus >>>> the lack of 14.2R examples. >>>> >>>> >>>> And local builds via: >>>> >>>> release-armv7 14.2-RELEASE-p2 armv7 pkgbase >>>> 2025-03-13 21:50:17 /usr/local/poudriere/jails/release-armv7 >>>> >>>> [01:58:58] [01] [01:34:53] Finished lang/gcc14 | gcc14-14.2.0_3: Success >>>> >>>> and via: >>>> >>>> official-armv7 14.2-STABLE armv7 pkgbase >>>> 2025-03-13 21:47:04 /usr/local/poudriere/jails/official-armv7 >>>> >>>> [01:53:58] [01] [01:32:13] Finished lang/gcc14 | gcc14-14.2.0_3: Success >>>> >>>> work as well. >>>> >>>> The failing context on main has (involving a grep for >>>> lines of interest): >>>> >>>> File: >>>> /wrkdirs/usr/ports/lang/gcc14/work/.build/prev-gcc/libgcc_eh.a(unwind-arm.o) >>>> 000000f8 00002f1a R_ARM_GOT_BREL 00000c30 __aeabi_unwind_cpp_pr2 >>>> 000000fc 0000301a R_ARM_GOT_BREL 00000c28 __aeabi_unwind_cpp_pr1 >>>> 46: 0000000000000c20 8 FUNC GLOBAL HIDDEN 1 >>>> __aeabi_unwind_cpp_pr0 >>>> 47: 0000000000000c30 8 FUNC WEAK HIDDEN 1 >>>> __aeabi_unwind_cpp_pr2 >>>> 48: 0000000000000c28 8 FUNC WEAK HIDDEN 1 >>>> __aeabi_unwind_cpp_pr1 >>>> >>>> That looks the same as what is install by the working >>>> builds on: >>>> >>>> 14.1-Release >>>> 14.2-Release >>>> 14.2-Stable >>>> >>>> The official build logs show the following also >>>> fail --just on main: >>>> >>>> lang/gcc14-devel >>>> lang/gcc15-devel >>> >> One armv7 FreeBSD 14.2 vs. main difference that I've just noticed is . . . >> armv7 FreeBSD stable/14 based: >> # readelf -a /usr/lib/libgcc_s.so | grep -e '__aeabi_unwind_cpp_pr' -e >> '^File:' | grep -v -e ' R_ARM_NONE ' -e ' UND ' | less >> 0002c568 00001715 R_ARM_GLOB_DAT 000187c4 __aeabi_unwind_cpp_pr2 >> 0002c558 00005715 R_ARM_GLOB_DAT 000184b4 __aeabi_unwind_cpp_pr0 >> 0002c560 00005e15 R_ARM_GLOB_DAT 000187b8 __aeabi_unwind_cpp_pr1 >> 23: 00000000000187c4 12 FUNC GLOBAL DEFAULT 14 >> __aeabi_unwind_cpp_pr2@@GCC_3.5 (8) >> 87: 00000000000184b4 12 FUNC GLOBAL DEFAULT 14 >> __aeabi_unwind_cpp_pr0@@GCC_3.5 (8) >> 94: 00000000000187b8 12 FUNC GLOBAL DEFAULT 14 >> __aeabi_unwind_cpp_pr1@@GCC_3.5 (8) >> armv7 FreeBSD main based: >> # readelf -a /usr/lib/libgcc_s.so | grep -e '__aeabi_unwind_cpp_pr' -e >> '^File:' | grep -v -e ' R_ARM_NONE ' -e ' UND ' | less >> 00028f98 00001515 R_ARM_GLOB_DAT 0001674c __aeabi_unwind_cpp_pr2 >> 00028f88 00005515 R_ARM_GLOB_DAT 00016570 __aeabi_unwind_cpp_pr0 >> 00028f90 00005c15 R_ARM_GLOB_DAT 00016740 __aeabi_unwind_cpp_pr1 >> 21: 000000000001674c 12 FUNC GLOBAL DEFAULT 14 >> __aeabi_unwind_cpp_pr2@@GCC_3.5 (8) >> 85: 0000000000016570 12 FUNC GLOBAL DEFAULT 14 >> __aeabi_unwind_cpp_pr0@@GCC_3.5 (8) >> 92: 0000000000016740 12 FUNC GLOBAL DEFAULT 14 >> __aeabi_unwind_cpp_pr1@@GCC_3.5 (8) >> 256: 0000000000016570 12 FUNC GLOBAL DEFAULT 14 >> __aeabi_unwind_cpp_pr0 >> 273: 0000000000016740 12 FUNC GLOBAL DEFAULT 14 >> __aeabi_unwind_cpp_pr1 >> 326: 000000000001674c 12 FUNC GLOBAL DEFAULT 14 >> __aeabi_unwind_cpp_pr2 >> So main has __aeabi_unwind_cpp_p* symbols without @@GCC_3.5 notation included >> in libgcc_s.so but stable/14 does not have those. > > > 1) gcc uses its own libraries (libgcc*), so the FBSD versions in > /usr/lib are out of scope. I have to use -Wl,-rpath=... to force lang/gcc14 to use some of its own libraries in normal operation. (Context below: stable/14 jail.) The same is true of earlier lang/gcc* going way back. But using lang/gcc14 here . . . # more just_main.cpp int main(void) { return 0; } # g++14 just_main.cpp # ldd -a a.out a.out: libstdc++.so.6 => /usr/local/lib/gcc14/libstdc++.so.6 (0x21200000) libm.so.5 => /lib/libm.so.5 (0x2106e000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x210bd000) libc.so.7 => /lib/libc.so.7 (0x21420000) /usr/local/lib/gcc14/libstdc++.so.6: libm.so.5 => /lib/libm.so.5 (0x2106e000) libc.so.7 => /lib/libc.so.7 (0x21420000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x210bd000) /lib/libm.so.5: libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x210bd000) libc.so.7 => /lib/libc.so.7 (0x21420000) /lib/libgcc_s.so.1: libc.so.7 => /lib/libc.so.7 (0x21420000) Note the /lib/libgcc_s.so.1 use above. May be the configure is careful to avoid that? g++14 -Wl,-rpath=/usr/local/lib/gcc14/ just_main.cpp aarch64PBase armv7 1402504 1402504 # ldd -a a.out a.out: libstdc++.so.6 => /usr/local/lib/gcc14//libstdc++.so.6 (0x21200000) libm.so.5 => /lib/libm.so.5 (0x2106e000) libgcc_s.so.1 => /usr/local/lib/gcc14//libgcc_s.so.1 (0x210c0000) libc.so.7 => /lib/libc.so.7 (0x21420000) /usr/local/lib/gcc14//libstdc++.so.6: libm.so.5 => /lib/libm.so.5 (0x2106e000) libc.so.7 => /lib/libc.so.7 (0x21420000) libgcc_s.so.1 => /usr/local/lib/gcc14//libgcc_s.so.1 (0x210c0000) /lib/libm.so.5: libgcc_s.so.1 => /usr/local/lib/gcc14//libgcc_s.so.1 (0x210c0000) libc.so.7 => /lib/libc.so.7 (0x21420000) /usr/local/lib/gcc14//libgcc_s.so.1: libc.so.7 => /lib/libc.so.7 (0x21420000) Note the /usr/local/lib/gcc14//libgcc_s.so.1 use above --but only for use -f -rpath=... . Note: The above is not armv7 specific. > 2) -static_libgcc forced executable to be linked with (static) libgcc.a so, > not with (shared) libgcc_s.so. Both are taken from the gcc distribution. So > any version of libgcc_s.so has no relevance to our problem. Again, in normal operation lang/gcc14 does not work that way with armv7 FreeBSD: # g++14 -static-libgcc just_main.cpp /usr/local/bin/ld: warning: libunwind.o: missing .note.GNU-stack section implies executable stack /usr/local/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/local/bin/ld: /usr/local/lib/gcc14/gcc/armv7-portbld-freebsd14.2/14.2.0/../../../libstdc++.so: undefined reference to `__aeabi_ldivmod@GCC_3.5' /usr/local/bin/ld: /usr/local/lib/gcc14/gcc/armv7-portbld-freebsd14.2/14.2.0/../../../libstdc++.so: undefined reference to `__aeabi_d2lz@GCC_3.5' /usr/local/bin/ld: /usr/local/lib/gcc14/gcc/armv7-portbld-freebsd14.2/14.2.0/../../../libstdc++.so: undefined reference to `__aeabi_uidivmod@GCC_3.5' /usr/local/bin/ld: /usr/local/lib/gcc14/gcc/armv7-portbld-freebsd14.2/14.2.0/../../../libstdc++.so: undefined reference to `__aeabi_uldivmod@GCC_3.5' /usr/local/bin/ld: /usr/local/lib/gcc14/gcc/armv7-portbld-freebsd14.2/14.2.0/../../../libstdc++.so: undefined reference to `__aeabi_l2d@GCC_3.5' /usr/local/bin/ld: /usr/local/lib/gcc14/gcc/armv7-portbld-freebsd14.2/14.2.0/../../../libstdc++.so: undefined reference to `__aeabi_idivmod@GCC_3.5' /usr/local/bin/ld: /usr/local/lib/gcc14/gcc/armv7-portbld-freebsd14.2/14.2.0/../../../libstdc++.so: undefined reference to `__aeabi_ul2f@GCC_3.5' /usr/local/bin/ld: /usr/local/lib/gcc14/gcc/armv7-portbld-freebsd14.2/14.2.0/../../../libstdc++.so: undefined reference to `__aeabi_ul2d@GCC_3.5' collect2: error: ld returned 1 exit status Note: The above type of result is armv7 specific. The below is not, as I remember. # g++14 -static-libgcc -Wl,-rpath=/usr/local/lib/gcc14/ just_main.cpp /usr/local/bin/ld: warning: libunwind.o: missing .note.GNU-stack section implies executable stack /usr/local/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker # ldd -a a.out a.out: libstdc++.so.6 => /usr/local/lib/gcc14//libstdc++.so.6 (0x21200000) libm.so.5 => /lib/libm.so.5 (0x2106e000) libc.so.7 => /lib/libc.so.7 (0x21420000) /usr/local/lib/gcc14//libstdc++.so.6: libm.so.5 => /lib/libm.so.5 (0x2106e000) libc.so.7 => /lib/libc.so.7 (0x21420000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x210bd000) /lib/libm.so.5: libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x210bd000) libc.so.7 => /lib/libc.so.7 (0x21420000) /lib/libgcc_s.so.1: libc.so.7 => /lib/libc.so.7 (0x21420000) Note the /lib/libgcc_s.so.1 use even with -rpath=... in use. Again, is the configure careful to avoid such? > Again, the root cause of this problem is that libgcc.a (or libgcc_eh.a - I > don't know which is more appropriate in a gcc environment) does not provide > unwinder symbols (__aeabi_unwind_cpp_pr*). Reminder of the configure error message and what it indicates: /usr/local/bin/ld: conftest: hidden symbol `__aeabi_unwind_cpp_pr0' in /wrkdirs/usr/ports/lang/gcc14/work/.build/./prev-gcc/libgcc_eh.a(unwind-arm.o) is referenced by DSO So (given the -static-libgcc usage in configure): ) It is using libgcc_eh.a in the failure context (specifically its unwind-arm.o) ) It is finding the symbol __aeabi_unwind_cpp_pr0 ) The symbol status is "hidden" ) The hidden status leads to the rejection Thus, the reference is of a form that can look in libgcc_eh.a to find a definition but that will not tolerate the hidden status. Also, you also tested that you could make a variation of lang/gcc13 that used -static-libgcc in its build like lang/gcc14 did and you replicated the build failure by doing so, if I understand right. That well isolated what contributes on the lang/gcc* side of things. > The only material supplied by FBSD that is relevant for this issue (shared > libraries) are /lib/libc.so.7 and /lib/libsys.so.7 I'm not sure if that is true vs. just a possibly-should-be-true. See above examples of actual (but normal, simple) link operations and the results for which libgcc_s.so is in use in each case that manages to link. (Standard lang/gcc13 could be used to see such in main [so: 15]. The above 'which libgcc_s.so' behaviors have a very long history for lang/gcc* on FreeBSD.) > On FBSD15, libc does not reference unwinder (see 'readelf -a /lib/libc.so.7 | > grep __aeabi_unwind_cpp_pr), but /lib/libsys.so.7 does it. Note that this > reference looks perfectly legal to me. For explicit reference for armv7 main: # readelf -a /lib/libsys.so.7 | grep __aeabi_unwind_cpp_pr 2: 00000000 0 NOTYPE GLOBAL DEFAULT UND __aeabi_unwind_cpp_pr0 4: 00000000 0 NOTYPE GLOBAL DEFAULT UND __aeabi_unwind_cpp_pr1 (No __aeabi_unwind_cpp_pr2 reference. Is that a problem of itself?) That is certainly is a context specific to main [so: 15]. But I've not figured out if other issues may also currently be contributing/interfering. Even if some other issues are, the specific failure might still be an issue after those other issues are fixed or avoided. I just do not know (yet?). It could well be that the above leads to the use of libgcc_eh.a for -static-libgcc and might reject hidden symbol matches (instead of skipping them and finding no others and reporting that none are found). > If memory serves me, 'libsys' was added in the FBSD15 lifecycle, but I have > no idea of MFC status of this patch. Possibly viewed as too likely to contribute to odd consequences for already released FreeBSD's, possibly like are being investigated here? It can have compatibility consequences even if not part of the official ABI structure? === Mark Millard marklmi at yahoo.com
