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

["bfriesen at simple dot dallas dot tx dot us" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From bfriesen at simple dot dallas dot tx dot us  2004-07-15 02:18 -------
Subject: Re:  gcc_s not found when linking 64-bit C++

On Tue, 13 Jul 2004, ebotcazou at gcc dot gnu dot org wrote:

>
> ------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-07-13 14:38 -------
>> Should the default libgcc_s.so.1 be 64-bit for this target or should
>> the specs file always look in the sparcv9 subdirectory by default?
>
> That's the whole question.  The default directory $(prefix)/lib is 32-bit on
> Solaris, $(prefix)/lib/sparcv9 being the 64-bit directory, both for the
> sparc-sun-solaris2.* and the sparc64-sun-solaris2.* compilers.  Now
> $(prefix)/lib/gcc/$(target)/$(gcc-version) is 32-bit with the
> sparc-sun-solaris2.* compiler and 64-bit with the sparc64-sun-solaris2.*
> compiler.  So all of this becomes very messy when
> --enable-version-specific-runtime-libs comes into play in the latter case.

I performed another build without 
--enable-version-specific-runtime-libs and the situation has improved 
(C++ programs link by default) however there is still a problem.  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. 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.  If the user uses a -m option to 
select 32-bits, then the compiler can alter the path in order to find 
the 32-bit version.

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.

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us
http://www.simplesystems.org/users/bfriesen


-- 


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