Re: Linking behavior for dylibs without the lib prefix
Re: Linking behavior for dylibs without the lib prefix
- Subject: Re: Linking behavior for dylibs without the lib prefix
- From: Gabriele de Simone <email@hidden>
- Date: Wed, 11 Jan 2006 16:13:52 -0500
Thanks Eric,
You cleared out a lot of doubts for me, but I must ask you to please
take a look at Radar bug # 4389346 again, after reading below.
I believe that there is a combination of steps that makes it
impossible to link against a library unless it follows the
lib<x>.dylib naming convention. This problem does *not* arise if you
drag a dylib to your project directly, because, as you point out,
Xcode passes the full path to the library in the invocation command.
The problem does arise if the dylib is made part of the link phase as
the build result of a dependent project. If you:
1) add a dependent project that generates a dylib, and this dependent
project does *not* share the same SYMROOT with its parent
2) add the dylib to the link phase (by clicking the disclosure
triangle next to the dependent project, and adding the dylib it
generates to your target)
then the linker may never be able to find the library, no matter what
extra configuration steps you're willing to do. If the library
happens to use the lib<x>.dylib naming convention, you can fix the
linker errors by adding the proper path to the "Library Search
Paths" (-L) build setting. But if your library does not follow this
naming convention, there's no way to point Xcode to the right path,
since the -L setting seems only to affect the libraries that are
linked in via -l.
If true, this bug is a shortcoming of the Xcode build system for
people who tend to use sub-projects often.
If only Xcode were smart enough to find (and specify) the full path
to a dependent project's output... after all, all the info it needs
is right there...
The universal solution appears to always build libraries with the lib
prefix and/or to share the SYMROOT among all of your projects. I'm
sure there must be some another workaround that involves messing
around with build settings and manually constructing the right path.
But this is 2006, and it would be really nice if things like this
just worked.
Thanks
Gabe
On Jan 11, 2006, at 2:42 PM, Eric Albert wrote:
On Jan 11, 2006, at 10:41 AM, Gabriele de Simone wrote:
There's been lots of (useful) talk on dynamic libraries, but there
is one issue I have personally been unable to understand from the
docs or from this list.
How is linking against a dynamic library that does not have the
canonical "lib" prefix any different than linking against one
with the proper name?
So far, I have collected the following info: the library is not
linked via the -l<someLibrary> argument, and the full path to the
library is passed in.
Does linking work the same even if the library is not specified as
part of a -l argument?
Yes. As far as the linker's concerned, no matter how you've
specified a library everything's the same.
And if the dylib is not linked via the -l argument, does the
"Library Search Paths" build setting (-L) still have any effect?
I'm not sure, but I suspect not. I'm afraid I don't know what
Xcode does for this case today, but it should pass the full path to
the library to the linker. Then -L wouldn't matter, but the
library you've added to the project would be the one linked in.
-Eric
_______________________________________________
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