Link with library of exact filename (i.e. exact version)

[Frederick Gotham]

Let's say I have a single-source-file program that I want to link with a library called "monkey" that resides in the current directory, and so I compile it like this:

g++ -o prog main.cpp -L./ -lmonkey

Next let's say that I want to specify the exact filename for the library "monkey" because I want an exact version of it, like so:

g++ -o prog main.cpp -L./ -l:libmonkey.so.1.2.0

(This means that I want version 1.2.0 and that I want to link dynamically with an "so" file instead of linking statically with a "a" file)

If I compile this program on my Linux computer (x86_64), and then if I run "ldd" on the executable file, I get this:

libmonkey.so.1 => /usr/lib/libmonkey.so.1 (0x0000007f7d5e0000)

If I check my file system, I see that there are three files beginning with "libmonkey.so", as follows:

-rwxr-xr-x 1 root root 30.1K Jul 6 2020 ./libmonkey.so.1.0.3
-rwxr-xr-x 1 root root 34.2K Jul 6 2020 ./libmonkey.so.1.2.0
lrwxrwxrwx 1 root root 15 Feb 11 22:14 ./libmonkey.so.1 -> libmonkey.so.1.2.0

So the are two fully-fledged files:
libmonkey.so.1.0.3
libmonkey.so.1.2.0

And then there is a symbolic link called "libmonkey.so.1" which points to the more recent library.

The problem here is that I don't want my executable file, "prog", to depend on "libmonkey.so.1". Instead, I want it to depend on "libmonkey.so.1.2.0". For some strange reason, the GNU linker is specifying the dependency as ".1" instead of ".1.2.0".

How do I get the linker to keep the full library name?

[Siri Cruise]

In article
<f6b620fb-562c-426f...@googlegroups.com>,

Frederick Gotham <cauldwel...@gmail.com> wrote:

> g++ -o prog main.cpp -L./ -l:libmonkey.so.1.2.0

>> How do I get the linker to keep the full library name?

Doesn't this work?
g++ -o prog main.cpp ./libmonkey.so.1.2.0

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
The first law of discordiamism: The more energy This post / \
to make order is nore energy made into entropy. insults Islam. Mohammed

[Frederick Gotham]

On Tuesday, July 7, 2020 at 1:12:30 PM UTC+1, Siri Cruise wrote:

> Doesn't this work?
> g++ -o prog main.cpp ./libmonkey.so.1.2.0

I tried that aswell but I got the same result.

[Fred. Zwarts]

Op 07.jul..2020 om 11:53 schreef Frederick Gotham:

I do not see a C++ question. Probably a group for your operating Linux
system can help you better.

--
Paradoxes in the relation between Creator and creature.
<http://www.wirholt.nl/English>.

[Kenny McCormack]

In article <re1uu4$hbt$1...@gioia.aioe.org>, Fred. Zwarts <F.Zw...@KVI.nl> wrote:
...

>I do not see a C++ question. Probably a group for your operating Linux
>system can help you better.

What is an operating Linux system?

--
The last time a Republican cared about you, you were a fetus.

[Fred. Zwarts]

Op 07.jul..2020 om 16:46 schreef Kenny McCormack:

> In article <re1uu4$hbt$1...@gioia.aioe.org>, Fred. Zwarts <F.Zw...@KVI.nl> wrote:
> ...
>> I do not see a C++ question. Probably a group for your operating Linux
>> system can help you better.
>
> What is an operating Linux system?
>

Sorry, the sorting of the words in the sentence used an incorrect
algorithm. 😉

[Cholo Lennon]

Maybe you need to specify the RPATH option (but be aware that it will
hardcode the library path inside the executable. The option may not be
helpful if you distribute your binaries instead of your source code)

https://en.wikipedia.org/wiki/Rpath

Regards

--
Cholo Lennon
Bs.As.
ARG

[Manfred]

As others have said, this is not a C++ question, rather it is a
[dynamic] linker question instead, and it is specific to the
implementation you use (since you refer to gcc this is most probably the
GNU linker).
However you may want to check the referenced SONAME in the executable.
Usually the GNU linker puts the SONAME of the shared library in the
executable, and at runtime the dynamic linker loads the shared library
by SO_NAME rather than by filename (see ld -soname).

Documentation of the GNU linker:
https://sourceware.org/binutils/docs-2.34/ld/

[Frederick Gotham]

On Tuesday, July 7, 2020 at 6:57:16 PM UTC+1, Manfred wrote:

> However you may want to check the referenced SONAME in the executable.
> Usually the GNU linker puts the SONAME of the shared library in the
> executable, and at runtime the dynamic linker loads the shared library
> by SO_NAME rather than by filename (see ld -soname).

I haven't investigated into this fully but I think you're right, Manfred. I used the program "patchelf" to change the "soname" inside my ".so" file, and now when I link with it, the resultant executable file is dependent upon the full filename.

Alternatively, and in similar fashion to "patchelf", I could have just altered a 5 - 10 bytes in the resultant binary to get it to look a file with a longer filename.

By the way, does anyone know if these two lines do exactly the same thing on Linux?

g++ -o prog main.cpp -L./ -l:libmonkey.so

g++ -o prog main.cpp ./libmonkey.so

From what I can see so far, these two commands are identical in effect.

[Manfred]

On 7/8/2020 2:32 PM, Frederick Gotham wrote:
> On Tuesday, July 7, 2020 at 6:57:16 PM UTC+1, Manfred wrote:
>
>> However you may want to check the referenced SONAME in the executable.
>> Usually the GNU linker puts the SONAME of the shared library in the
>> executable, and at runtime the dynamic linker loads the shared library
>> by SO_NAME rather than by filename (see ld -soname).
>
>
> I haven't investigated into this fully but I think you're right, Manfred. I used the program "patchelf" to change the "soname" inside my ".so" file, and now when I link with it, the resultant executable file is dependent upon the full filename.

If you are compiling and linking the .so yourself, then you'd probably
better use the "-soname" ld option rather than patching the binary
afterwards - if it is a 3rd party project, it is probably a good idea to
suggest this to the maintainer.

>
> Alternatively, and in similar fashion to "patchelf", I could have just altered a 5 - 10 bytes in the resultant binary to get it to look a file with a longer filename.
>
> By the way, does anyone know if these two lines do exactly the same thing on Linux?
>
> g++ -o prog main.cpp -L./ -l:libmonkey.so
>
> g++ -o prog main.cpp ./libmonkey.so
>
> From what I can see so far, these two commands are identical in effect.
>

I would guess so, anyway the documentation of both gcc and ld is usually
pretty accurate, so if you want to be sure better check "info gcc" and
"info ld" (or man gcc, man ld)
If you find some inconsistency, usually bug reports do get consideration
on these projects - note that ld is part of binutils.
(BTW I think there is one between the manpages of ld and ld.so on this
very topic)

[Frederick Gotham]

On Wednesday, July 8, 2020 at 2:03:11 PM UTC+1, Manfred wrote:

> If you are compiling and linking the .so yourself, then you'd probably
> better use the "-soname" ld option rather than patching the binary
> afterwards - if it is a 3rd party project, it is probably a good idea to
> suggest this to the maintainer.

We contact the maintainer at most once a week and only when absolutely necessary. Furthermore the maintainer didn't intend for us to use multiple versions of the same library, so they probably like the "soname" that they currently are using.

As "patchelf" seems to work fine for my needs, this is the best option.

[James Kuyper]

On 7/8/20 9:02 AM, Manfred wrote:
> On 7/8/2020 2:32 PM, Frederick Gotham wrote:

...

>> By the way, does anyone know if these two lines do exactly the same thing on Linux?
>>
>> g++ -o prog main.cpp -L./ -l:libmonkey.so
>>
>> g++ -o prog main.cpp ./libmonkey.so
>>
>> From what I can see so far, these two commands are identical in effect.
>>
>
> I would guess so, anyway the documentation of both gcc and ld is usually
> pretty accurate, so if you want to be sure better check "info gcc" and
> "info ld" (or man gcc, man ld)
> If you find some inconsistency, usually bug reports do get consideration
> on these projects - note that ld is part of binutils.
> (BTW I think there is one between the manpages of ld and ld.so on this
> very topic)

-L./ adds ./ to the list of locations that are searched for libraries.
-l:libmonkey.so tells it to look in the current list of locations for a
library named libmonkey.so.

Using ./libmonkey.so searches only for ./libmonkey.so

These two commands can do different things (depending upn the context)
for couple of reasons:
A. The -L option affects all subsequent library searches, not just this one.
B. the -l option causes other places to be searched for the library, not
just ./