Re: [Xcode-users] Linking static curl lib
Re: [Xcode-users] Linking static curl lib
- Subject: Re: [Xcode-users] Linking static curl lib
- From: Peter O'Gorman <email@hidden>
- Date: Wed, 26 Nov 2008 09:14:10 -0600
Rush Manbert wrote:
>
> On Nov 25, 2008, at 6:01 PM, Peter O'Gorman wrote:
>
>> David Cohn wrote:
>>> Chirs,
>>>
>>> Thanks for your help... something must be wrong here:
>>>
>>> Other Linker Flags: -l/My/Full/Path/libcurl.a
>>
>> Chris accidentally inserted the -l, just put /Full/Path/to/libcurl.a in
>> Other Linker Flags.
>>
>
> This is a sidetrack, but I ran across an example of this recently while
> examining what an open source project make was doing, and have wondered
> whether it could be beneficial to one of my projects.
>
> If we assume that the linker search would find the same static library
> as what is specified as /path/to/libstatic.a, is there any linker
> behavior difference if you specify a static library this way, rather
> than providing a linker search path and a -lname specification?
When you specify -lname, the linker searches all -L paths and the
standard library directories looking for libname.dylib[1], then, if it
failed to find it, starts again looking for libname.a. To change this
behavior, you can add the -search_paths_first linker flag, which will
look in each directory, first looking for libname.dylib, then libname.a.
Apple's linker currently does not have a flag to specify that you want
it to find libname.a first.
By giving the linker the path to the library (either
/path/to/libname.dylib or /path/to/libname.a), you have complete control
over what library is used, and do not have to rely on -L ordering etc.
There are issues of portability with this approach, some systems encode
different rpaths depending upon if the library was found with a -L path
search or was passed as a path/to/file. Passing ../relative/path/to/file
on HP-UX, for example, is an issue, as you end up with a relative path
in the search path for the library at run time.
Peter
[1] ld actually looks for libname.dylib and libname.so.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden