hey i am new to the macports thing as i recently switched to the mac. as i was thinking of developing some applications in my mac i wanted all the usual gnu and opensource tools i need. but i had a small confusion. i was installing git with macports and i noticied it installed a lot of packages like Perl that i already have in my machne. so i was thinking won't there be any conflicts and how does one know which version is used. the macports one or the apple one?
MacPorts installs all of its ports into /opt/local (or whatever prefix you configured it with, but it's /opt/local by default). It installs its own copies of Perl, Python, etc., so that the MacPorts install is standardized, and to avoid conflicts (Apple-supplied versions of some programs like Perl and Python, and some libraries, often lag far behind the latest versions of those tools).
When you install MacPorts, it automatically prepends /opt/local/bin to your $PATH variable (you can change this by editing your shell configuration file), so if you call perl, etc., you'll get the MacPorts version. However, the Apple-supplied versions will still be intact and unchanged, and other programs that rely on those versions will not be affected, either.
There shouldn't be any conflicts, since MacPorts installs all of its programs under a completely separate directory hierarchy in /opt/local/.
If you have multiple versions of software installed (e.g. the default OS X Perl and MacPorts' Perl), then it depends on the order of directories in your $PATH environment variable. MacPorts typically sets itself up with its bin directories earlier in your path, so saying perl at the command line will invoke the MacPorts Perl, not the OS X Perl.
MacPorts installs its own dependencies in the /opt/local tree (you can change this default when you build MacPorts) because its packagers then have a known quantity to test against. In some cases there is a system package for a given dependency that will let you use the system-installed version, but that's actually pretty rare. System vs. MacPort versions are chosen according to whichever comes first on the PATH (for executables) or the linker path(s) for dynamic libraries. Use your standard development tools' options to select the appropriate libraries to link against and you should be fine.
Related
I am quite new at using homebrew and I am trying to figure out how it works to use some libraries (boost, gsl, openblas for example) in my own project.
I have understood that each formula is installed by Homebrew in /usr/local/Cellar/ and then symlinked in usr/local/bin, usr/local/lib, usr/local/include, so it seems, excepts for keg-only formulas so it does not mess with already installed libraries by the OS (cf. Understand homebrew and keg-only dependencies for example). But I found out that every formula is also linked to a /usr/local/opt directory.
So my question is why is there this /usr/local/opt directory (it is kind of redundant), and what path do I have to use for using formulas (usr/local/Cellar or usr/local/ or usr/local/opt basically) ?
It provides a path for a formula's contents that does not change across version upgrades.
Consider this scenario: Say you build libfoo.dylib with Homebrew. It is version 2.0.0, and so it lives at /usr/local/Cellar/libfoo/2.0.0/lib/libfoo.dylib. You want to link to it from another program you are building, so you pass -L/usr/local/Cellar/libfoo/2.0.0/lib -lfoo to gcc. Your program compiles. Later on, you upgrade to libfoo 2.0.1 and remove v2.0.0. Now /usr/local/Cellar/libfoo/2.0.0/lib/libfoo.dylib no longer exists, and your program no longer runs, because it can't dynamically load libfoo.
That's okay. libfoo.dylib is also available at /usr/local/lib/libfoo.dylib. It's a symlink to the latest version of libfoo, so it should always be present. So you pass -L/usr/local/lib -lfoo to your program and compile it. Later you upgrade to libfoo 2.0.1. No problem, because /usr/local/lib/libfoo.dylib is still present and points to the v2.0.1 copy.
That's great, and Homebrew existed with just that system for a while. The problem is, some formula are "keg-only", so they are not symlinked from /usr/local. (Generally they are keg-only because they shadow a version of a library that ships with OS X, and superseding OS X libraries can cause problems.) Say you want to link to a keg-only version of the library. It's not symlinked from /usr/local/lib, so you have to give the full path to the version installed in /usr/local/Cellar, which is brings you back to the first problem listed above.
/usr/local/opt solves this problem. It provides a place for the current version of all formulae to be symlinked, regardless of whether they are keg-only or not. Now, when you want to compile your program, you can use -L/usr/local/opt/libfoo/lib -lfoo, and your program will link to the latest version of libfoo, even if you upgrade it and even if it is keg-only.
Just to complement mipadi answer.
From an article aptly named '/usr/local/opt'
Storing files in consistent locations is an important part of keeping
a system clean and maintainable. On most Linux systems, the majority
of software is installed using a package manager. A package manager
tracks the files that are installed, so it can update and remove
software with minimal side-effects.
There are times, however, when software that is not available through
the package manager must be installed. To minimize the side-effects on
the filesystem, such software is installed within the /usr/local
directory. UNIX-style installation of software puts files in the bin,
lib, share, etc. subdirectories under the local root, but it is very
common to install software into package-specific directories and add
soft-links from the local root instead. Doing so allows for easy
removal of the software—simply remove the package-specific directory
as well as any links pointing into it.
Some software provides local installation instructions that promote
creating a package-specific directory directly in /usr/local. This
does not promote good organization, as it mixes UNIX hierarchy
directories with package-specific directories. Installation of
software into package-specific directories is already done elsewhere,
in the /opt directory, and it would therefore make sense to follow the
same conventions and put locally installed package-specific
directories in a /usr/local/opt directory.
Including a version number in the directory name is not required, but
it is good practice for locally-installed software because it allows
multiple versions to be installed and tested simultaneously. To run a
specific version of the software, run the executable under the package
directory directly. Any version can be made the default by controlling
which executable is linked to from /usr/local/bin. For example, a new
version of software can be installed and tested without removing the
old version. When the new version is ready, the link in /usr/local/bin
can be updated to point to it. The old version of the software can
then be removed when it is no longer needed.
Source: Copyright © 2014 Extellisys
I found that in /usr/local/opt(in my own macOS file system) there were many symlinks related to other programs, such as openssl, gnutls, and so on. So I think this(/usr/local/opt) specific directory is not created just for HomeBrew, and it might be applied to more broader range of executable procedure.
BTW 1: I consulted the homepage of the "Filesystem Hierarchy Standard (FHS)". I didn't find the description about /usr/local/opt in the "Chapter 4. The /usr Hierarchy". It's somewhat curious.
BTW 2: I have installed the GNU Stow by HomeBrew. When I input the command brew --prefix stow the Terminal displays the path /usr/local/opt/stow. Then I try to open it using command open /usr/local/opt/stow in Terminal. It opens a directory whose path is /usr/local/Cellar/stow/2.3.1.
So, we all know that Mountain Lion doesn't ship with X11 anymore and users needing X11 are directed to download Xquartz. Xquartz installs to /opt, but it also symlinks X11 and X11R6 to /usr. But when building software that requires linking to X11 include files, I've discovered that I must pass an environment variable adding /usr/X11/include (or /opt/X11/include) to the library search path to get ./configure to find the X11 libraries. My question is why?
I've done some research on Google (many results pointing back to Stack Overflow), and I've read Apple's documentation, and these sources all indicate that there is no equivalent in OS X to the /etc/ld.so.conf file found in many (if not all) Linux distributions. Apple even states that DYLD_LIBRARY_PATH is empty by default. However, under Lion (with Apple's last 'official' X11 installed), the same ./configure scripts would find the X11 libraries without adding anything to the library search path.
So, why can't ./configure scripts find X11 libraries in Mountain Lion without explicit modification of the library search path?
Asked more than a year ago... but as I came here with a similar problem...
Note that in the mentioned ruby question, there was no library search path being modified.
That solution just set an environment variable that is picked up by many Makefiles as the flags for the C++ compiler. That example defined the build time -I ncludepath, i.e. where to search for .h eaders -- not libraries (which would have been a -L option to your compiler/linker). Both would have been build time options.
Whether LD_LIBRARY_PATH or DYLD_LIBRARY_PATH -- both are environment variables that are considered by the dynamic linker at runtime. (For more, see http://en.wikipedia.org/wiki/Dynamic_linker )
I have no pre-10.8 machine at hand, but guess that there might have been a symlink
/usr/include/X11 -> /opt/X11/include/X11 -- otherwise I have no Idea atm how
it could have worked before, assuming same sources...
This is another potential solution for such problems (just fixed my realvnc build):
$ autoconf
$ ./configure
So your question for "why?" could be eventually answered with: Because your sources contained a 'pre-built' configure script that was based on older autotools that did not include
/opt/X11/include as a potential location to search for X11 includes or simply did not get some of the above mentioned compile time flags right on your current system.
I have autoconf installed through homebrew -- ahh, great stuff, cheers.
Recently, in an attempt to try xmonad (which apparently requires X11 version >= 1.4.6.1), I tried upgrading Snow Leopard's native X11 via Macports. However, after upgrading, X11 has been acting strangely. For example, it won't automatically start quartz-wm (though it lets me do so manually via xterm). It also crashes after being inactive for long periods of time. Checking the console, I get the following errors: [org.macports.startx: No protocol specified]. Further, despite upgrading to X11 v1.9.2, xmonad still doesn't work, giving me the following error:
Configuring xmonad-0.9...
Setup.lhs: At least the following dependencies are missing:
X11 >=1.4.6.1 (!)
At this point, I decided to just give up on xmonad and use the native X11, but this is now giving me the exact same errors. In particular, the native X is telling me that it can't communicate with the display (:0.0) set in the DISPLAY variable (which apparently has been changed by macports' X11 install). Needless to say, this is very frustrating, and any help would be greatly appreciated. Thanks!
MacPorts does not upgrade Snow Leopards's X11, it installs a completely separate version of the X11 client libraries and whatever other packages you ask it to. This is a deliberate design decision with MacPorts and all its packages. By default and in general, MacPorts installs everything under /opt/local. To not use the MacPorts version, just make sure you do not include any /opt/local directories - particularly /opt/local/bin - in your shell environment variables - in particular PATH - or in any absolute paths to executables and libraries. If you want to totally remove MacPorts, the following will get rid of just about everything:
$ sudo rm -rf /opt/local
The X11 to which the Xmonad error message refers is the Haskell package http://hackage.haskell.org/package/X11/, which doesn't appear to require any particular numerical version of X11 proper or of the X server. In other words, you were barking up the wrong tree.
I'm trying to install QtROOT, and as part of the installation (specifically, the readme file in the QtROOT tarball at http://root.bnl.gov/QtRoot/downloads/qtFullRoot.tar.gz), it mentions to make sure that QTDIR is set. I've installed from the Qt 4.6.3 SDK installation for Mac OS X, and I have no such environment variable set. I've tried googling to figure out where it should be set to, but the options I've found (such as /usr/local/qt) don't exist. What should this variable be set to?
OS X 10.6.4, Qt 4.6.3, ROOT 5.26/00, QtROOT... I have no idea. :P
Thanks,
Paul
Qt's packaged installer for OSX scatters things throughout the /Developer and /Library directories rather than installing to a self-contained location in /usr/local or /opt/local as you might expect it to do on other unix-based systems.
Incidentally, Qt follows Apple's way of doing things in this respect, so it's really not wrong -- it's just different -- but it does make some 3rd party Qt applications somewhat difficult to build on OSX.
The packaged Qt installer itself has the following to say on this topic:
After a successful install, you can find most new things in /Developer. Specifically things will be located in the following places:
Qt Designer, Qt Linguist: /Developer/Applications/Qt
Qt Documentation: /Developer/Documentation/Qt
Qt Examples: /Developer/Examples/Qt
Qt Plugins: /Developer/Applications/Qt/Plugins
Qt Frameworks: /Library/Frameworks
Qt Libraries: /usr/lib
qmake, moc, uic, etc.: /Developer/Tools/Qt (symlink to /usr/bin)
Uninstall script: /Developer/Tools/uninstall-qt.py
So, it does put the libs into '/usr/lib', and it symlinks the essential Qt tools (like qmake) into '/usr/bin'. This suggests that QTDIR could be set to '/usr'. In practice however, this doesn't work because the qt headers remain buried in '/Library/Frameworks/Qt*/Headers/*.h', while builds that rely on $QTDIR will end up looking for the qt headers in "${QTDIR}/include/" instead.
The easiest way around all this is to build Qt from source. The install location will default to something like /usr/local/Trolltech/Qt-4.6.3 (note the version number, and adjust accordingly). You can override the default install location by using the -prefix option on ./configure.
A simpler approach is to let macports build it for you. This is the approach I ended up taking (and with good success). Just install macports, if you don't already have it. Then:
> sudo port selfupdate
> sudo port install qt4-mac
Macports will work its magic, and when it's done Qt will be installed, in its entirety, at /opt/local/libexec/qt4-mac.
Regardless of how you build Qt, expect a full build to take several hours. It's a very large code base.
I didn't install Qt from the installer (but compiled it myself), so I don't know the default location.
However, where you installed Qt, there is your QTDIR.
Search for qmake, it should reside in some bin/ folder. one up is QTDIR ($QTDIR/bin/qmake).
Usually it's not necessary anymore to set QTDIR these days to build a Qt project, just qmake must be in the PATH, everything else found then. But some projects might require it though (if they use a custom build system that still uses QTDIR).
I need to install LiteIDE on my mac and in the install guide, the QTDIR is necessary. I install the qt with the homebrew by brew install qt --build-from-source, it takes about 2 hours in RMBP. After the install finished, there is still no QTDIR path. By checking the build_osx.sh, i know it's just the parent folder of bin. so i set the path by export QTDIR=/usr/local/Cellar/qt/4.8.6. Then run the ./build_osx.sh again. it works.
Hope this will be helpful.
I'm sure this is a newbie question, but every time I've compiled/dl'ed a new version of vim for os x, running vim on the command-line opens up the gvim app. I just want to upgrade the console version (so I can, for example, have python compiled in to use omnicomplete).
If I understsood the question correcty, here is another solution: check out http://www.andrewvos.com/2011/07/23/upgrading-vim-on-os-x-with-homebrew/
Really simple, fast, painless. It uses homebrew-alt and you also need to have mercurial installed (it will prompt you if not).
You can also use MacPorts to handle the installation for you. Once you've installed it, run the /opt/local/bin/vim binary. I place this in my PATH before the system binary dirs (although be aware that this may cause problems for cmdline tools that rely on the versions of tools shipped with OS X).
This may sound stupid, but are you copying the vim binary to /usr/bin? by default, the "vim" path is /usr/bin/vim. If you compile from source, you'll likely need to either copy the vim binary to /usr/bin/vim (thus overwriting the original vim), or launch the compiled version via absolute path (eg. ~/vim-checkout/build/vim).
that's just a guess, however. I can't see it being anything more than that.
With Homebrew:
brew install macvim
ln -s /usr/local/bin/mvim /usr/local/bin/vim
Can also symlink your new binary to /usr/local/bin/