Static linking woes.

[Skorche]

For my 21 days entry, I needed to link to libpng. After sending it to a friend, the console reports that /usr/lib/local/libpng.dylib isn't found.

But I specifically included libpng.a :blink:

I then noticed an warning in the build results. /usr/bin/ld: warning prebinding disabled because dependent library: /usr/local/lib/libpng.3.dylib is not prebound

How does XCode know about the .dylib?

[AnotherJake]

But I specifically included libpng.a :blink:
It doesn't matter, Xcode was specifically designed to be a piece of crap when it comes to some things. I don't remember what I did to get around that problem, but you might be able to move the dylib out of there to force it to use the .a instead. It always prefers dylibs if it can find one for some unkown and completely idiotic reason. This has been discussed here on the forums some time ago. You might try digging around for an old thread or two on the subject.

[Skorche]

libpng.a was copied into the project folder. So is it possible that maybe there's something wrong with my copy of libpng.a so that it depends on the .dylib? :\

[AnotherJake]

No. Xcode is just dumb and really *is* trying to use the dylib even though you told it not to. Your .a is most likely perfectly okay. I prefer to not install distributions anymore because of this behavior. I just build them in the directory they came with (without running install) and drag them into the project from there to keep Xcode in the dark about any dylibs that came with it.

[Skorche]

I just build them in the directory they came with and drag them into the project from there to keep Xcode in the dark about any dylibs that came with it.

Funny, I just thought the same thing. I re-downloaded and compliled only libpng.a. Using that, It *STILL* finds /usr/local/lib/libpng.3.dylib. :mad: If I remove libpng.a from the linking stage, it won't compile at all. (as expected of course)

[AnotherJake]

Did you remember to uninstall libpng first?

[Dan Potter]

I had similar problems linking in OggVorbis from Fink. I finally ended up having to remove /sw/lib from my linker path and copying the .a's into my project build dir manually, and adding -logg, etc, to the linker flags. After that it finally got the point.

I don't think the problem is that Xcode is too stupid per se, I think it's that it tries to be a lot smarter than it is. Which is a hallmark of Windows programs in general. I have a great deal of frustration with Xcode sometimes. :) At least with VS.NET at work I've figured out all the things I need to do in order to turn it *actually* stupid so I can tell it what to do, and get on with my work.

[Skorche]

The problem is, I don't know how or where /usr/local/lib got added to the linker path. It's not really a standard osx lib path is it? Is it buried in an environment variable somwhere?

[AnotherJake]

That's a good question. Maybe OSC knows. It sure seems like Xcode thinks it's a permanently important path. As far as I know, the only way to get Xcode to use the .a instead of the .dylib is to either temporarily (or permanently) remove or rename the dylib in the local libs directory so Xcode can't find it. Have you tried that yet?

[Steven]

The man pages are unclear so I don't know if this is anywhere in the right ballpark, but I'll throw it out anyway - would passing --static to gcc help?

[Dan Potter]

It's a good idea but GCC is rather ignorant about linking options like that. If you pass it --static, it wants to link everything static, which will cause some issues. Who knows (OSC? :)), there might be some way to link a few libs static and everything else dynamic... if so I'd love to hear about it.

[TomorrowPlusX]

I faught against libpng too, once long ago. I ended up removing the dylib from /usr/local/lib -- after all, nothing depended on it.

Ultimately, I ended up using quicktime to load my images, so, whatever. But, anyway, there's no overriding Xcode's dylib preference as far as anybody can tell. You have to get *rid* of any dylib it finds.

Also, instead of having to send to your friends to see if it still looks for /usr/local/lib/libpng or whatever, you can use otool to get a listing of dependancies on your binary.