Re: [RFC] Dos and don'ts while removing multilib

Hi Thomas,
hi Andreas,

Thanks for sharing the setup on x86_64/alpha/ia64.  I was afraid that
directory structures might be different and not really standardized.  In
order to have a smooth transition while removing an ABI from s390, I
will keep the directory structure as is for the remaining 64-bit target.
I guess it is uncommon (maybe first time?) that a target removes an ABI,
so it is not unexpected to run into odd cases.  Meanwhile I've
identified two bugs (?!) and I will send out a patch shortly in order to
discuss those.

Thanks again,
Stefan

On Tue, May 05, 2026 at 11:46:28AM +0200, Thomas Schwinge wrote:
> Hi!
> 
> On 2026-05-01T11:50:11+0200, Stefan Schulze Frielinghaus <[email protected]> wrote:
> > I'm in the middle of preparing a patch in order to remove -m31 support
> > for s390.  After the removal, there is only 64-bit support left which
> > renders multilib obsolete on s390 ... or doesn't it?  In the past 32-bit
> > libraries were installed under /usr/lib and 64-bit libraries under
> > /usr/lib64 which I would like to keep.
> 
> Not sure if the following helps you figure out how to configure, but just
> in case: a standard x86_64-pc-linux-gnu build (on Debian/Ubuntu;
> multiarch), puts (default) '-m64' libraries into 'lib64/', and '-m32'
> ones into 'lib32/', and 'lib/' only contains "GCC internals".  If I build
> that with '--disable-multilib' (which should -- conceptually --
> correspond to your new scenario?), I still get 'lib64/' for the (default)
> '-m64' libraries (and no 'lib32/' anymore), and the 'include's also still
> work.
> 
> 
> Grüße
>  Thomas
> 
> 
> > Naively removing
> > MULTILIB_{OPTIONS,DIRNAMES,OSDIRNAMES} from Makefile
> > config/s390/t-linux64 and the define MULTILIB_DEFAULTS results in
> > choosing the wrong library dir `lib` instead of `lib64`.  For example,
> > on Fedora we would run into:
> >
> > /devel/gcc-test/build/./gcc/xgcc -B/devel/gcc-test/build/./gcc/ -B/devel/gcc-test/dst/s390x-ibm-linux-gnu/bin/ -B/devel/gcc-test/dst/s390x-ibm-linux-gnu/lib/ -isystem /devel/gcc-test/dst/s390x-ibm-linux-gnu/include -isystem /devel/gcc-test/dst/s390x-ibm-linux-gnu/sys-include    -O2  -g -O2 -DIN_GCC   -W -Wall -Wno-error=narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -mlong-double-128 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map  -o ./libgcc_s.so.1.tmp -g -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _mulbitint3_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o _divmodbitint4_s.o _dpd_hf_to_sd_s.o _dpd_hf_to_dd_s.o _dpd_hf_to_td_s.o _dpd_sd_to_hf_s.o _dpd_dd_to_hf_s.o _dpd_td_to_hf_s.o sfp-exceptions_s.o extendhfsf2_s.o extendhfdf2_s.o extendhftf2_s.o truncsfhf2_s.o truncdfhf2_s.o trunctfhf2_s.o fixhfti_s.o fixunshfti_s.o floattihf_s.o floatuntihf_s.o floatbitinthf_s.o fixtfbitint_s.o floatbitinttf_s.o fixsfbitint_s.o floatbitintsf_s.o fixdfbitint_s.o floatbitintdf_s.o enable-execute-stack_s.o hardcfr_s.o strub_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc
> > /usr/bin/ld: cannot find crti.o: No such file or directory
> >
> > Option -v gives a clue why this is failing:
> >
> > LIBRARY_PATH=/devel/gcc-test/build/./gcc/:./:/lib/:/usr/lib/
> >
> > The library path can be fixed via
> >
> > MULTIARCH_DIRNAME = ../lib64$(call if_multiarch,:s390x-linux-gnu)
> >
> > where we then have
> >
> > LIBRARY_PATH=/devel/gcc-test/build/./gcc/:./:/lib/../lib64/:/lib/:/usr/lib/../lib64/:/usr/lib/
> >
> > However, this works on Fedora but fails on Debian/Ubuntu with another
> > error:
> >
> > make[2]: Entering directory '/devel/gcc-test/build/s390x-ibm-linux-gnu/libgcc'
> > # If this is the top-level multilib, build all the other
> > # multilibs.
> > /devel/gcc-test/build/./gcc/xgcc -B/devel/gcc-test/build/./gcc/ -B/devel/gcc-test/dst/s390x-ibm-linux-gnu/bin/ -B/devel/gcc-test/dst/s390x-ibm-linux-gnu/lib/ -isystem /devel/gcc-test/dst/s390x-ibm-linux-gnu/include -isystem /devel/gcc-test/dst/s390x-ibm-linux-gnu/sys-include    -g -O2 -O2  -g -O2 -DIN_GCC   -W -Wall -Wno-error=narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -mlong-double-128 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  -fPIC -mlong-double-128 -I. -I. -I../.././gcc -I/devel/gcc-test/src/libgcc -I/devel/gcc-test/src/libgcc/. -I/devel/gcc-test/src/libgcc/../gcc -I/devel/gcc-test/src/libgcc/../include  -DHAVE_CC_TLS   -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /devel/gcc-test/src/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
> > In file included from /devel/gcc-test/src/libgcc/../gcc/tsystem.h:95,
> >                  from /devel/gcc-test/src/libgcc/libgcc2.c:27:
> > /usr/include/stdio.h:28:10: fatal error: bits/libc-header-start.h: No such file or directory
> >    28 | #include <bits/libc-header-start.h>
> >       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~
> > compilation terminated.
> >
> > Option -v shows:
> >
> > #include <...> search starts here:
> >  .
> >  ../.././gcc
> >  /devel/gcc-test/src/libgcc
> >  /devel/gcc-test/src/libgcc/../gcc
> >  /devel/gcc-test/src/libgcc/../include
> >  /devel/gcc-test/build/./gcc/include
> >  /devel/gcc-test/build/./gcc/include-fixed
> >  /usr/local/include
> >  /usr/include
> > End of search list.
> >
> > However, on Debian/Ubuntu we have a multiarch directory structure
> >
> > $ ls /usr/include/bits
> > ls: cannot access '/usr/include/bits': No such file or directory
> > $ ls /usr/include/s390x-linux-gnu/bits/libc-header-start.h
> > /usr/include/s390x-linux-gnu/bits/libc-header-start.h
> >
> > The only configuration which works so far on Fedora/Debian/Ubuntu is to
> > still enable multilib support via
> >
> > config/s390/t-linux64:
> > MULTILIB_OPTIONS = m64
> > MULTILIB_DIRNAMES = 64
> > MULTILIB_OSDIRNAMES = ../lib64$(call if_multiarch,:s390x-linux-gnu)
> >
> > config/s390/linux.h:
> > #define MULTILIB_DEFAULTS { "m64" }
> >
> > However, having a multilib setup for a single option seems overly
> > complicated and slightly off to me.  Though, some comments  seem to
> > indicate that for some setups this maybe required.  Since I'm not
> > familiar with multilib/multiarch setups I might have missed something
> > and welcome any suggestions.  If everything fails, I will keep the
> > single multilib setup since this is basically the configuration which
> > works up to date.
> >
> > Cheers,
> > Stefan