Re: RETITLED/edited/shorter: Building lang/gcc14 fails only on main [so: 15], works on 14.2-Release and 14.2-Stable, why?

On 28.04.2025 0:39, Mark Millard wrote:
> On Apr 27, 2025, at 11:34, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> On Apr 27, 2025, at 09:21, Mark Millard <marklmi@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.

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, 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*).

The only material supplied by FBSD that is relevant for this issue 
(shared libraries) are /lib/libc.so.7 and /lib/libsys.so.7

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.

If memory serves me, 'libsys' was added in the FBSD15 lifecycle, but I 
have no idea of MFC status of this patch.

Michal