This works for most people, can you provide the full command line you are linking with?

Subject: Re:  gcc_s not found when linking 64-bit C++

On Mon, 13 Jul 2004, pinskia at gcc dot gnu dot org wrote:

>
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-13 00:40 -------
> This works for most people, can you provide the full command line you are linking with?

/usr/local/sparc64/bin/c++-3.4.1 -v -o exceptions  exceptions.cpp

Note that this is a "multi-lib" install, which uses a different 
library layout than the default install.

Bob

>
> --
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|UNCONFIRMED                 |WAITING
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16507
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>

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

In fact people use multi-lib installs all the time.  This smells of not fully installing gcc.

Or really saying you want 64bit but saying the default cpu is 32 bit: --with-cpu=ultrasparc

Subject: Re:  gcc_s not found when linking 64-bit C++

On Mon, 13 Jul 2004, pinskia at gcc dot gnu dot org wrote:

>
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-13 00:49 -------
> In fact people use multi-lib installs all the time.  This smells of not fully installing gcc.
>
> Or really saying you want 64bit but saying the default cpu is 32 bit: --with-cpu=ultrasparc

So --with-cpu=ultrasparc implies 32 bit CPU?  The option is a bit 
redundant.

I will try building without that option.

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

> Linking C++ programs fails due to either the wrong (32-bit) libgcc_s.so.1being
> installed in the compiler's default directory

I don't think so, the linker would have complained about ELF class mismatch.

> or the linker search path not being specified correctly.

Neither, I see -L/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1 and
libgcc_s.so should be there because of --enable-version-specific-runtime-libs.

> Note that default libgcc_s.so.1 is 32 bit, not 64-bit:
> % file /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.1/libgcc_s.so.1
> /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.1/libgcc_s.so.1:    ELF 32-bit MSB
> dynamic lib SPARC32PLUS Version 1, V8+ Required, UltraSPARC1 Extensions
> Required, dynamically linked, not stripped
> % file /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.1/sparcv9/libgcc_s.so.1 
> /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.1/sparcv9/libgcc_s.so.1:    ELF
> 64-bit MSB dynamic lib SPARCV9 Version 1, UltraSPARC1 Extensions Required,
> dynamically linked, not stripped

Note that you don't look at the right place.  According to your prefix
/usr/local/sparc64 and your target sparc64-sun-solaris2.9, the path should read:
% file /usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/libgcc_s.so.1

This suggests that the compiler was not properly installed, or maybe not
installed at all.  Please try again to issue "gmake install".

