RE: Question about dynamic and static libraries
RE: Question about dynamic and static libraries
- Subject: RE: Question about dynamic and static libraries
- From: "Brant Sears" <email@hidden>
- Date: Wed, 28 Dec 2005 20:38:51 -0500
- Thread-topic: Question about dynamic and static libraries
Title: RE: Question about dynamic and static libraries
>> 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.
>
>
>This is not weird behaviour. There are very good reasons for he
>behaviour.
>
>MacOS X ships with multiple compiler versions. You may well have gcc
>2.95, gcc 3.x and gcc 4.x all installed. Dynamic libraries are
>compiler independent. Static libraries, which are just object code
>archives, are not compiler independent. You see plenty of problems
>on these lists from people trying to link code from a static library
>built with gcc 3 with some other objects built with gcc 4 and vice
>versa. Linux distros tend to have a system compiler which was used
>to build the system itself and all enhancements. so this issue is
>less common.
>
>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.
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".
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.
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?
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?
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.
_______________________________________________
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