I have a library that is being delivered to me as portable source code
that I build by doing configure, make, make install. The person who is
delivering this library to me has a linux background. I have a Mac
background.
The result of this is that I get several versions of the library.
There is a .dylib version, a .la version, and a .a version. Then,
there are two alias (or perhaps a symbolic link? I'm not sure what the
difference is.) files created that are both .dylibs with different
names. The "make install" command causes these to be placed into
/usr/local/lib
As Art mentioned, these are almost certainly symlinks. You typically
end up with symlinks for a dynamic library when it's built with a
version number hardcoded into its name but you want people to be able
to link against the version-less name for binary compatibility reasons.
For example, here's what libcups has in /usr/lib on my 10.3.9 system:
Ithilien:/usr/lib> ls -l libcups.*
-rwxr-xr-x 1 root wheel 106872 5 Jul 09:36 libcups.2.dylib*
lrwxr-xr-x 1 root wheel 15 20 Dec 2003 libcups.dylib@ ->
libcups.2.dylib
Also, I'm noting a weird behavior. When I build my app, it will link
to the .dylib unless I delete the libraries from /usr/local/lib and
copy the .a file into my project. In that case, otool does not show a
dependency on the .dylib. However, if I run the app on a machine where
these files exist in /usr/local/lib, it will use the version of the
library from that directory. Why does this happen? How can I avoid
this? I want it to always use my static library.
The easiest thing to do is to not build the dynamic library version at
all. You can often do that with configure scripts by running
'./configure --disabled-shared'. Oh, and delete the /usr/local/lib bit
first. :)
If that doesn't work, just don't run 'make install'. In other words,
do a configure and make, then copy the .a to wherever you want, run
ranlib on it, and leave things like that.
The reason why you're seeing the dylib being linked even though you add
the .a to the project is that on Mac OS X, when you pass -lLibraryName
to the linker, the linker defaults to searching through all of its
search paths for a .dylib file that matches and then, if none is found,
repeats the search for a .a. Xcode by default links against static
libraries with -lLibraryName rather than passing the full path to the
library, which would avoid this problem. I think this is an Xcode bug,
but the Xcode team may disagree with me. (Or not; I don't know.) You
can change the linker's behavior by passing -search_paths_first, which
causes it to go through its search paths one at a time, first searching
for a .dylib in each directory and then searching for a .a before
moving on to the next directory.
If you're successfully linking against the .a and not pulling in the
.dylib, your application can't be pulling in the .dylib on a system on
which it exists unless you're dynamically loading the .dylib at runtime
via dlopen or a similar API.
Hope this helps,
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
