2011/9/5 Jonathan Wakely <jwakely.gcc@xxxxxxxxx>: > 2011/9/5 Marc Glisse : >> On Mon, 5 Sep 2011, Maciej Bliziński wrote: >> >>> What is the right way to set the RPATH on the binary / pass >>> -R/opt/csw/lib to the linker? By reading the docs, searching the web >>> and reading code I found out so far the following potential ways: >>> >>> 1. "--with-boot-ldflags=flags - This option may be used to set linker >>> flags to be used when linking stage 2 and later when bootstrapping >>> GCC. " >> >> Equivalent to BOOT_LDFLAGS (I hope). >> >>> 2. exporting LDFLAGS >> >> (also named --with-stage1-ldflags I believe) >> >>> 3. exporting BOOT_LDFLAGS >> >> You need both this one and the previous one to add the rpath at all stages. > > I think Marc's right here. > > IIRC setting LD_RUN_PATH doesn't help, maybe it gets cleaned from the > environment. > > >>> 4. exporting LDFLAGS_FOR_TARGET >> >> I don't think that's needed (and it won't do exactly what you want for >> libstdc++ wrt. 32/64bits, maybe LD_RUN_PATH_32 (and _64) would help there, >> but libstdc++ shouldn't need to know where to find libgcc_s because >> everything linked with libstdc++ should also be linked with libgcc_s). > > Indeed, but if the CSW rules say libstdc++ must be able to find its > dependency anyway you could use an rpath of $ORIGIN. Right, but there's still the question how to do you set the RPATH on libstdc++. I did some science - I set a number of environment variables, seeding them with unique strings, and ran a build. export BOOT_LDFLAGS="-R/env/boot-ldflags" export LDFLAGS_FOR_TARGET="-R/env/ldflags-for-target" export LDFLAGS_FOR_BUILD="-R/env/ldflags-for-build" export LDFLAGS="-L/opt/csw/lib -R/env/ldflags" export LD_OPTIONS="-R/env/ld-options" Then I looked at libstdc++ to see if any of the strings made it into RPATH. The answer: LD_OPTIONS So I set LD_OPTIONS to -R/opt/csw/lib -R/opt/csw/lib/$ISALIST and got libstdc++ with the right RPATH. >>> Is any of these ways the right way to pass -R/opt/csw/lib? If none, >>> what is the right way? >> >> I would also patch the specs at some point anyway (gcc/gcc.c if before >> building, or copying the patched relevant part of `gcc -dumpspecs` to a >> specs file in the right directory (use truss to find which one) afterwards) >> so users don't have to add a -R option for their programs to find libstdc++. >> If you patch gcc/gcc.c, it may also solve your libstdc++ "issue". > > I think patching the specs is the approach taken by NetBSD's pkgsrc > and some other packaging systems, although I've seen it done wrong > (e.g. only working for 64-bit builds) as often as I've seen it done > right. I wouldn't want that. I prefer less magic on the compiler's side and more control on the build system's side. For example, on Solaris, it's common to keep 32-bit and 64-bit binaries on the filesystem, in directories named e.g. /opt/csw/lib/sparcv9 and /opt/csw/lib/amd64. I'm still running a full GCC build to get the full set of packages and start the next round of testing. Maciej
