Re: MAC OS X, static compilation and libtool

[Peter O'Gorman]

Bob Friesenhahn wrote:
> On Tue, 18 Mar 2008, Peter O'Gorman wrote:
>>
>> If linking libtool libraries, then libtool should add the full path to
>> the static archive (e.g. ../foo/libfoo.a) when calling the linker. This
>> will overcome even the OS X linker which searches all -L paths for a
>> dylib before going back to the start again looking for a .a.
>>
>> Feel free to add -Wl,-search_paths_first to LDFLAGS if $host is darwin*.
>>
>> I am not sure that this should be handled in libtool, I'd be fine with
>> adding it by default if another maintainer agrees.
> 
> I have always thought that libtool is doing the right thing.  Most
> system linkers will choose a shared library over a static library unless
> special options or a full path is provided.
> 
> Is it possible that this reported problem could be due to a project
> issue?  For example, is it possible that the libraries are being built
> in the wrong order so that the library is not available when it is
> needed to link the application?  This would cause libtool to find the
> already installed library.

Hi Bob,

Mac OS X has a special linker, it searches for libraries differently. If
you do, e.g.

cc -o foo -LA -LB -lbar

The linker will look for A/libbar.dylib, B/libbar.dylib, A/libbar.a
B/libbar.a, stopping at the first one it finds. Adding
-Wl,-search_paths_first makes it look for A/libbar.dylib, A/libbar.a,
B/libbar.dylib, B/libbar.a, which is more in line with what the
developer expects.

I do not know if there is a case for adding this flag to the default
linker flags for libtool on Mac OS X (if it is available, iirc it became
available in Mac OS X 10.2 or thereabouts), the user or developer can
easily add it to LDFLAGS if it turns out to be required, and I think
libtool does the right thing in most/all cases anyway.

Peter
-- 
Peter O'Gorman
http://pogma.com