sparcv9 build failure with GCC mainline

[Adhemerval Zanella Netto]

On 06/12/23 22:14, Joseph Myers wrote:
> 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.
> 
> Should this be fixed by making glibc also define .udiv and .div together, 
> or is there some better approach for fixing this build failure?  It's 
> unfortunate that the division of libgcc functions into object files is 
> part of the libgcc interface that glibc needs to know about (in this case, 
> when glibc also defines some of the same functions), but it seems that it 
> is (for static linking).
> 


Afaik these in glibc only for compatibility reasons, and to keep the compat
was always tricky (bdc543e338281 for instance).  Consolidating .udiv and
.div on same TU seems the easiest solution.