Library path mac os

Setting DYLD_LIBRARY_PATH on Mac OS X Sierra (CoolProp)

Disclaimer: This question started as a GitHub issue.

Question

I’ll put the X question right up front: Does anyone know a way to set DYLD_LIBRARY_PATH in a way that Excel 2016 will recognize on MacOS Sierra?

The actual problem (Y): How (else) can the developers of CoolProp allow their dynamic library to be used in Excel?

Background

I am trying to get Excel 2016 for Mac to recognize the CoolProp plugin using these instructions, which basically boil down to using this startup.plist :

to set DYLD_LIBRARY_PATH to a location where Excel can access the dynamic library and copying the libCoolProp.dylib file into that same directory. Unfortunately, it appears that due to SIP, one can no longer set any environment variable which starts with DYLD_ .

To verify this, I have built a test spreadsheet which contains this VBA function and =ENV(«DYLD_LIBRARY_PATH») in cell A1.

I observe this behaviour:

After running this sequence of commands in my terminal and restarting Excel, I am able to retrieve the contents of «DYLDLIBRARYPATH» using the test spreadsheet. I have also edited the startup.plist and obtained similar results. I appear to be following all the right steps, but it appears that «DYLD_*» is simply not being set when I call setenv. The result is the same if I do it as root.

So basically I am looking for any way in which I can still use this plugin on the Mac.

Versions: MacOS Sierra (10.12.3), Excel 2016 (15.32), CoolProp 6.10

Источник

LD_LIBRARY_PATH and DYLD_LIBRARY_PATH not imported on OS X #1523

Comments

currymj commented Mar 3, 2017

I tried to import GPU Tensorflow; it failed to find the CUDA libraries. I checked the process.env environment variable and found that LD_LIBRARY_PATH and DYLD_LIBRARY_PATH had not been added. After further digging, I found that the shell-env package doesn’t import them because it just calls the env command, which doesn’t include them in its output for some reason.

Manually going to the console, adding the paths to process.env , and restarting the kernel fixed the problem.

I’m not sure what the solution is here. Either import these separately, allow them to be configured somewhere, or something else? I think there are enough people who want to call CUDA from Python that it’s probably worth doing though.

The text was updated successfully, but these errors were encountered:

rgbkrk commented Mar 3, 2017

We definitely need to figure out why those aren’t loaded properly.

Are you setting LD_LIBRARY_PATH in your startup scripts for your shell ( .bashrc )?

One annoyance on OS X is that it invokes Applications with launchctl and does not create a shell for you. The shell-env was put in place to work around this issue by spawning a shell for the user.

I’m installing Tensorflow on my mac now, I’ve only used it on remote systems prior to this.

lgeiger commented Mar 3, 2017

New versions of OS X enable system integrity protection per default. Meaning that setting the DYLD_LIBRARY_PATH and LD_LIBRARY_PATH will have no effects.

I had this issue before in another context, but it looks like it’s a common issue on other Node modules as well: oracle/node-oracledb#231

currymj commented Mar 3, 2017 •

I’m doing it in .bash_profile ; I put it in .profile as well just to see if it would work.

I’ve definitely run into the problem of environment variables in non-command-line OS X apps before. But in this case, all other environment variables are loaded fine! I think the root of the problem is that for some reason, the env shell command (which shell-env relies on) doesn’t include LD_LIBRARY_PATH or DYLD_LIBRARY_PATH . If there’s a good place to just shell out, echo $LD_LIBRARY_PATH , and separately add it, point me at it and I’d be happy to throw together a PR.

I’m confused by the SIP issue, because I have it enabled but 1) everything works fine on command line or in jupyter notebook invoked from there, I’m able to set those variables and tensorflow will find the CUDA libraries; 2) when I manually add the missing fields to process.env everything in nteract works perfectly.

rather than turning off SIP, might it be possible to just allow users to configure nteract to add these fields to process.env ?

rgbkrk commented Mar 3, 2017

Side question so that I can experience this — what kind of Mac do you have, what GPU do you use? My Macbook Pro (2015 model) only has the built in Intel GPU, and the newer Macs use AMD GPUs.

