Opened 10 years ago
Closed 10 years ago
#47432 closed defect (invalid)
libpng version error
Reported by: | murat@… | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.3 |
Keywords: | Cc: | ||
Port: | libpng |
Description (last modified by mf2k (Frank Schima))
sudo port install libpng
should install latest libpng (1.6.17 as of this writing), and after install,
port installed
does report that libpng 1.6.17 is installed.
However an examination of /opt/local/lib shows that libpng 1.6.16 is in actually installed.
Change History (8)
comment:1 Changed 10 years ago by murat@…
comment:2 Changed 10 years ago by mf2k (Frank Schima)
Owner: | changed from macports-tickets@… to ryandesign@… |
---|---|
Port: | libpng added |
In the future, please fill in the Port field and Cc the port maintainers (port info --maintainers libpng
), if any.
comment:3 Changed 10 years ago by mf2k (Frank Schima)
Description: | modified (diff) |
---|
comment:4 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to murat@…:
sudo port install libpngshould install latest libpng (1.6.17 as of this writing), and after install,
port installeddoes report that libpng 1.6.17 is installed.
However an examination of /opt/local/lib shows that libpng 1.6.16 is in actually installed.
Could you describe this examination in more detail? Why do you think 1.6.16 is installed?
What is the output of:
/opt/local/bin/libpng-config --version
comment:5 follow-up: 6 Changed 10 years ago by murat@…
Forgive me if I'm committing a newbie error.
The output of libpng-config is indeed 1.6.17.
However, a directory listing of /opt/local/lib gives me this:
lrwxr-xr-x 1 root admin 10 Apr 7 20:53 libpng.a -> libpng16.a lrwxr-xr-x 1 root admin 14 Apr 7 20:53 libpng.dylib -> libpng16.dylib lrwxr-xr-x 1 root admin 11 Apr 7 20:53 libpng.la -> libpng16.la -rwxr-xr-x 1 root admin 176924 Apr 7 20:53 libpng16.16.dylib -rw-r--r-- 1 root admin 278128 Apr 7 20:53 libpng16.a lrwxr-xr-x 1 root admin 17 Apr 7 20:53 libpng16.dylib -> libpng16.16.dylib
Which looks to me like 1.6.16, but I'm now doubting my interpretation of how libraries encode their version numbers.
However (and this is what started all this), trying to run tcpflow results in the following error:
dyld: Library not loaded: /opt/local/lib/libpng16.16.dylib Referenced from: /opt/local/lib/libfreetype.6.dylib Reason: Incompatible library version: libfreetype.6.dylib requires version 34.0.0 or later, but libpng16.16.dylib provides version 32.0.0 Trace/BPT trap: 5
comment:6 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to murat@…:
Forgive me if I'm committing a newbie error.
The output of libpng-config is indeed 1.6.17.
However, a directory listing of /opt/local/lib gives me this:
lrwxr-xr-x 1 root admin 10 Apr 7 20:53 libpng.a -> libpng16.a lrwxr-xr-x 1 root admin 14 Apr 7 20:53 libpng.dylib -> libpng16.dylib lrwxr-xr-x 1 root admin 11 Apr 7 20:53 libpng.la -> libpng16.la -rwxr-xr-x 1 root admin 176924 Apr 7 20:53 libpng16.16.dylib -rw-r--r-- 1 root admin 278128 Apr 7 20:53 libpng16.a lrwxr-xr-x 1 root admin 17 Apr 7 20:53 libpng16.dylib -> libpng16.16.dylibWhich looks to me like 1.6.16, but I'm now doubting my interpretation of how libraries encode their version numbers.
Library version numbers rarely coincide with project version numbers. I also have those files installed on my system with libpng 1.6.17. The real library version information is stored in the library. libpng 1.6.17 provides libpng16 compatibility version 34. The same files are also installed with libpng 1.6.16, except they are compatibility version 33. The same files are installed with libpng 1.6.15, except compatibility version 32.
However (and this is what started all this), trying to run tcpflow results in the following error:
dyld: Library not loaded: /opt/local/lib/libpng16.16.dylib Referenced from: /opt/local/lib/libfreetype.6.dylib Reason: Incompatible library version: libfreetype.6.dylib requires version 34.0.0 or later, but libpng16.16.dylib provides version 32.0.0 Trace/BPT trap: 5
Compatibility version 32 was from libpng 1.6.15, so somewhere on your system you have installed a copy of libpng 1.6.15, either in addition to or on top of the 1.6.17 installed by MacPorts.
Run:
otool -L /opt/local/lib/libpng16.dylib
If this shows compatibility version 32 (or any number other than 34), then your MacPorts libpng library was overwritten somehow (did you run some other installer?) and you should deactivate and reactivate the libpng port to put it right:
sudo port -f deactivate libpng sudo port activate libpng
If, however, otool
shows compatibility version 34, then your MacPorts libpng is probably undamaged. In that case, I would suspect that you have set the DYLD_LIBRARY_PATH
environment variable to a location where libpng 1.6.15 is installed. Have you done that? To find out, you can run:
env | grep DYLD_LIBRARY_PATH
If this produces no output, you don't have DYLD_LIBRARY_PATH
set, but if you do, it will show you what value it's set to.
You might also check whether you have libpng16.16.dylib in /usr/local/lib (or anything in /usr/local, really).
comment:7 Changed 10 years ago by murat@…
Looks like the problem was a configuration script we use here that set DYLD_LIBRARY_PATH to the wrong directory.
Thank you for your help and my apologies.
comment:8 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → invalid |
---|---|
Status: | new → closed |
OK, glad that's all it was. Setting DYLD_LIBRARY_PATH
often causes problems and is usually not necessary. If you have a situation where you think you need to set DYLD_LIBRARY_PATH
, you should see if there is a better way to solve the problem. For example, often DYLD_LIBRARY_PATH
is used when a library does not have the right install_name
. In that case, the solution is to fix the library's install_name
, which may also involve fixing the references to that library's install_name
in any other libraries or programs that link with it.
obviously 'limping' should be 'libpng'.