The 04/29/2020 10:18, Florian Weimer wrote: > * Szabolcs Nagy: > > > The 04/28/2020 10:58, Mathieu Desnoyers wrote: > >> ----- On Apr 28, 2020, at 8:54 AM, Florian Weimer fw@xxxxxxxxxxxxx wrote: > >> > That one definitely should work. > >> > > >> > I expect you might see this if libgcc_s.so.1 is installed into a > >> > multiarch subdirectory that upstream glibc does not search. (The > >> > Debian patches are unfortunately not upstream.) > >> > >> My test environment is a Ubuntu 18.04.1 LTS. > >> > >> > > >> > I think on my system, the built glibc can find the system libgcc_s via > >> > /etc/ld.so.cache, so I haven't seen this issue yet. > >> > >> On my system, libgcc_s is provided here: > >> > >> /lib/x86_64-linux-gnu/libgcc_s.so.1 > >> > >> by this package: > >> > >> Package: libgcc1 > >> Architecture: amd64 > >> Version: 1:8.4.0-1ubuntu1~18.04 > > > > before running the tests > > > > cp `$CC --print-file-name libgcc_s.so.1` glibc/build/dir > > cp `$CC --print-file-name libstdc++.so.6` glibc/build/dir > > > > so those toolchain libs are in the search path > > of the newly built libc when running tests. > > Do you actually see the need for these steps yourself? > > I guess the correct fix would be to upstream the Debian multiarch > changes and activate them automatically with a configure check on > systems that use multiarch paths. cancel tests work for me on an ubuntu system because of /etc/ld.so.cache, but that may not be present or the system may not be glibc based at all. i always do the cp because i build gcc myself (usually close to current master) and don't install it to the system path which means at compile time and runtime different libraries are used if i dont copy
