Re: git: 51e8e8b0f369 - main - Merge commit e24f90190c77 from llvm git (by Brad Smith):

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sat, 08 Nov 2025 16:19:27 UTC
On Nov 8, 2025, at 01:29, Mark Millard <marklmi@yahoo.com> wrote:

> On Nov 7, 2025, at 23:03, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> On Nov 7, 2025, at 19:51, Mark Millard <marklmi@yahoo.com> wrote:
>> 
>>> Dimitry Andric <dim_at_FreeBSD.org> wrote on
>>> Date: Thu, 06 Nov 2025 15:56:54 UTC :
>>> 
>>>> On 5 Nov 2025, at 08:56, Herbert J. Skuhra <herbert@gojira.at> wrote:
>>>>> 
>>>>> On Fri, 31 Oct 2025 14:48:06 +0100, Jose Luis Duran wrote:
>>>>>> 
>>>>>> On Wed, Oct 29, 2025 at 3:50 PM Dimitry Andric <dim@freebsd.org> wrote:
>>>>>>> 
>>>>>>> The branch main has been updated by dim:
>>>>>>> 
>>>>>>> URL: https://cgit.FreeBSD.org/src/commit/?id=51e8e8b0f36933814b1be08913857727876aece5
>>>>>>> 
>>>>>>> 
>>> . . .
>>>>>>> 
>>>>>>> Merge commit e24f90190c77 from llvm git (by Brad Smith):
>>>>>>> 
>>>>>>> [Driver] Enable outline atomics for FreeBSD/aarch64 (#156089)
>>>>>>> 
>>>>>>> The compiler_rt helper functions have been built since 12.4, 13.1, 14
>>>>>>> and anything newer.
>>>>>>> 
>>>>>>> 
>>> . . .
>>>>>> I'm sure you're probably aware by now, but aarch64 builds are failing
>>>>>> after this commit:
>>>>>> 
>>>>>> https://ci.freebsd.org/job/FreeBSD-main-aarch64-build/33100/
>>>>> 
>>>>> I am now getting this error on stable/15 (aarch64) after this change was
>>>>> reverted in f6a81b18a467.
>>>>> 
>>>>> I have already tried:
>>>>> 
>>>>> % rm -rf /usr/obj/usr
>>>>> % rm -rf ~/.cache/ccache
>>>>> % make SRCCONF=/dev/null __MAKE_CONF=/dev/null buildworld
>>>>> 
>>>>> I am now trying to rebuild world with llvm19 from ports.
>>>> 
>>>> I have repeatedly tried to reproduce this problem, but I have been unsuccessful.
>>> 
>>> I tried to set up a simple context to experiment with but ended up
>>> blocked for what I intended. Nothing blocked making a .o for
>>> which:
>>> 
>>>   6: 0000000000000000     4 FUNC    GLOBAL HIDDEN      2 shared_static_routine
>>> 
>>> Nothing blocked making a .a for which:
>>> 
>>>   6: 0000000000000000     4 FUNC    GLOBAL HIDDEN      2 shared_static_routine
>>> 
>>> But every one of my attempts to form a .so with such a GLOBAL HIDDEN status
>>> based on the .a instead ended up with the likes of:
>>> 
>>>  30: 0000000000010538     4 FUNC    LOCAL  HIDDEN     12 shared_static_routine
>>> 
>>> So I did not get to the stage of a program that uses a .so with GLOBAL HIDDEN
>>> status involved.
>>> 
>>> I tried commands that used each of: /usr/bin/ld ,  /usr/bin/ld.lld ,
>>> /usr/local/bin/ld.bfd , and /usr/local/bin/aarch64-unknown-freebsd16.0-ld .
>>> 
>>> I did similarly on amd64.
>>> 
>>> All of them converted the GLOBAL to be a LOCAL in the .so .
>>> 
>>> The context used is main 16.
>>> 
>>> It looks like the toolchain is deliberately avoiding generating the
>>> GLOBAL HIDDEN combination in the .so .
>>> 
>>>> If anybody has a system where this reliably occurs, and can give me access to it (no privileged user needed, as long as git is installed), that would be nice.
>> 
>> 
>> Turns out that my intended test was based on a partial
>> misinterpretation of the original error messages. I'll
>> need to set up a somewhat different test later.
>> 
> 
> Here is the small example context I came up with to test. I show
> commands to use in comments for each of the 3 tiny source files.
> 
> 
> File #1 of 3:
> 
> // shared_static_routine.c :
> 
> // cc -std=c17 -Wpedantic -Wall -o shared_static_routine.o -fPIC -c shared_static_routine.c -fvisibility=internal
> // ar rcs libstatic_routine.a shared_static_routine.o
> 
> // Note: Ends up with GLOBAL binding and HIDDEN visibility in libstatic_routine.a
> 
> 
> void shared_static_routine(void) {}
> 
> 
> File #2 of 3:
> 
> // shared_static_referencing_routine.c :
> 
> // BAD:  cc -shared -fPIC -Wl,-soname,libshared_routine.so -o libshared_routine.so                      shared_static_referencing_routine.c
> // vs.
> // GOOD: cc -shared -fPIC -Wl,-soname,libshared_routine.so -o libshared_routine.so -L. -lstatic_routine shared_static_referencing_routine.c
> 
> 
> extern void shared_static_routine(void);
> 
> void shared_static_referencing_routine(void) { shared_static_routine(); }

For reference . . .

BAD ends up with:

# readelf -s libshared_routine.so | grep shared_static_routine
     2: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT   UND shared_static_routine
    40: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT   UND shared_static_routine

GOOD ends up with:

# readelf -s libshared_routine.so | grep shared_static_routine
    26: 0000000000000000     0 FILE    LOCAL  DEFAULT   ABS shared_static_routine.c
    30: 0000000000010538     4 FUNC    LOCAL  HIDDEN     12 shared_static_routine


> File #3 of 3:
> 
> // shared_routine_main.c :
> 
> // cc -o shared_routine_main.o -fPIC -c shared_routine_main.c
> // Then . . .
> 
> // For good libshared_routine.so case:
> // SUFFICIENT:
> // cc -o shared_routine_main   -fPIC    shared_routine_main.o -L.                  -lshared_routine -Wl,-rpath=.
> // ALSO WORKS:
> // cc -o shared_routine_main   -fPIC    shared_routine_main.o -L. -lstatic_routine -lshared_routine -Wl,-rpath=.
> 
> // For the bad libshared_routine.so case, the SUFFICIENT case above reports:
> //
> // ld: error: undefined reference: shared_static_routine
> // >>> referenced by ./libshared_routine.so (disallowed by --no-allow-shlib-undefined)
> // cc: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> // For the bad libshared_routine.so case, the ALSO WORKS case above reports:
> //
> // ld: error: non-exported symbol 'shared_static_routine' in './libstatic_routine.a(shared_static_routine.o)' is referenced by DSO './libshared_routine.so'
> // cc: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> 
> extern void shared_static_referencing_routine(void);
> 
> int main(void) { shared_static_referencing_routine(); }
> 



===
Mark Millard
marklmi at yahoo.com