As for if you’re able to extract the LD_LIBRARY_PATH , my first thought is adding to

Off the cuff, I’m guessing it would look something like:

However, if I had to guess we probably need to look into how the kernel gets spawned (the above code is for locating kernels and other necessary paths).

currymj commented Mar 3, 2017

15 inch Retina, mid 2014, NVIDIA GeForce GT 750M graphics card. i think this may be a red herring though, b/c everything works fine once the environment variables are set. i’m inferring things in tensorflow right now! (the reason i bring this up is that getting everything compatible among CUDA, Xcode, clang, gcc, Python, and Tensorflow can be extremely frustrating.)

now i’ve found that manually editing os.environ in python before importing tensorflow also works.

Looking at this, I think that SIP might indeed be the problem; also extractEnvVariable above might not work.

bimsapi commented May 15, 2017

For what it’s worth, rather than disable SIP, I’ve resorted to linking the .dylib objects into /usr/local/lib . E.g., ln -s $ORACLE_HOME/*.dylib* /usr/local/lib

stale bot commented Apr 13, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

rgbkrk commented Apr 13, 2018

This seems like an issue we should move into some docs. Is anyone game for making a page encapsulating this?

stale bot commented Dec 7, 2019

This issue hasn’t had any activity on it in the last 90 days. Unfortunately we don’t get around to dealing with every issue that is opened. Instead of leaving issues open we’re seeking to be transparent by closing issues that aren’t being prioritized. If no other activity happens on this issue in one week, it will be closed.
It’s more than likely that just by me posting about this, the maintainers will take a closer look at these long forgotten issues to help evaluate what to do next.
If you would like to see this issue get prioritized over others, there are multiple avenues 🗓 :

• Ask how you can help with this issue 👩🏿‍💻👨🏻‍💻
• Help solve other issues the team is currently working on 👨🏾‍💻👩🏼‍💻
• Donate to nteract so we can support developers to work on these features and bugs more regularly 💰 🕐

Источник

Is it OK to use DYLD_LIBRARY_PATH on Mac OS X? And, what’s the dynamic library search algorithm with it?

I read some articles discouraging of the use of DYLD_LIBRARY_PATH, as the the path of dynamic library should be fixed using -install_name, @rpath, and @loader_path.

In terms of making a program that runs both on Linux and Mac OS X, DYLD_LIBRARY_PATH of Mac OS X does exactly what LD_LIBRARY_PATH of Linux. And, we can share (almost) the same make file that doesn’t have the -install_name and @rpath.

• Is this OK to use DYLD_LIBRARY_PATH on Mac OS X?
• What’s the dynamic library search algorithm with Mac OS X when the binary can’t find the dynamic library? current directory -> DYLD_LIBRARY_PATH directories . ?

3 Answers 3

As you’ve noted, DYLD_LIBRARY_PATH behaves like LD_LIBRARY_PATH on other *nix. However, there is another environment variable you should look at called DYLD_FALLBACK_LIBRARY_PATH .

In general, these are (both on osx and linux) suggested only for development use as they can cause symbol lookup errors when you override with a library that does not have the same symbol table. A good example of this is when you attempt to override the default install of VecLib (e.g. blas lapack) with a custom install. This will cause symbol not found errors in applications linked to the system VecLib if DYLD_LIBRARY_PATH is set and the reverse (symbol lookup errors in custom applications) if it is not. This is due to the system blas/lapack not being a full implementation of the ATLAS libs.

DYLD_FALLBACK_LIBRARY_PATH will not produce these problems.

When installing libraries to a non-standard location, DYLD_FALLBACK_LIBRARY_PATH is much more sane. This will look for symbols in libraries provided in the default paths and if the symbol is not found there, fall back to the specified path.

The benefit is that this process will not cause symbol lookup errors in applications compiled against the default libraries.

In general, when libraries are installed to non-standard locations absolute paths should be specified which negates the ambiguity of the dynamic lookup.

Источник

Where do I set DYLD_LIBRARY_PATH on Mac OS X, and is it a good idea?

I am trying to install a solver written in C++ on my Mac (OS X), for use with code I have written in XCode.

The solver documentation says this:

Be sure to have «.» in your DYLD_LIBRARY_PATH in order to

• run the ready-built executables
• link with the libamg.dylib (and the gfortran RTSlibs)

I don’t really understand what this means. Where and what do I need to change what?

I have done some googling, but haven’t come across anything that is simple enough for a newbie like me! If there are any patient people out there who wouldn’t mind directing me to an online resource or giving me the a-b-cs of how and where to set environment variables, I would be very grateful.

3 Answers 3

It’s an environment variable and as such is usually set in Terminal by

This is a colon separated list of directories that contain libraries. The dynamic linker searches these directories before it searches the default locations for libraries. It allows you to test new versions of existing libraries.

For each library that a program uses, the dynamic linker looks for it in each directory in DYLD_LIBRARY_PATH in turn. If it still can’t find the library, it then searches DYLD_FALLBACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH in turn.

Use the -L option to otool(1) . to discover the frameworks and shared libraries that the executable is linked against.

You’d probably want something like

to prepend . (current directory) to the list of locations searched. On my unmodified OS X, DYLD_LIBRARY_PATH has no current value though:

Источник

Make /usr/local/lib a default library search path for ld on mac os x?

I have XCode installed, but for some reason, /usr/local/lib is not amongst the default library search paths:

This is unfortunate since /usr/local/lib is a fairly canonical location for installed libraries and and there is no /etc/ld.so.conf + ldconfig on mac os x to modify the default library search paths. So without using -L/usr/local/lib this results in a linker error. Is there any other, non-runtime option than setting the environment variable DYLD_LIBRARY_PATH ?

EDIT: Setting the DYLD_LIBRARY_PATH env variable did nothing for me. I had to set the LIBRARY_PATH env variable instead to be able to link libraries installed under /usr/local/lib with gcc .

Was there an option about this when installing XCode ? (it’s a work computer, haven’t installed it myself)

/.bash_profile : if [ -z «$» ] #\n then #\n export LIBRARY_PATH=»/usr/lib:/usr/local/lib» #\n else #\n export LIBRARY_PATH=»LIBRARY_PATH:/usr/lib:/usr/local/lib» #\n fi (showing newlines with #\n ). After this, gcc -Xlinker -v also lists /usr/local/lib (open a new terminal window for .bash_profile to take effect)

2 Answers 2

To add a temporary library to my project using Xcode I did the following:

To add a temporary include path to my XCode library search paths I had to do the following:

If you want to add default include and search paths you need to use:

For include paths:

And for library paths:

In order for Xcode and other GUI applications in OS X (tested on 10.10) to be able to access these environment variables, you need to set variables using:

But these are not permanent. In order to have these variables across restarts, you need to create a startup script. See this page for an example.

Environment variables starting with DYLD_ like DYLD_LIBRARY_PATH are specific to Apple’s dynamic link editor called dyld. The manual pages state:

DYLD_LIBRARY_PATH This is a colon separated list of directories that contain libraries. The dynamic linker searches these directories before it searches the default locations for libraries. It allows you to test new versions of existing libraries. For each library that a program uses, the dynamic linker looks for it in each directory in DYLD_LIBRARY_PATH in turn. If it still can’t find the library, it then searches DYLD_FALL- BACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH in turn. Use the -L option to otool(1). to discover the frameworks and shared libraries that the exe- cutable is linked against.

Please note that the DYLD_FALLBACK_LIBRARY_PATH already contains a reference to standard /usr/local/lib by default.

DYLD_FALLBACK_LIBRARY_PATH This is a colon separated list of directories that contain libraries. It is used as the default location for libraries not found in their install path. By default, it is set to $(HOME)/lib:/usr/local/lib:/lib:/usr/lib.

Xcode has Project-wide or Target-specific Build Settings such as «Library Search Paths» where you would define paths to non-standard locations that you need to let the linker know about.

Apart from copying and adding *.dylib files to your Xcode project you need to «make install» those to one of these known library locations. Otherwise the O/S loader (launchd process) cannot use them during actual launch or run-time of your app image.

Please note that C++ as well as Object-C have their challenges regarding Dynamic Libraries.

Источник