This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: egcs-1.1b/Solaris 2.5.1: problems with version numbers in dynamic libraries


>  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]