I'm trying to build a 64-bit shared library using gcc 3.4.3 on a
Solaris 10 x86 system.  For example:

  /* testlib.c */
  int foo() { return 0; }

  $ /usr/sfw/bin/gcc -o testlib -m64 -shared -fpic testlib.c

  $ ldd -s ./testlib

   find object=libgcc_s.so.1; required by ./testlib
    search path=/usr/local/lib  (LD_LIBRARY_PATH)
    trying path=/usr/local/lib/libgcc_s.so.1
    search path=/usr/sfw/lib  (RPATH from file ./testlib)
    trying path=/usr/sfw/lib/libgcc_s.so.1
    search path=/lib/64:/usr/lib/64  (default)
    trying path=/lib/64/libgcc_s.so.1
    trying path=/usr/lib/64/libgcc_s.so.1
        libgcc_s.so.1 =>         /usr/sfw/lib/libgcc_s.so.1  - wrong
ELF class: ELFCLASS32

Notice it's picking up the wrong libgcc_s from /usr/sfw/lib; it should
be picking it up from the /usr/sfw/lib/amd64 directory.  If I add this
to my LD_LIBRARY_PATH it works, but we want to do it so end users don't
have to modify their environment.

Is there someway to get /usr/sfw/bin/gcc to pick up the 64-bit
directory?  I'm guessing I want to somehow get the compiler to pick up
crtbegin, crtend and libgcc.a from

   /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/amd64

Maybe using -nodefaultlibs or -nostdlib somehow?

kenkahn wrote:
> I'm trying to build a 64-bit shared library using gcc 3.4.3 on a
> Solaris 10 x86 system.  For example:
>
>   /* testlib.c */
>   int foo() { return 0; }
>
>   $ /usr/sfw/bin/gcc -o testlib -m64 -shared -fpic testlib.c
>
>   $ ldd -s ./testlib
>
>    find object=libgcc_s.so.1; required by ./testlib
>     search path=/usr/local/lib  (LD_LIBRARY_PATH)
>     trying path=/usr/local/lib/libgcc_s.so.1
>     search path=/usr/sfw/lib  (RPATH from file ./testlib)
>     trying path=/usr/sfw/lib/libgcc_s.so.1
>     search path=/lib/64:/usr/lib/64  (default)
>     trying path=/lib/64/libgcc_s.so.1
>     trying path=/usr/lib/64/libgcc_s.so.1
>         libgcc_s.so.1 =>         /usr/sfw/lib/libgcc_s.so.1  - wrong
> ELF class: ELFCLASS32
> Notice it's picking up the wrong libgcc_s from /usr/sfw/lib; it should
> be picking it up from the /usr/sfw/lib/amd64 directory.  If I add this
> to my LD_LIBRARY_PATH it works, but we want to do it so end users don't
> have to modify their environment.
> Is there someway to get /usr/sfw/bin/gcc to pick up the 64-bit
> directory?  I'm guessing I want to somehow get the compiler to pick up
> crtbegin, crtend and libgcc.a from
>    /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/amd64
> Maybe using -nodefaultlibs or -nostdlib somehow?

No gcc is kind of dumb. It needs to be told where to look.
You can resort to using -L -R on the command line or
preset LD_RUN_PATH
No such problem with Studio 11
I tested on SPARC but AMD should work the same

"gerryt"  wrote:

>> I'm trying to build a 64-bit shared library using gcc 3.4.3 on a
>> Solaris 10 x86 system.  For example:
>>
>>   /* testlib.c */
>>   int foo() { return 0; }
>>
>>   $ /usr/sfw/bin/gcc -o testlib -m64 -shared -fpic testlib.c
>>
>>   $ ldd -s ./testlib
>>
>>    find object=libgcc_s.so.1; required by ./testlib
>>     search path=/usr/local/lib  (LD_LIBRARY_PATH)
>>     trying path=/usr/local/lib/libgcc_s.so.1
>>     search path=/usr/sfw/lib  (RPATH from file ./testlib)
>>     trying path=/usr/sfw/lib/libgcc_s.so.1
>>     search path=/lib/64:/usr/lib/64  (default)
>>     trying path=/lib/64/libgcc_s.so.1
>>     trying path=/usr/lib/64/libgcc_s.so.1
>>         libgcc_s.so.1 =>         /usr/sfw/lib/libgcc_s.so.1  - wrong
>> ELF class: ELFCLASS32
>> Is there someway to get /usr/sfw/bin/gcc to pick up the 64-bit
>> directory?  I'm guessing I want to somehow get the compiler to pick up
>> crtbegin, crtend and libgcc.a from
>>    /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/amd64

Compile-time works fine here, it is only the runpath that is wrong.
Adding -R/usr/sfw/lib/64 to the command line works fine.

> No gcc is kind of dumb. It needs to be told where to look.
> You can resort to using -L -R on the command line or
> preset LD_RUN_PATH

gcc is not dumb, the specs of the version of gcc provided with solaris 10
are. See:
http://bugs.opensolaris.org/view_bug.do?bug_id=6223255

gerryt wrote:
> No gcc is kind of dumb. It needs to be told where to look.
> You can resort to using -L -R on the command line or
> preset LD_RUN_PATH

My test case using -R/usr/sfw/lib/amd64  appears to confirm that this
does fix the problem.
Thanks..

> No such problem with Studio 11

Agreed; the code in question is vendor supplied, and they insist on
using gcc on *all* supported platforms.  We use forte 11 for our own
code and never had this problem.

Thanks...

Marc wrote:
> "gerryt"  wrote:
> >> I'm trying to build a 64-bit shared library using gcc 3.4.3 on a
> >> Solaris 10 x86 system.  For example:
> >>   /* testlib.c */
> >>   int foo() { return 0; }
> >>   $ /usr/sfw/bin/gcc -o testlib -m64 -shared -fpic testlib.c
> >>   $ ldd -s ./testlib
> >>    find object=libgcc_s.so.1; required by ./testlib
> >>     search path=/usr/local/lib  (LD_LIBRARY_PATH)
> >>     trying path=/usr/local/lib/libgcc_s.so.1
> >>     search path=/usr/sfw/lib  (RPATH from file ./testlib)
> >>     trying path=/usr/sfw/lib/libgcc_s.so.1
> >>     search path=/lib/64:/usr/lib/64  (default)
> >>     trying path=/lib/64/libgcc_s.so.1
> >>     trying path=/usr/lib/64/libgcc_s.so.1
> >>         libgcc_s.so.1 =>         /usr/sfw/lib/libgcc_s.so.1  - wrong
> >> ELF class: ELFCLASS32
> >> Is there someway to get /usr/sfw/bin/gcc to pick up the 64-bit
> >> directory?  I'm guessing I want to somehow get the compiler to pick up
> >> crtbegin, crtend and libgcc.a from
> >>    /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/amd64
> Compile-time works fine here, it is only the runpath that is wrong.
> Adding -R/usr/sfw/lib/64 to the command line works fine.
> > No gcc is kind of dumb. It needs to be told where to look.
> > You can resort to using -L -R on the command line or
> > preset LD_RUN_PATH
> gcc is not dumb, the specs of the version of gcc provided with solaris 10
> are. See:
> http://bugs.opensolaris.org/view_bug.do?bug_id=6223255

So its an admitted bug. Its still dumb from the users standpoint
which is all I was trying to say : >