I was building a cross-compiler from i686 linux to sparc solaris 2.8. Binutils were configured as ../binutils-2.19/configure --target=sparc-sun-solaris2.8 \ --with-sysroot=/usr/local/sysroots/sparc-sun-solaris2.8 Where /usr/local/sysroots/sparc-sun-solaris2.8 contains the /usr/include and /usr/lib directories from a solaris2.8/sparc machine. It worked for the most part, but when I was done building gcc, I noticed that the linker does not search /usr/local/sparc-sun-solaris2.8/lib (called $tool_lib from now on) when linking 32 bit applications. These would thus not link unless I passed -rpath-link=$tool_lib to the linker, complaining libgcc_s.so.1 and libstdc++.so.6 could not be found. 64 bit applications link fine, however. The problem lies in the builtin linker scripts. Where the ${builddir}/ld/ldscripts/elf64_sparc.x* linker scripts (and consequently ld/eelf64_sparc.c) are generated including $tool_lib/sparcv9 (but not $tool_lib) in the SEARCH_DIRs, the elf32_sparc.x* scripts don't have $tool_lib; their relevant line is SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/usr/ccs/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib"); Manually patching eelf32_sparc.c, then compiling ld solves the problem. I believe the relevant piece of code is in ${sourcedir}/ld/genscripts.sh, lines 155 to 164, where $tool_lib is added to $libs _unless_ binutils are configured with --with-sysroot - in which case they are, however, also needed there.
Created attachment 3633 [details] Make 32-bit sparc library searching behave in the same way as the 64-bit version
Hi, I do not think that genscripts.sh is misbehaving here. In general if you are providing a sysroot then you should not expect the linker to search elsewhere for libraries. The fact that the 64-bit sparc linker does do this is an anomaly. (At least in my opinion). It does make sense however that the 32-bit and 64-bit sparc linkers should behave in same way, so please could you try out the uploaded patch which will make the 32-bit sparc linker look in the normal system library directories as well as the sysroot directories. Cheers Nick
That works, at least for my use case. About the searchworthyness of those directories with a sysroot linker...I don't know much about the bowels of binutils or gcc, so I can't make any calls on design questions. From a user's perspective, though - unless I (and, indeed, most people who bothered with cross compilers on the 'net) was grossly misinformed, --with-sysroot is the preferred means to build cross compilers, and it would make a lot of sense if the linker the compiler uses found the compiler's components. How that is best achieved is open for debate, I suppose, but one way or another, the linker has to know where to find them.
Fixed a long time ago