public inbox for glibc-cvs@sourceware.org
help / color / mirror / Atom feed
* [glibc] Do not build sparc32 libgcc functions into static libc
@ 2023-12-19 16:00 Joseph Myers
  0 siblings, 0 replies; only message in thread
From: Joseph Myers @ 2023-12-19 16:00 UTC (permalink / raw)
  To: glibc-cvs

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5275fc784c8113c84c85ca028ce621f68fe6642b

commit 5275fc784c8113c84c85ca028ce621f68fe6642b
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Tue Dec 19 16:00:11 2023 +0000

    Do not build sparc32 libgcc functions into static libc
    
    Since GCC commit f31a019d1161ec78846473da743aedf49cca8c27 "Emit
    funcall external declarations only if actually used.", the glibc
    testsuite has failed to build for 32-bit SPARC with GCC mainline.
    
    /scratch/jmyers/glibc-bot/install/compilers/sparc64-linux-gnu/lib/gcc/sparc64-glibc-linux-gnu/14.0.0/../../../../sparc64-glibc-linux-gnu/bin/ld: /scratch/jmyers/glibc-bot/install/compilers/sparc64-linux-gnu/lib/gcc/sparc64-glibc-linux-gnu/14.0.0/32/libgcc.a(_divsi3.o): in function `.div':
    /scratch/jmyers/glibc-bot/src/gcc/libgcc/config/sparc/lb1spc.S:138: multiple definition of `.div'; /scratch/jmyers/glibc-bot/build/glibcs/sparcv9-linux-gnu/glibc/libc.a(sdiv.o):/scratch/jmyers/glibc-bot/src/glibc/gnulib/../sysdeps/sparc/sparc32/sparcv9/sdiv.S:13: first defined here
    /scratch/jmyers/glibc-bot/install/compilers/sparc64-linux-gnu/lib/gcc/sparc64-glibc-linux-gnu/14.0.0/../../../../sparc64-glibc-linux-gnu/bin/ld: disabling relaxation; it will not work with multiple definitions
    collect2: error: ld returned 1 exit status
    make[3]: *** [../Rules:298: /scratch/jmyers/glibc-bot/build/glibcs/sparcv9-linux-gnu/glibc/nptl/tst-cancel24-static] Error 1
    
    https://sourceware.org/pipermail/libc-testresults/2023q4/012154.html
    
    I'm not sure of the exact sequence of undefined references that cause
    first the glibc object file defining .div and then the libgcc object
    file defining both .div and .udiv to be pulled in (which must have
    been perturbed by that GCC change in a way that introduced the build
    failure), but I think the failure illustrates that it's inherently
    fragile for glibc to define symbols in separate object files that
    libgcc defines in the same object file - and indeed for glibc to
    redefine libgcc symbols at all, since the division into object files
    shouldn't really be part of the interface between libgcc and libc.
    
    These symbols appear to be in libc only for compatibility, maybe one
    of the cases where they were accidentally exported from shared libc in
    glibc 2.0 before the introduction of symbol versioning and so programs
    started expecting shared libc to provide them.  Thus, there is no need
    to have them in static libc.  Add this set of libgcc functions to
    shared-only-routines so they are no longer provided in static libc.
    (No change is made regarding .mul - dotmul source file - since unlike
    the other symbols in this grouping, it doesn't actually appear to be a
    libgcc symbol, at least in current GCC.)
    
    Tested with build-many-glibcs.py for sparcv9-linux-gnu with GCC
    mainline.

Diff:
---
 sysdeps/sparc/sparc32/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sysdeps/sparc/sparc32/Makefile b/sysdeps/sparc/sparc32/Makefile
index b792e56710..cc1db68cc6 100644
--- a/sysdeps/sparc/sparc32/Makefile
+++ b/sysdeps/sparc/sparc32/Makefile
@@ -17,6 +17,7 @@
 
 ifeq ($(subdir),gnulib)
 sysdep_routines = dotmul umul $(divrem) alloca
+shared-only-routines += umul $(divrem)
 endif	# gnulib
 
 divrem := sdiv udiv rem urem

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2023-12-19 16:00 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-19 16:00 [glibc] Do not build sparc32 libgcc functions into static libc Joseph Myers

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).