Re: Question about dynamic and static libraries
Re: Question about dynamic and static libraries
- Subject: Re: Question about dynamic and static libraries
- From: Bill Northcott <email@hidden>
- Date: Thu, 29 Dec 2005 13:53:45 +1100
On 29/12/2005, at 12:38 PM, Brant Sears wrote:
>
>For this and other good reasons, the use of static libraries is
>deprecated on MacOS X. So the linker ld will always use a dynamic
>library if it can find one on the search path.
Thanks for the information, Bill. From reading your interesting
post, it appears that you know something that I don't as to what
behavior is expected regarding this.
All I know is the result of reading documentation when I had problems.
I think that several folks have articulated the many valid reasons
why traditional static libraries are desireable: organization/
modularization of code within a single project by team members, use
of large third party (often open source) in situations where one
wishes to use a particular snapshot of the library - not as a
dynamic "system resource".
All this can be done with dylibs on MacOS X. See below
That said, when I view my app executable using "otool -L" and it
doesn't show the .dylib because I did link only to the .a and
deleted the .dylib from my computer before building my app, I am
amazed when the linker is going off and loading the .dylib at some
later time on a different computer. The whole purpose of using the
static library was to *prevent* this kind of scenario. I'm
imaginging this to be a potential security risk and a potential
source of failure in the field that I would like to prevent without
losing the benefits of a traiditonal static library.
Funny effects like this generally happen because one dylib loads
another. So a symbol becomes available in a way you did not
anticipate. Security should not be an issue because libraries in the
default search paths should need admin permissions to modify. Of
course anyone with admin permissions can ..........
Is there a way using XCode to use a static library in a traditional
sense where I can always be assured that my application will not go
off behind my back at some later time (post deployment) and load a
dynamic library?
No. Static libraries are deprecated. I presume 'traditional' means
'Linux like.'
If not, do you know by what method it decides which .dylib to load?
Is it based on the name of the .dylib, or some other factor?
At launch time the dynamic loader 'dyld' looks first for a library in
its installed path as visible with otool and modifiable with
install_name_tool. If that path is within your private bundle and
the library is there, then there is no danger that it will use
anything else. If it fails to find the library it will then search
first DYLD_LIBRARY_PATH and then the system directories. So if you
bundle everything, you can modularise and organise in whatever way
you please. Not needing to search saves time at launch. dyld will
never do a blanket search of frameworks. So there is no danger of
you using another framework's library.
Deprecated usually means we can still use something but that it is
going away in the future. I'm very surprised to hear that something
as useful as static libraries are going away. It is like oatmeal
being deprecated or something.
They are not needed. So Apple tools like Xcode don't support them.
You can use them as long as you stay inside the ./configure/make/make
install build method.
Cheers
Bill
_______________________________________________
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