shared libraries on Solaris (and other SVR4 systems?)

[Dimitri PAPADOPOULOS-ORFANOS]

Alexandre Oliva <oliva@dcc.unicamp.br> writes:

> Dimitri PAPADOPOULOS-ORFANOS <papadopo@shfj.cea.fr> writes:
>
> > Using egcs-1.0.2, the linker links with libfoo.so.1.0.
> > Using egcs-1.1, the linker links with libfoo.so.
> > Of course, the program should always link against libfoo.so.1.0.
> 
> Why?  IMO, egcs should follow whatever standard the underlying OS
> defines.  If the standard linker looks for libfoo.so, so should egcs
> and GNU binutils.  If a library does not have a soname (-h), the
> standard library name should be recorded in the program linked with
> it.

You're right. I looked at Sun's CC compiler: it links with libfoo.so
instead of libfoo.so.1.0. A `-h' flag can be used to `assign a name
to a shared dynamic library and record the name in the library file'.

> Shared libraries are not as portable as you may think.  The only way
> to create libraries in a reasonably portable way is to use GNU
> libtool.

Again you're right.
But I don't want to create libraries in a portable way.
I just want to work on my project on the OS I happen to use, like
I did in the past.

> > * in egcs-1.0.2 `ld' is called with option `-h libfoo.so.1.0'
> >   and option `-o libfoo.so.1.0'
> > * in egcs-1.1 `collect2' is called with option `-o libfoo.so.1.0'
> >   only
> 
> IMO, egcs 1.0.2 is wrong, there's no reason to force the `-h' flag.

Don't get me wrong, I agree with you. And I know it is easier to
maintain a well-written program that does not mess with OS issues.

But I could say as well:
IMO, egcs 1.1b is wrong, there's no reason to remove the `-h' flag.

We had a working compiler which could create shared libraries.
Then it was changed. What's so wrong with this `-h' flag? I see
more and more of these `theoretically sound' features in egcs; the
result is that the compiler is getting more and more perfect, but
also more and more difficult to use in real world situations:
* undocumented (correct me if I'm wrong) changes in the way shared
  libraries are handled
* useless options choke on libstdc++ headers such as `-Weffc++' or
  on system headers such as `-Wall' - of course Sun's system headers
  are broken, but I don't know of any OS that doesn't have broken
  headers and I am (usually) not interested in fixing them
* undocumented but important options need hours of adjustment to
  work such as `-fsquangle' (`-fsquangle' should really be handled
  within `configure', modifying the top-level Makefile and adding
  an option flag in the specs)
May I suggest you read this article:
	http://www.heise.de/ct/english/98/18/003/

Thanks to the EGCS team for their excellent work,
--
Dimitri