Re: Problems building universal binaries using -isysroot
Re: Problems building universal binaries using -isysroot
- Subject: Re: Problems building universal binaries using -isysroot
- From: Tron Thomas <email@hidden>
- Date: Sat, 15 Apr 2006 11:08:52 -0700
I think this is definitely a bug. It seems to work around the problem,
any executable that links to a dynamic library that also links to 3rd
party libraries located in /usr/local/lib has to explicitly link to
those 3rd party libraries as well. This was never required when
building for a specific architecture. I don't see why it should be a
requirement for building universal binaries. /usr/local/lib doesn't
even exist on a default system that a person would purchase from Apple.
That directory seems to be meant to install custom 3rd party software.
It should not be part of the SDK root.
Finlay Dobbie wrote:
On 14/04/06, Peter O'Gorman <email@hidden> wrote:
I'd be inclined to disagree. /usr/lib /lib and /usr/local/lib are all in
the "system" search paths for the linker. When you specify an new system
root, surely all the system search paths should be changed. For
directories outside the standard framework and library search paths,
they are only used if they exist in the new root. This seems perfectly
legitimate to me.
On the other hand, when you specify an SDK you're just specifying an
SDK representing a certain version of the system libraries, headers
and frameworks. /usr/local/lib is obviously not supplied by the
system, so it doesn't really make sense to treat it as part of the
SDK...
The fact that SDKs are implemented by changing the root for the system
search paths in the compiler and linker is somewhat incidental to most
people's high-level goals.
It all depends on how you look at it, as Eric mentioned ;-)
-- Finlay
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden