Re: Incompatibilities between home-compiled and apple's libpng
Re: Incompatibilities between home-compiled and apple's libpng
- Subject: Re: Incompatibilities between home-compiled and apple's libpng
- From: Andreas Grosam <email@hidden>
- Date: Wed, 12 Oct 2005 17:54:49 +0200
On 11.10.2005, at 12:09, Damien Bobillot wrote:
Peter O'Gorman wrote :
D. Walsh wrote:
This doesn't work by mistake, it works because you are repackaging a
static library as a dynamic library and providing the current and
compatibility information.
There already was a dynamic shared library with the correct current
and compatibility versions though, making up different numbers to
solve the problem is not right, I feel.
The existing library with the same name cannot be used, because it
does not export the same symbols. So I MUST compile my own version of
the libpng.
I think, it's not supposed to be used. This library libPng.dylib is
located in a private framework (ImageIO) within the framework
ApplicationServices (only in 10.4, in previous system versions this may
be different!).
Meanwhile, I've found an obvious solution to my problem : just adding
the static lib libpng.a to my project... (300Ko is not so much).
Sure, this is the solution ;-)
... or just install libpng with darwinports and build static and
dynamic versions. Then, in your app link against this lib.
The real issue is that Apple uses the opensource libpng library, but
don't export the png_* symbols. So it's impossible to use this library
in our programs without any hacks. Why Apple don't
make it publicly available ? (may be off topic...)
Most likely because Apple want to use this lib *privately*. This is a
common use case. I know several other libraries that link (mostly
statically) against a local copy of another open source library. The
reasons may be:
- customized sources
- non-default configure options
- newest sources needed (cvs, unstable)
- independence of other installation paths and the existence of this
libs
- etc,
If you find this library usefull, feel free to install it by yourself.
Anyway, I think the original poster has DYLD_LIBRARY_PATH set
somewhere to be getting this behavior.
I do. However, if I put my library in /usr/lib, I don't need
DYLD_LIBRARY_PATH anymore. So my problem has nothing to do with
DYLD_LIBRARY_PATH.
/usr/lib is owned by system, you should not touch these folders/files.
You should better install the library from the package (using
configure/make/make install) in usr/local or another "prefix" e.g.
/opt/local.
Or better, use one of the package managers Darwinports or Fink to
install third party libs:
<http://darwinports.opendarwin.org/> (currently down!?)
<http://fink.sourceforge.net/>
Andreas
--
Damien Bobillot
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
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