Re: static libraries
Re: static libraries
- Subject: Re: static libraries
- From: Steve Checkoway <email@hidden>
- Date: Tue, 25 Oct 2005 15:33:26 -0700
I'm not entirely positive that this reply made it to the list, so I'm
resending it. If it comes twice, please accept my apologies.
Andreas Grosam wrote:
I have 2 different things, first a questions, and secondly a suggestion.
1) Does somebody know for a fact how ld orders the search paths
specified with the command -L option?
The man says, that it "adds" the search path to the search list, but
where? At the tail, at the top or elsewhere?
It adds the path to the beginning. From the ld man page:
"ld searches for libraries first in any directories specified with -L
options, then in the standard directories /lib, /usr/lib, and
/usr/local/lib."
2) Another option to resolve search paths ambiguity would be to use a
link-file-list. However, such a file is generated by Xcode, and we have
no control about this.
From the man:
-filelist listfile[,dirname]
Specifies that the linker should link the files listed
in list-
file . This is an alternative to listing the files on
the com-
mand line.The file names are listed one per line
separated only
by newlines. (Spaces and tabs are assumed to be part of
the file
name.) If the optional directory name, dirname is
specified, it
is prepended to each name in the list file.
Why does Xcode just not put *all* linked objects into the link-file-list?
Suppose, my App links against Carbon framework, libfreetype
(dynamically), libz (dynamically) and my customized png library
(statically) which is located in my project folder. Suppose *all*
libraries have been dragged into the project so that the app gets
linked with them. The content of the link-file-list could look like this:
foo.o, <object_root>
bar.o, <objec_root>
libpng.a, /my/path/to/project/mylibs
libz.dylib, /opt/local/bin
libfreetype.dylib, /opt/local/bin
Carbon.framework, <system_path>
This above would eliminate the ambiguity of library search paths and it
also would not require to specify any library search path in the build
settings.
So, even when there is a library libpng.dylib in /opt/local/lib ld
shouldn´t select it, but libpng.a in the customer search path.
Any pitfalls which come into mind? Otherwise, I would appreciate it
very much if Xcode could manage this task for us.
One thing that comes to mind is if you give this application to anyone
else and they do not have libz.dylib and libfreetype.dylib in
/opt/local/lib, then the application will fail to launch even if the
libraries are installed elsewhere. As far as I can determine, there is
no way to get around this with mach-o executables (except for dlopen).
- Steve
_______________________________________________
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