[Bug c++/16507] gcc_s not found when linking 64-bit C++

["ebotcazou at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-07-15 05:21 -------
> If  the user uses a -L option which specifies the lib directory where 
> libstc++.so is installed (-L/prefix/lib), the link fails because even 
> though the desired default target is 64-bits, the libstc++.so 
> installed with other package libraries is 32-bits.  I have found that 
> using
> 
>   -L/prefix/lib/sparcv9 -L/prefix/lib
> 
> causes the link to succeed.  This is flawed in my opinion.

No, this is not flawed.  This is the standard behaviour on Solaris/SPARC.

> It is also quite a problem when compiling open source software since some 
> software uses the system linker to link and needs the -L option. If 
> "sparc64" is specified rather than "sparc", it seems to me that the 
> default libraries should be 64-bit.

No, this would mean that the sparc-sun-solaris2.* and the sparc64-sun-solaris2.*
compilers would override each other's libraries.

> I will now try using
> 
>   --disable-multilib --enable-version-specific-runtime-libs
> 
> since my objective is to create a directory tree for 100% 64-bit 
> development and I don't want to take the risk of failure while 
> upgrading the compiler.

This will not change anything, --disable-multilib has nothing to do here.

I'd suggest as a temporary workaround:
- either to use --enable-version-specific-runtime-libs with a 32-bit multilib
compiler, and to wrap up 'gcc -m64' in a shell script 'gcc64',
- or to drop --enable-version-specific-runtime-libs with the 64-bit compiler,
using a special --prefix instead.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16507