Incompatible library version: libnetcdf.7.dylib requires version 9.0.0 or later, but libcurl.4.dylib provides version 8.0.0

[veit.helm@…]

Hi,

I have a problem with libcurl as stated above. The error occured after upgrading macports. I run OSX version Yosemite. I uninstalled macports, upgraded to EL-Capitan and reinstalled macports. However, the issue is still there. It seems to has something to do with the GMT or GDAL package.

What can I do, how can I upgrade libcurl to provide veriosn 9.0.0?

Many thanks fpr any help

[ryandesign (Ryan Carsten Schmidt)]

curl version 7.46.0 as provided in MacPorts does provide libcurl 9.0.0. If you have libcurl 8.0.0 on your system something is wrong. Reinstall the curl port?

[ryandesign (Ryan Carsten Schmidt)]

Actually before you do that we should check some things.

Are your ports up to date? Run:

sudo port selfupdate
port outdated

If any ports are outdated, run:

sudo port upgrade outdated

Check what version of curl is installed using:

port installed curl

The active one should be 7.46.0_0. Assuming it is, check what library version it has:

otool -L /opt/local/lib/libcurl.dylib

It should be libcurl.4.dylib, compatibility version 9.0.0, current version 9.0.0.

[veit.helm@…]

Hi,

thanks for this very quick and useful answer. I checked all points. Nothing was outdated and otools -L showed the same settings as mentioned. Therfore I checked via sudo find / -name 'libcurl*dylib' if I had another instance of libcurl installed somewhere else. It turn out that this was the case: I moved that other instance and now everything is working fine.

Thanks again

[ryandesign (Ryan Carsten Schmidt)]

In that case, it may be that you have the DYLD_LIBRARY_PATH environment variable set in your shell. You can check by running:

env | grep DYLD

[veit.helm@…]

Hi,

no nothing set like this. I have IDL installed and this software brings its own libcurl. When running some IDL routines it first searches for that internal one. I renamed that IDL one and then the macports one is used as first instance.

[neverpanic (Clemens Lang)]

Note that /usr/bin/env no longer shows DLYD_ variables if you're on 10.11, so the empty grep may actually be misleading.

Try (set -o posix; set) | grep DYLD instead.

[veit.helm@…]

This gave me:

DYLD_FALLBACK_LIBRARY_PATH=/usr/local/GAMMA_SOFTWARE-20150819/lib:/opt/local/lib:/usr/local/lib

DYLD_FALLBACK_LIBRARY_PATH is defined in .profiles

But again everthings working fine now and I guess the ticket can be closed. I just have to remember when installing an updated version of the IDL software to rename the IDL internal libcurl or would you recommend to define a Variable

DYLD_LIBRARY_PATH in .profile?

[ryandesign (Ryan Carsten Schmidt)]

Using DYLD_LIBRARY_PATH in .profile is highly not recommended because it causes the problem you experienced. Using DYLD_FALLBACK_LIBRARY_PATH was supposed to be safe, I thought, because it should only look for the library in the specified locations if it is not found in its normal location, so I'm not sure why you experienced the issue.

[veit.helm@…]

Well thanks good to know. In my stupid mind I would assume that a commercial software like IDL searches its own libary path as first instance and in a lower priority the $path or other env variables which are set in .profile.

To my opinion the issue occured, since I spawned a child process from IDL to executed a command (like gdalwarp) on the command line.

[neverpanic (Clemens Lang)]

Yes, if you fork process from a certain environment there is a high probability that they have DYLD_LIBRARY_PATH exported (because people assume DYLD_LIBRARY_PATH works similar to LD_LIBRARY_PATH on Linux – hint: it doesn't) and then run into this issue.

You should file a bug with the providers of that commercial software and ask them to not rely on DYLD_LIBRARY_PATH. Even DYLD_FALLBACK_LIBRARY_PATH should be unnecessary on OS X, because libraries are referenced using absolute paths on OS X, which enables 3rd party commercial vendors to link against their own copies of libraries without relying on any DYLD_* variables.

As you have already said, this is not a bug in MacPorts and I'm going to close this ticket. We may want to check our documentation for the usage of env | grep DYLD and replace them for 10.11 compatibility, though.

[neverpanic (Clemens Lang)]

As a workaround, try explicitly unsetting DYLD_LIBRARY_PATH when spawning child processes from these commercial environments (if necessary via a script). That has previously worked well for Matlab at least.