Opened 9 years ago

Closed 9 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 9 years ago by murat@…

obviously 'limping' should be 'libpng'.

comment:2 Changed 9 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 9 years ago by mf2k (Frank Schima)

Description: modified (diff)

comment:4 in reply to:  description Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to murat@…:

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.

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 Changed 9 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 in reply to:  5 Changed 9 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.dylib

Which 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 9 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 9 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: invalid
Status: newclosed

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.

Note: See TracTickets for help on using tickets.