Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2013-02

link search order

8 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Vittorio Giovara

Hi,
I'm using fpc and trying to link it with a library, let's call it libfoo version 2.

The problem I'm facing is that many people have libfoo 1.0 installed and that when linking, fpc takes libfoo 1.0 instead of the new libfoo 2.0. Of course this causes a link failure as I need many libfoo version 2 functions.

I set the right library search path but the system search path gets always picked first (confirmed by ).
Is there a way to force the order of search path (possibly without modifying fpc.cfg or playing with linker flags)?

Thanks,
Vittorio

Reply by email

Tomas Hajny
to Vittorio Giovara

On Fri, February 22, 2013 10:59, Vittorio Giovara wrote:

Hi,

Show quoted text 12 lines
I'm using fpc and trying to link it with a library, let's call it libfoo version 2. The problem I'm facing is that many people have libfoo 1.0 installed and that when linking, fpc takes libfoo 1.0 instead of the new libfoo 2.0. Of course this causes a link failure as I need many libfoo version 2 functions. I set the right library search path but the system search path gets always picked first (confirmed by ). Is there a way to force the order of search path (possibly without modifying fpc.cfg or playing with linker flags)?

You don't provide much information about your situation, but I assume that you talk about Linux here. If you need version 2, you may need to link explicitly to libfoo.2.so rather just libfoo.so. If you link to libfoo.so and this is expected to be a symbolic link to the latest installed version, you may also want to check why people having both libfoo 1.0 and libfoo 2.0 installed do not have the symbolic link pointing to the later version. One such reason may be not having the development version of the respective library installed (at least this may be the case on some Linux distributions as far as I know).

Tomas

Reply by email

Vittorio Giovara
to Tomas Hajny

Hi,
yes I was talking about linux. I didn't include much information because I didn't want to confuse people with details.

In this branch of Hedgewars
https://code.google.com/p/hedgewars/source/list?name=physfslayer we are using physfs library version 2.1.0.
However many people out there have version 2.0.3 installed and (of course) it doesn't contain many of the APIs present in 2.1.0. So when libphysfs is not found (or an old one is detected) we provide a copy of the right physfs and have CMake (our build system) compile and install it. However even if I hardcode the right path of the right library of the right version, the installed system library takes precedence, and thus if another version of physfs is installed, hedgewars doesn't link any more.

I would refrain from using a different library name; looking at the generated link.res file it seems that the first lib search path is /urs/lib and /lib and the custom one (where the right libphysfs resides) is found only later on. Is there a way to prevent this? I tried to play with the -Xd flag but the result didn't change.

Any help is appreciated.
Vittorio

Tomas Hajny wrote 36 lines
On Fri, February 22, 2013 10:59, Vittorio Giovara wrote: Hi, > I'm using fpc and trying to link it with a library, let's call it libfoo > version 2. > > The problem I'm facing is that many people have libfoo 1.0 installed and > that when linking, fpc takes libfoo 1.0 instead of the new libfoo 2.0. Of > course this causes a link failure as I need many libfoo version 2 > functions. > > I set the right library search path but the system search path gets always > picked first (confirmed by ). > Is there a way to force the order of search path (possibly without > modifying fpc.cfg or playing with linker flags)? You don't provide much information about your situation, but I assume that you talk about Linux here. If you need version 2, you may need to link explicitly to libfoo.2.so rather just libfoo.so. If you link to libfoo.so and this is expected to be a symbolic link to the latest installed version, you may also want to check why people having both libfoo 1.0 and libfoo 2.0 installed do not have the symbolic link pointing to the later version. One such reason may be not having the development version of the respective library installed (at least this may be the case on some Linux distributions as far as I know). Tomas _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Tomas Hajny
to Vittorio Giovara

On Fri, February 22, 2013 16:33, Vittorio Giovara wrote:

Hi,

Show quoted text 22 lines
yes I was talking about linux. I didn't include much information because I didn't want to confuse people with details. In this branch of Hedgewars https://code.google.com/p/hedgewars/source/list?name=physfslayer we are using physfs library version 2.1.0. However many people out there have version 2.0.3 installed and (of course) it doesn't contain many of the APIs present in 2.1.0. So when libphysfs is not found (or an old one is detected) we provide a copy of the right physfs and have CMake (our build system) compile and install it. However even if I hardcode the right path of the right library of the right version, the installed system library takes precedence, and thus if another version of physfs is installed, hedgewars doesn't link any more. I would refrain from using a different library name; looking at the generated link.res file it seems that the first lib search path is /urs/lib and /lib and the custom one (where the right libphysfs resides) is found only later on. Is there a way to prevent this? I tried to play with the -Xd flag but the result didn't change.

I don't know enough about the library path setting (I leave commenting on this to others). However, if you require a specific version number of a library (and even distribute that version with your code), explicitly linking to that library version seems to be the appropriate solution from my point of view. Another option may be linking the respective library statically.

Tomas

Reply by email

Marco van de Voort
to Vittorio Giovara: I'm using fpc and trying to link it with a library, let's call it libfoo version 2. The…

