shared libraries on Solaris (and other SVR4 systems?)

[Alexandre Oliva]

Dimitri PAPADOPOULOS-ORFANOS <papadopo@shfj.cea.fr> writes:

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

Yep.  egcs, as most of the GNU suite, is supposed to be a good
replacement for proprietary tools, as compatible with them as
reasonable.  Since Sun's CC does not pass the `-h' switch to the
linker, egcs shouldn't either, it's that simple.  Why should we create 
yet another source of problems?

> I just want to work on my project on the OS I happen to use, like
> I did in the past.

You were just lucky that you didn't have to create the usual soft-link 
to point to the library name.  In fact, some people just forget about
version numbers and create libraries named libfoo.so, so that no link
is needed.  A better approach would be to create libfoo.so.1.0 -h
libfoo.so.1 so that, when you release a new version of your library
that is backward binary-compatible with the previous release, you can
name it libfoo.so.1.1 -h libfoo.so.1.  Then, when you modify the link
named libfoo.so.1, the new release will be used.

> And I know it is easier to maintain a well-written program that does
> not mess with OS issues.

That's exactly the opposite: trying to be as similar as possible with
dozens of different, brain-damaged and mutually incompatible operating
systems is very hard, and that's why some bug like the unexpected
presence of -h in the link specs slips through.  

> We had a working compiler which could create shared libraries.

You still have it, don't you?  Or did you remove it? :-)

> Then it was changed. What's so wrong with this `-h' flag?

It's different from the behavior of the standard tools of Solaris.

> * undocumented (correct me if I'm wrong) changes in the way shared
>   libraries are handled

Did you look at the ChangeLog?  I didn't :-)

> * 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)

They're undocumented because they're not ready for public consumption.
If you're willing to *test* them (note, I'm not talking about *using*
them), then you're a gcc hacker (welcome to the team :-), and you
should know what you're doing.

> 	http://www.heise.de/ct/english/98/18/003/

Thanks for the suggestion, I'll take a look at it.

> Thanks to the EGCS team for their excellent work,

Thanks for your input :-)

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil