Re: Solaris 7/x86 shared libgcc?

[Ben Taylor <bent at clark dot net>]

On Mon, 6 Mar 2000, Bryan W. Headley wrote:

Thanks to everyone for all the tips.  Just wanted to relay what I found
out.

1)  It turns out I had an link to an older version libstdc++.so.0.2.8,
    but this made no difference once I fixed it.
2)  The libtool just will not allow a statically linked library to 
    be involved in the creation of a shared library.
3)  I got a suggestion to manually create a shared object, so I compiled
    libgcc2.c with the appropriate flags to generate __divdi3.lo
4)  I finally got a valid link phase which ran (yippee) by
    adding -R/usr/local/lib -L/usr/local/lib -lstdc++ to LDFLAGS, as well
    as the shared object for __divdi3.

At this point, I still think that gcc should include a shared libgcc as
well as a statically linked one.

Ben

> Ben Taylor wrote:
> 
> > I am trying to build a shared library module, which eventually will
> > be used with xmms.
> >
> > When I don't link with libgcc.a, I get the following error on startup:
> >
> > ld.so.1: xmms: fatal: relocation error: file
> > /usr/local/lib/xmms/Input/libmodplug.so: symbol __divdi3: referenced
> > symbol not found
> >
> > When I link with libgcc.a, the shared library won't build because
> > libgcc.a is a statically linked library.  Unfortunately, this means
> > that at runtime the module can't be loaded by xmms.
> >
> > Any ideas on how to either build a shared libgcc, or send flags to
> > the compiler to prevent it from using the __divdi3 call?
> 
> Your problem is pretty strange and suggests that the compiler itself is
> not functional (e.g., the gcc binary suite and the attendant libgcc are
> from different versions, especially a gcc that's 2.8x and lower, versus
> an egcs 1.0/ gcc 2.9x and greater)
> 
> Except: I've seen this before, and interestingly enough, on an UltraSparc
> before.  Question: are all of the libraries and object files that you are
> linking into this product built by the same version of gcc/egcs? I ask
> that because a lot of calls to the libgcc.a library are made by code IN
> your shared libraries. A lot of the compiler internals changed between
> 2.8x and the egcs/2.9x series, so if you have a library built by an older
> gcc, it's the contributant. If you can, do a fresh compile of everything
> that's gcc-touched in your project. If there's stuff you CAN'T recompile,
> e.g., proprietary vendor stuff, THEN the fun begins (I've been there
> before, and made some fake functions like your __divdi3 -- nothing more
> scary than faking the exception handling internals between 2.72 and 2.96
> gcc -- which is what I got trapped on -- even though neither my code nor
> theirs' threw exceptions)
> 
> 
> --
> Bryan W. Headley                     Phone: 312/913-9158
> Chief Technology Officer             Fax:   312/913-9155
> Prisma & Company                     Email: bheadley@prismalink.com
> 
> 
>