In our previous episode, Vittorio Giovara said:

Show quoted text 11 lines
I'm using fpc and trying to link it with a library, let's call it libfoo version 2. The problem I'm facing is that many people have libfoo 1.0 installed and that when linking, fpc takes libfoo 1.0 instead of the new libfoo 2.0. Of course this causes a link failure as I need many libfoo version 2 functions. I set the right library search path but the system search path gets always picked first (confirmed by ). Is there a way to force the order of search path (possibly without modifying fpc.cfg or playing with linker flags)?

Pass -Xd and then your own list of libraries with various -Fl?

Without -Xd some defaults are emitted first.

Reply by email

Vittorio Giovara
to Marco van de Voort
Marco van de Voort wrote 16 lines
In our previous episode, Vittorio Giovara said: > I'm using fpc and trying to link it with a library, let's call it libfoo > version 2. > > The problem I'm facing is that many people have libfoo 1.0 installed and > that when linking, fpc takes libfoo 1.0 instead of the new libfoo 2.0. Of > course this causes a link failure as I need many libfoo version 2 functions. > > I set the right library search path but the system search path gets always > picked first (confirmed by ). > Is there a way to force the order of search path (possibly without > modifying fpc.cfg or playing with linker flags)? Pass -Xd and then your own list of libraries with various -Fl? Without -Xd some defaults are emitted

I've tried setting -Xd and then -Fl/path/to/right/lib but the system library is picked first nevertheless.
Plus I need to have the system path in the search path, just in a different order, otherwise I'd have to hardcore different paths for every possible arch out there...

Vittorio

Reply by email

Vittorio Giovara
to Tomas Hajny: I don't know enough about the library path setting (I leave commenting on this to…
Tomas Hajny wrote 34 lines
On Fri, February 22, 2013 16:33, Vittorio Giovara wrote: Hi, > yes I was talking about linux. I didn't include much information because I > didn't want to confuse people with details. > > In this branch of Hedgewars > https://code.google.com/p/hedgewars/source/list?name=physfslayer we are > using physfs library version 2.1.0. > However many people out there have version 2.0.3 installed and (of course) > it doesn't contain many of the APIs present in 2.1.0. > So when libphysfs is not found (or an old one is detected) we provide a > copy of the right physfs and have CMake (our build system) compile and > install it. However even if I hardcode the right path of the right library > of the right version, the installed system library takes precedence, and > thus if another version of physfs is installed, hedgewars doesn't link any > more. > > I would refrain from using a different library name; looking at the > generated link.res file it seems that the first lib search path is > /urs/lib > and /lib and the custom one (where the right libphysfs resides) is found > only later on. Is there a way to prevent this? I tried to play with the > -Xd > flag but the result didn't change. I don't know enough about the library path setting (I leave commenting on this to others). However, if you require a specific version number of a library (and even distribute that version with your code), explicitly linking to that library version seems to be the appropriate solution from my point of view. Another option may be linking the respective library

As mentioned, I've been doing only static builds so far. Plus I passed the linker (with -k) the full path of the library it should link, but the system one is somehow always dragged in and linked before my command takes effect.

Vittorio

Reply by email

Vittorio Giovara
to Vittorio Giovara

I've opened a bug regarding this
http://bugs.freepascal.org/view.php?id=23948 for better tracking this issue. Thanks for all the feedback received here.
Vittorio

On Sat, Feb 23, 2013 at 5:50 PM, Vittorio Giovara <

Show quoted text 50 lines
wrote: On 22/feb/2013, at 16:59, Tomas Hajny wrote: > On Fri, February 22, 2013 16:33, Vittorio Giovara wrote: > > > Hi, > >> yes I was talking about linux. I didn't include much information because I >> didn't want to confuse people with details. >> >> In this branch of Hedgewars >> https://code.google.com/p/hedgewars/source/list?name=physfslayer we are >> using physfs library version 2.1.0. >> However many people out there have version 2.0.3 installed and (of course) >> it doesn't contain many of the APIs present in 2.1.0. >> So when libphysfs is not found (or an old one is detected) we provide a >> copy of the right physfs and have CMake (our build system) compile and >> install it. However even if I hardcode the right path of the right library >> of the right version, the installed system library takes precedence, and >> thus if another version of physfs is installed, hedgewars doesn't link any >> more. >> >> I would refrain from using a different library name; looking at the >> generated link.res file it seems that the first lib search path is >> /urs/lib >> and /lib and the custom one (where the right libphysfs resides) is found >> only later on. Is there a way to prevent this? I tried to play with the >> -Xd >> flag but the result didn't change. > > I don't know enough about the library path setting (I leave commenting on > this to others). However, if you require a specific version number of a > library (and even distribute that version with your code), explicitly > linking to that library version seems to be the appropriate solution from > my point of view. Another option may be linking the respective library > As mentioned, I've been doing only static builds so far. Plus I passed the linker (with -k) the full path of the library it should link, but the system one is somehow always dragged in and linked before my command takes effect. Vittorio

Reply by email