Re: Solaris 10: wchar_iso.h vs cwchar

[Maciej (Matchek) BliziÅski <maciej at opencsw dot org>]

2011/9/5 Jonathan Wakely <jwakely.gcc@gmail.com>:
> 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