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. >> 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.
