I have a makefile project that I would like to port to Xcode.
I was following the instructions on:
https://developer.apple.com/library/mac/#documentation/Porting/Conceptual/PortingUnix/preparing/preparing.html
The document lists as important to install Xcode in the default "/usr" folder.
But the installer gives no such option.
And it installs the folder Devolopper in the "/" folder.
Is it safe to just move the whole content of "Developper" to "/usr" or should that be done during installation?
If so, how?
TFA says
If you are using makefiles for compilation, you should install Xcode in the default location (/usr). If you do not, you may have to do extra work to get your scripts to run the compiler, linker, and so on in a nonstandard location.
I'm guessing that the specific path is out of date, but the overall advice of installing Xcode in the standard place is sound. I recommend you use the Xcode installer, which puts make and gcc in the proper places and not worry about /usr in particular.
You certainly do NOT need to move /Developer to /usr. The docs must be talking about /usr/llvm-gcc-4.2/ folder and others which will be created when Xcode is installed into /Developer. You don't need to do anything special for that.
When Xcode tools are installed to the default location (/Developer), the installer creates aliases for developer tools in /usr locations automatically. Install and everything will just work: make, gcc, ld and everything else will appear in $PATH. In short, just install and that will be it.
I don't know why the doc says it that way, it must be mistake or misunderstanding.
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.
I am learning to build a compiler using LLVM as back end.
I followed the steps on getting started with the LLVM system until setting up your environment
What is the specific location for [/path/to/your/bitcode/libs] ?
Was this mistake cause the command not found when I type in lli in a Terminal?
//I am trying to build a hello world to see through the total compiling procedure
You can put LLVM_LIB_SEARCH_PATH wherever you want. For now, you probably don't need to worry about it at all; as the documentation says, it is optional. Later, you may create bitcode (i.e. compiled VM code) functions which you would like to link into the bitcode your compiler produces. For example, you may need to create some kind of standard library and runtime environment for your executables.
That has nothing to do with the lli not found error, which is the result of the LLVM binaries either not having been installed, or having been installed somewhere which is not in your $PATH.
By default, the llvm package will configure itself for installation under the prefix /usr/local, which means that after you gmake install you should find lli and friends in places like /usr/local/bin/lli. That may or may not be in your $PATH; to find out, type
echo "$PATH"
and see if it has :/usr/local/bin: somewhere in it. If it doesn't, then you could change your PATH:
export PATH="/usr/local/bin:$PATH"
To make that permanent, you'll have to add it to your bash startup files.
But you might not want it to be installed there. I usually install software I'm playing with in my local directory tree, so that I don't have to sudo all the time. You can change the root of the installation directory tree with the --prefix argument to ./configure. (You have to do that before you build LLVM.) ./configure --help will provide some more information about configure options, but --prefix is certainly the most important one.
Whatever you do, don't do it blindly. Make sure you understand what this all means before doing it. If you plan on making a compiler, you'll need to understand some of the details of a typical build- and runtime- environment; PATH and configure scripts are on the unfortunately long list of things you should at least be somewhat familiar with.
As I understand it, some version of LLVM is already installed on Mac OS X, so you'll need to be careful that your installation doesn't interfere. The fact that bash is report that lli can't be found probably indicates that not all the tools are installed, which will make things less complicated.
I'm afraid that I don't really have any experience with installing LLVM on a Mac, but if you run into specific problems (like "my compiler doesn't work after I install LLVM") then you could ask a specific question with appropriate tags.
I don't know whether this is actually an SDL issue or just me not knowing how to build packages from msys/mingw. What I have done thus far:
downloaded latest mingw-get-inst.exe from sourceforge and ran it. This installed a C:\MinGW\ directory with msys inside. This brought me to my first bit of confusion. When I opened the mingw shell, rather than bringing me to my /home/ directory as I expected ( I have used mingw before and remember this being weird ) it placed me in /c/Users/me/.
I figured that this must be my home directory and put the extracted SDL-1.2.15/ in this location.
I then ran:
cd SDL-1.2.15
./configure --help
but received sh: ./configure: No such file or directory.
I then created a /c/MinGW/msys/1.0/home/ directory, set that as the HOME environment variable, moved the SDL folder into it and tried to configure again with the same result.
There are a few things I really dont understand about installing packages that I hope someone can clear up. I have installed a few before and the ./configure; make; make install; seems to be a common procedure. I know msys provides the functionality for make, but is configure a file that is supposed to be included in each package? If so, why is it not in the SDL package/how do configure it?
I have been following instructions from here and they seem to have worked for others in the comments. The bottom-most comment tells that mingw-get-inst works, though I did try it both ways.
I have a feeling my lack of msys/mingw knowledge is my problem.
I am on windows 7.
I had the same problem as you describe and I got SDL, SDL_image and SDL_ttf working after some research.
It seems that the configure file exists only in the source code packages. I found that out after I downloaded the SDL_image source. So, the problem probably lies in that the configure file comes only in the source packages.
However, I'm having other problems so I'm not sure this has fixed it for me, but it seems like it should.
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've installed XCode v3.1.3 and am having difficulties using the rumored GCC that is installed along with it. -- I'm certainly able to use the XCode IDE to compile my programs but would like the flexibility of also using the command line...
Where's GCC?
Look in /Developer/usr/bin
The most likely explanation is that when you installed the Developer tools you unchecked "UNIX Development Support", so the command line tools were never installed. Delete your /Developer/ directory and do a clean install of the tools; make sure to select "configure" during the installation process and ensure that the appropriate items are checked.
In /usr/bin you should find gcc-4.0 and gcc-4.2 and then there will be a symbolic link gcc which points to one of these (usually gcc-4.2).
As always, you can find out where any available command in your PATH is located using which, e.g.
$ which gcc