I’m not sure what you’re trying to achieve by setting CPATH, either – MacPorts will ignore your current environment setup anyway, so unless you run use_macports.sh clang, it won’t have an effect at all. DYLD_FALLBACK_PATH on the other hand is only used if the library isn’t found using the path baked into the binary. a binary links against /usr/lib/libcurl.4.dylib and you have curl installed via MacPorts and you set DYLD_LIBRARY_PATH to the MacPorts prefix, that binary might load an incompatible version of libcurl, whereas it would have worked fine without the variable. Setting DYLD_LIBRARY_PATH will make the loader ignore those absolute paths and always use the version form DYLD_LIBRARY_PATH. Please see man 1 dyld for more information on what these variables do and how to set them correctly.Īs rationale: Libraries are referenced using absolute paths on OS X. In the remote case that a binary doesn’t work, you should set DYLD_FALLBACK_LIBRARY_PATH. It’s important to know that this variables does *not* behave like LD_LIBRARY_PATH on Linux.Īll executables should already work without DYLD_LIBRARY_PATH set *even* in the presence of homebrew, unless you did also set DYLD_LIBRARY_PATH for homebrew (which should not be required there either, but I’m no pro on that). It’s very likely it doesn’t do what you expect it to and is really only meant to be a tool for developers to test compatibility against newer library versions. Please do not set DYLD_LIBRARY_PATH on OS X. It seems that kpsewhich cannot detect its parameters correctly using this method. Update: There is now a known issue when using kpsewhich with this method. If you have any problems or concerns please feel free to comment. I’ve used Macports to install evince and texlive, and there is no problem to use this method by far. In this case, you might want to try to run brew install -env=std package_name and brew install -env=super package_name to see whether the build works, or you even need to rename /opt/local temporarily.
When using Homebrew to install packages, one noticeable thing is that sometimes /opt/local may interference the build of the packages. When Using Homebrew to Install Packages … That’s why I try to use Homebrew if the package is available there. So now you see, although it’s not a big deal, Macports packages require more energy to set up. For example, assuming ~/bin is in your PATH environmental variable: echo 'exec use_macports.sh port $*' >~/bin/portĮxecuting the above line will give you a new “port” command which is actually a wrapper. pdflatex if texlive is installed from MacPorts) directly without the lengthy command above, you can wrap frequently used commands into scripts. įor example, you need to run port command to install texlive: use_macports.sh port install texliveįor convenience, if you want to run port (or any other executables installed from MacPorts, e.g. Then, to wrap any executables installed by Macports, just run: use_macports.sh executable args1 args2. # Wrap Macports command (any executables installed by Macports).Įcho "Usage: $0 command " >&2Įxport PATH="$MACPORTS_PREFIX/bin:$MACPORTS_PREFIX/sbin:$PATH"Įxport CPATH="$MACPORTS_PREFIX/include:$CPATH"Ĭopy this script to any directory in your PATH environmental variable.
To do this, I wrote a wrapper script use_macports.sh: #!/bin/bash where $MACPORTS_PREFIX is the installation prefix of Macports (by default it is /opt/local. Wrap Macports Executables with Appropriate Environmental Variables When You Use themīefore running any executables, we need to prepend $MACPORTS_PREFIX/bin:$MACPORTS_PREFIX/sbin to the PATH environmental variable, etc. But remember not to modify environmental variables related to Macports, such as PATH, CPATH.
It is not garanteed to work, and it is possible that it does not work under some certain circumstances.įollowing the installation instructions on their websites ( Homebrew and Macports) to install both of them. Please note that this post only presents a workaround.
We will wrap the executables installed by Macports with suitable Environmental Variables. When one package is not available in Homebrew, install it from Macports (you will soon see why). The basic rules here are using Homebrew packages as much as possible. Although having both of them installed is not recommended, I still want to give it a try. But sometimes, there are just some packages not available in Homebrew while they are in Macports. At most of the time, Homebrew is fair enough: it has a large package collections. Homebrew and Macports are two excellent package managers on OS X.
0 kommentar(er)
