Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to I deference symbolic links when linking?

58 views
Skip to first unread message

NoName

unread,
Mar 3, 2013, 7:00:37 PM3/3/13
to
I might be in the wrong ng; if so, please direct me accordingly.

My question is this: suppose I have a library a_lib.so.1.1, with the
symlinks a_lib.so.1 pointing to it, and a_lib.so pointing to a_lib.so.1,
just as they ought to be. I am compiling a program which compiles against
a_lib.so. How do I get the linker to link with a_lib.so.1.1 instead?

I ask because later I will upgrade a_lib.so.1.1 to a_lib.so.1.3, and,
though GNU guidelines dictate that it should, my program simply will not
work with a_lib.so.1.3, and segfaults. Which is a shame, because I have
a_lib.so.1.1 right there, but now a_lib.so.1 points to a_lib.so.1.3, and
the a_lib.so (which my program links against) points to a_lib.so.1.

Again, my question is: How do I get my program to link with a_lib.so.1.1
instead of a_lib.so?

--
dave
Sun Mar 3 19:50:40 AST 2013


Rob Windgassen

unread,
Mar 4, 2013, 5:32:18 PM3/4/13
to
Some background

http://unix.stackexchange.com/questions/475/how-do-so-shared-object-numbers-work

tells that link time the symbolic link is used to identify the (version of)
the library.

A small example goes like this with 3 small source files:

--- file lib1.c ---
int libfun(void) { return 1; }
--- end of file ---

--- file lib2.c ---
int libfun(void) { return 2; }
--- end of file ---

--- file prog.c ---
#include <stdio.h>

extern int libfun(void);

int main(void)
{
printf("libfun()=%d\n", libfun());
return 0;
}
--- end of file ---


And then build stuff like this:


gcc -fPIC -c lib1.c
gcc -shared -Wl,-soname,libmy.so.1.1 -o libmy.so.1.1 lib1.o

gcc -fPIC -c lib2.c
gcc -shared -Wl,-soname,libmy.so.1.2 -o libmy.so.1.2 lib2.o

gcc -c prog.c

# set up link for 1st lib
ln -sf libmy.so.1.1 libmy.so
gcc prog.o -L. -lmy -o prog1

# set up link for 2nd lib
ln -sf libmy.so.1.2 libmy.so
gcc prog.o -L. -lmy -o prog2

# remove symbolic link - no need during exec
rm libmy.so

# run stuff
prog1
prog2


Groetjes,

Rob

NoName

unread,
Mar 4, 2013, 7:08:06 PM3/4/13
to
Well, that simply does not answer my question, so I will give some
background:

I have a nice system compiled by hand, from source, and ... well, I have
broken it somewhat by upgrading a major system library. I want to prevent
this same mishap from recurring, so I will explain my problem, propose my
solution, and ask how to implement my solution.

I want to know how to make the linker dereference symbolic links when
compiling. For instance, gimp is linked to libglib-2.0.so.0, and
libpng15.so.15:

# ldd `which gimp`
<snip>
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb6f50000)
<snip>
libpng15.so.15 => /usr/lib/libpng15.so.15 (0xb6a5e000)
<snip>


However, I have several versions of libglib-2.0.so.0, and 2 of
libpng15.so.15:

# ls -l /usr/lib/{libglib-2.0.so.0,libpng15.so.15}*

/usr/lib/libglib-2.0.so.0 -> libglib-2.0.so.0.3303.0
/usr/lib/libglib-2.0.so.0.1300.0
/usr/lib/libglib-2.0.so.0.1800.4
/usr/lib/libglib-2.0.so.0.3200.0
/usr/lib/libglib-2.0.so.0.3303.0
/usr/lib/libpng15.so.15 -> libpng15.so.15.9.0
/usr/lib/libpng15.so.15.6.0
/usr/lib/libpng15.so.15.9.0

Gimp now segfaults when I try to save as a .PNG format, and several other
programs are sketchy too. So I want to rebuild my system; however, I
would like to avoid this pitfall. If I could, for instance, cause gimp to
link only to /usr/lib/libpng15.so.15.6.0 (or whatever version was, when
gimp was built), instead of whatever the most recent version of
libpng15.so.15 on my system is, then gimp will continue to work even after
I upgrade my libpng15.so.15, and whatever other libraries I need to
upgrade (for programs which need more recent versions of libraries, for eg.)

I know that GNU protocols specify that a minor version change
shouldn't break library compatibility, but in practice it is not
always so. So, my question is, how do I get my linker to dereference
symbolic links at compile time?



--
dave
Mon Mar 4 20:02:56 AST 2013


Rob Windgassen

unread,
Mar 5, 2013, 4:23:06 PM3/5/13
to
It seems that I wasn't clear enough, but it is all about the softlink
that is used during linking.
The name of the softlink doesn't need to match the name of the library,
it just has to start with 'lib' and end in '.so'.
In your case that should be something like (in a directory where you
have write access and can link your program):

$ ln -s /usr/lib/libpng15.so.15.6.0 libThatYouLike.so

and then link this one instead of default libpng15, e.g. something like

$ gcc <your object files> -L. -lThatYouLike <otherlibs> -o yourprog

The -L. allows for searching the libThatYouLike.so softlink in the
current directory wherever it is, and -lThatYouLike causes the generated
program to refer to the lib where the softlink libThatYouLike.so points
to, i.e. /usr/lib/libpng15.so.15.6.0


Groetjes,

Rob



NoName

unread,
Apr 1, 2013, 9:37:08 PM4/1/13
to
I'm rebuilding my whole world. Do you know of any easy way to
make gcc dereference ALL symlinks by default?

--
dave
Mon Apr 1 22:31:31 ADT 2013


Rob Windgassen

unread,
Apr 4, 2013, 1:24:28 PM4/4/13
to
Can you explain a bit more what problem you face and what you have in mind?

Groetjes,

Rob

0 new messages