Date: Sat, 8 Nov 2025 01:29:21 -0800 From: Mark Millard <marklmi@yahoo.com> To: Dimitry Andric <dim@FreeBSD.org>, FreeBSD-pkgbase@freebsd.org Subject: Re: git: 51e8e8b0f369 - main - Merge commit e24f90190c77 from llvm git (by Brad Smith): Message-ID: <D7A7C424-28D7-401A-8655-2802B07C8DDA@yahoo.com> In-Reply-To: <C1FDECCF-DCCD-42EF-AF58-22EC3A6C0CA5@yahoo.com> References: <23041DE4-706C-427C-9BC5-3AD5EAD13934@yahoo.com> <C1FDECCF-DCCD-42EF-AF58-22EC3A6C0CA5@yahoo.com>
index | next in thread | previous in thread | raw e-mail
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(); } 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.comhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D7A7C424-28D7-401A-8655-2802B07C8DDA>