[As a side note, specifying -mcpu=ultrasparc doesn't imply 32-bit mode.]

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 06:53 -------
>> Linking C++ programs fails due to either the wrong (32-bit) libgcc_s.so.1being
>> installed in the compiler's default directory
>
> I don't think so, the linker would have complained about ELF class mismatch.
>
>> or the linker search path not being specified correctly.
>
> Neither, I see -L/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1 and
> libgcc_s.so should be there because of --enable-version-specific-runtime-libs.

Right.  I used a wrong command in my bug report, however, the actual 
condition remains.  Here is the good stuff:

blade:gcc/sparc64-sun-solaris2.9/3.4.1# pwd
/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1
blade:gcc/sparc64-sun-solaris2.9/3.4.1# file libgcc_s.so.1
libgcc_s.so.1:  ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+ 
Required, dynamically linked, not stripped

> This suggests that the compiler was not properly installed, or maybe not
> installed at all.  Please try again to issue "gmake install".
>
> [As a side note, specifying -mcpu=ultrasparc doesn't imply 32-bit mode.]

I have done another configure and build like:

% CC='gcc -m64' /home/bfriesen/src/gnu/gcc-3.4.1/configure
  --prefix=/usr/local/sparc64 --program-suffix=-3.4.1 --enable-shared
  --enable-threads --enable-version-specific-runtime-libs
  --enable-languages=c,c++ --disable-nls sparc64-sun-solaris2.9
% gmake bootstrap
% gmake install

And when compiling a trivial C++ program I see this error:

% /usr/local/sparc64/bin/c++-3.4.1 -o exceptions exceptions.cpp
ld: fatal: library -lgcc_s: not found
ld: fatal: library -lgcc_s: not found
ld: fatal: File processing errors. No output written to exceptions
collect2: ld returned 1 exit status

The following shows the same thing as in my bug report.  The linker 
(Sun linker, not GNU) is not being provided with the right paths in 
order to find the 64-bit libgcc_s.so:

% /usr/local/sparc64/bin/c++-3.4.1 -v -o exceptions exceptions.cpp
Reading specs from 
/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/specs
Configured with: /home/bfriesen/src/gnu/gcc-3.4.1/configure 
--prefix=/usr/local/sparc64 --program-suffix=-3.4.1 --enable-shared 
--enable-threads --enable-version-specific-runtime-libs 
--enable-languages=c,c++ --disable-nls sparc64-sun-solaris2.9
Thread model: posix
gcc version 3.4.1
  /usr/local/sparc64/libexec/gcc/sparc64-sun-solaris2.9/3.4.1/cc1plus 
-quiet -v -D__arch64__ -D__sparcv9 exceptions.cpp -quiet -dumpbase 
exceptions.cpp -mcpu=v9 -auxbase exceptions -version -o 
/var/tmp//cclL77eN.s
ignoring nonexistent directory 
"/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/../../../../sparc64-sun-solaris2.9/include"
#include "..." search starts here:
#include <...> search starts here:
  /usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/include/c++

/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/include/c++/sparc64-sun-solaris2.9

/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/include/c++/backward
  /usr/local/include
  /usr/local/sparc64/include
  /usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/include
  /usr/include
End of search list.
GNU C++ version 3.4.1 (sparc64-sun-solaris2.9)
         compiled by GNU C version 3.4.1.
GGC heuristics: --param ggc-min-expand=100 --param 
ggc-min-heapsize=131072
  /usr/ccs/bin/as -V -Qy -s -xarch=v9 -o /var/tmp//ccBepUPw.o 
/var/tmp//cclL77eN.s
/usr/ccs/bin/as: Sun WorkShop 6 update 2 Compiler Common 6.2 
Solaris_9_CBE 2001/04/02
  /usr/local/sparc64/libexec/gcc/sparc64-sun-solaris2.9/3.4.1/collect2 
-V -Y P,/usr/lib/sparcv9 -Qy -o exceptions 
/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/crt1.o 
/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/crti.o 
/usr/ccs/lib/sparcv9/values-Xa.o 
/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/crtbegin.o 
-L/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1 
-L/usr/ccs/bin/sparcv9 -L/usr/ccs/bin -L/usr/ccs/lib/sparcv9 
-L/usr/ccs/lib 
-L/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/../../.. 
-L/lib/sparcv9 -L/usr/lib/sparcv9 /var/tmp//ccBepUPw.o -lstdc++ -lm 
-lgcc_s -lgcc -lc -lgcc_s -lgcc -lc 
/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/crtend.o 
/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.381
ld: fatal: library -lgcc_s: not found
ld: fatal: library -lgcc_s: not found
ld: fatal: File processing errors. No output written to exceptions
collect2: ld returned 1 exit status

Note that this manually corrected link does work:

% /usr/local/sparc64/bin/c++-3.4.1
  -L/usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/sparcv9 -o
  exceptions exceptions.cpp

So there is either a problem with the specs file, or the default 
libgcc_s.so is expected to be 64-bit (but is not).

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

> Right.  I used a wrong command in my bug report, however, the actual 
> condition remains.  Here is the good stuff:
> 
> blade:gcc/sparc64-sun-solaris2.9/3.4.1# pwd
> /usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1
> blade:gcc/sparc64-sun-solaris2.9/3.4.1# file libgcc_s.so.1
> libgcc_s.so.1:  ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+ 
> Required, dynamically linked, not stripped

Okay. I'm a bit surprised by the error message issued by the linker though.

> So there is either a problem with the specs file, or the default 
> libgcc_s.so is expected to be 64-bit (but is not).

It's a bad interaction between --enable-version-specific-runtime-libs and the
multi-os-directory feature.

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 13:51 -------
>> Right.  I used a wrong command in my bug report, however, the actual
>> condition remains.  Here is the good stuff:
>>
>> blade:gcc/sparc64-sun-solaris2.9/3.4.1# pwd
>> /usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1
>> blade:gcc/sparc64-sun-solaris2.9/3.4.1# file libgcc_s.so.1
>> libgcc_s.so.1:  ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+
>> Required, dynamically linked, not stripped
>
> Okay. I'm a bit surprised by the error message issued by the linker though.

It does not surprise me since the linker never found a 64-bit 
libgcc_s.so in the search path. The Sun linker simply ignores 32-bit 
libraries..  If the linker had been requested to use a specific 
library file, and it was the wrong type, then the error would have 
been different.

>> So there is either a problem with the specs file, or the default
>> libgcc_s.so is expected to be 64-bit (but is not).
>
> It's a bad interaction between --enable-version-specific-runtime-libs and the
> multi-os-directory feature.

That's what it looks like to me.  There are a lot of variables here.

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?  I 
can manually fix the compiler install but I would like to do it 
correctly.

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

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

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

Subject: Re:  gcc_s not found when linking 64-bit C++

On Wed, 14 Jul 2004, Bob Friesenhahn wrote:
>
> 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.

I would like to be able to say that this finally worked as expected, 
but it did not.  As before, gcc_s is not found because libgcc_s.so is 
hidden away in a sparcv9 subdirectory and gcc is not telling the 
system linker where to look.

This fails:

% c++64-3.4.1 -o exceptions exceptions.cpp
ld: fatal: library -lgcc_s: not found
ld: fatal: library -lgcc_s: not found
ld: fatal: File processing errors. No output written to exceptions
collect2: ld returned 1 exit status

This succeeds:

% c++64-3.4.1 -L /usr/local/sparc64/lib/gcc/sparc64-sun-solaris2.9/3.4.1/sparcv9 -o exceptions exceptions.cpp
%

Thus far I have not found a permutation of options which installs the 
libraries in the right place, or passes the right options to the 
system linker so that it can find them.

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

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

> Thus far I have not found a permutation of options which installs the 
> libraries in the right place, or passes the right options to the 
> system linker so that it can find them.

Drop --enable-version-specific-runtime-libs with the 64-bit compiler or use a
32-bit multilibed compiler.

Subject: Re:  gcc_s not found when linking 64-bit C++

On Thu, 15 Jul 2004, ebotcazou at gcc dot gnu dot org wrote:
>>
>> 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.

I already have a 32-bit multilib compiler that works fine for building 
64-bit binaries.  However, my objective is to build a completely 
native 64-bit compiler using a special --prefix. This compiler should 
not requre that special -L flags be provided in order to achieve 
linkage to its own components.

The reason for this multi-day effort has been that I want 'make 
distcheck' to succeed when using 64-bit compilation.  Instead it ends 
up with a mis-mash of 32-bit and 64-bit files and fails.  I 
incorrectly assumed that requesting the 64-bit target would provide a 
64-bit build with libraries in the traditional locations.

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

It's a build machinery problem.

(In reply to comment #15)
> It's a build machinery problem.

Actually it is the "configure" script and "libtool" scripts in 99% of open source packages not handling the sparc64 correctly (not handling it at all would be more correct description).  This sometimes makes compiling stuff on bi-arch systems a nightmare.  One workaround is to use 'LDFLAGS=-R/prefix/lib/sparcv9 ./configure --libdir=/prefix/lib/sparcv9' (however, there might be sideeffects).

Gcc is about the only open source thing that I saw so far that handles sparc64 installs as it should.  You type one make command, you get both 32-bit and 64-bit libs.  You type one make install, you get both libs installed in correct locations (well, except for libiberty ;-).

.