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
