This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: egcs-1.1b/Solaris 2.5.1: problems with version numbers in dynamic libraries
- To: law at cygnus dot com
- Subject: Re: egcs-1.1b/Solaris 2.5.1: problems with version numbers in dynamic libraries
- From: papadopo at shfj dot cea dot fr (Dimitri PAPADOPOULOS-ORFANOS)
- Date: Fri, 11 Sep 1998 14:57:11 +0200
- Cc: egcs-bugs at cygnus dot com
> In message <199809081540.RAA13516@orcanie.shfj.cea.fr>you write:
> > I have problems using dynamic libraries with version numbers.
> > Here is a small exeample with a dynamic library "library"
> > version 1.0 and a program "exe" which tries to use it:
> > % g++ -fpic -c exe.cc
> > % g++ -fpic -c library.cc
> > % g++ -shared -o liblibrary.so.1.0 library.o
> > % ln -s liblibrary.so.1.0 liblibrary.so
> > % g++ -o exe exe.o -L/home/papadopo/TOTO -llibrary
> > %
> >
> > The problem is that "exe" is linked against "liblibrary.so"
> > instead of "liblibrary.so.1.0":
> > % ldd exe
> > liblibrary.so => ./liblibrary.so
> > [...]
> > %
> >
> > This was not the case with egcs-1.0.2:
> > % ldd exe
> > liblibrary.so.1.0 => ./liblibrary.so.1.0
> > [...]
> > %
> >
> > The program won't run unless "liblibrary.so" is in the
> > LD_LIBRARY_PATH. "liblibrary.so.1.0" won't do.
> >
> > Is this a bug? Am I missing something?
> This seems more like a linker issue. egcs does not (to the best of
> my knowledge) only specifies -llibrary to the linker and it is up to
> the linker to select the appropriate library.
The problem is not with `-llibrary', but with `-shared'.
Let me expand on the subject.
I have found that gcc-2.8.1 and egcs-1.1 share the same problem
with version numbers of dynamic libraries, while egcs-1.0.2 does
not. I understand that gcc-2.8.1 and egcs-1.1 share common new
code (`gcc2'?), while egcs-1.0.2 still relies on old code.
So there has to be a problem here.
Investigating further, I also found that in the sequence
% g++ -fpic -c exe.cc
% g++ -fpic -c library.cc
% g++ -shared -o liblibrary.so.1.0 library.o
% ln -s liblibrary.so.1.0 liblibrary.so
% g++ -o exe exe.o -L<LIBDIR> -llibrary
the problem is in the 3rd command `g++ -shared'.
Indeed, if I use egcs-1.1 to execute all the commands but the
3rd one and egcs-1.0.2 to execute the 3rd one, everything's
fine:
% env LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ldd exe
library.so.1.0 => ./library.so.1.0
[...]
If I change to egcs-1.1 to execute the 3rd command, version
numbers are not taken into account:
% env LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ldd exe
library.so => ./library.so
[...]
Please note that my PATH contains
/usr/ucb
before
/usr/ccs/bin
I read in the GCC manual:
* On Solaris, do not use the linker or other tools in `/usr/ucb' to
build GNU CC. Use `/usr/ccs/bin'.
* On Solaris 2, trying to use the linker and other tools in
`/usr/ucb' to install GNU CC has been observed to cause trouble.
For example, the linker may hang indefinitely. The fix is to
remove `/usr/ucb' from your `PATH'.
The same goes for LD_LIBRARY_PATH which contains `/usr/ucblib'.
Our system manager has probably good reasons (I hope) for keeping
it that way. I guess we have legacy SunOS code that may need
`/usr/ucb' or `/usr/ucblib'.
Anyway, this `/usr/ucb' stuff shouldn't be a problem, as `g++' is
not supposed to look in `/usr/ucb' for `ld':
% gcc -print-search-dirs | fgrep '^programs:'
programs: /usr/local/egcs-1.1b/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.57/:/usr/local/egcs-1.1b/lib/gcc-lib/sparc-sun-solaris2.5.1/:/usr/lib/gcc/sparc-sun-solaris2.5.1/egcs-2.91.57/:/usr/lib/gcc/sparc-sun-solaris2.5.1/:/usr/local/egcs-1.1b/sparc-sun-solaris2.5.1/bin/sparc-sun-solaris2.5.1/egcs-2.91.57/:/usr/local/egcs-1.1b/sparc-sun-solaris2.5.1/bin/:/usr/ccs/bin/sparc-sun-solaris2.5.1/egcs-2.91.57/:/usr/ccs/bin/
What has changed in the way `g++' handles the `-shared' option?
Should I build dynamic libraries in some other way?
Thank you.
--
Dimitri Papadopoulos