bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MAC OS X, static compilation and libtool


From: Peter O'Gorman
Subject: Re: MAC OS X, static compilation and libtool
Date: Tue, 18 Mar 2008 00:40:59 -0500
User-agent: Thunderbird 2.0.0.9 (X11/20071115)

George Bosilca wrote:
> I run into some troubles with the latest version of libtool (2.2). I
> didn't notice this problem with older libtool versions, but a coworker
> confirm it with 1.5.22. To be honest I don't know if it's a libtool
> problem or a MAC OS X, or whatever.
> 
> The problem is when I compile an application with a libtool enabled
> library (Open MPI for the sake of completeness). This only happen when
> the library is compiled with the "--enable-static --disable-shared", all
> other cases seems to perform as expected. By default libtool propose
> some linking flags that seems sufficient on most Unix environments,
> except on MAC OS X. For some obscure reasons, MAC OS X always try to
> link with shared libraries based on the default path (and Open MPI is
> shipped by Apple with Leopard), instead of following the -L path as
> specified by the user on the link command.
> 
> After digging into the gcc man pages, I found that in order to have the
> expected behavior (or at least what I think is expected: look into the
> user provided lib path for all libraries independing if they are static
> or dynamic) one has to add the -Wl,-search_paths_first flags to the link
> command. From the gcc documentation, it seems that this is not
> necessarily MAC OS X specific (but I didn't test it elsewhere).
> 
> I was pondering if I should add a special check in our configure for
> detecting this case or there is a nicer libtool based way of handling this.

[All mentions of libtool below are for GNU libtool, not Apple's
/usr/bin/libtool]

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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]