Re: help with installing gcc in os x please.

["Andrea 'fwyzard' Bocci" <fwyzard at inwind dot it>]

> At 20.09 23/12/2002 +0000, Ben Dougall wrote:
> fwyzard: thanks very much for such a thorough response :)
Hi Ben,
I'm happy I could help you somehow. Let's try to get it worked to the happy 
ending :-)

This time, I'll start answering from your last questions. Let's begin with 
some general infos, then.

> > In this way you'll get gcc & co. in /usr/local/bin.
> i've never quite understand that - i've seen /usr/local/bin mentioned a 
> lot but where/what is it? i don't seem to have a folder called bin in a 
> folder called local... anywhere. is it a kind of virtual path?! i'm 
> guessing. what i mean is, is it something that isn't going to be 
> represented by folders/directories that i can see like normal folders 
> represented as icons in the finder? i guess usr may be my user name rather 
> than 'usr', but i still can't see what that means.
>
> so i'm not sure if it's succeeded or not. it may easily have worked and 
> i'm just not sure how to access the new gcc rather than the apple gcc.
/usr/local/bin is a folder. There's nohing "special" about it, it's just a 
conventional folder to store "non-standard" binaries.
OK, maybe that was not too clear. From the beginnin', then.

Under Unix (and DOS, and Windows if you look around a bit), and MacOS, I 
guess, everyting is organized in folders.
The "position" where an executable, or any other file, is, is called "path".
  Under Unix, paths are of the form "/usr/bin", or 
"/home/fwyzard/Desktop", or "../../src/include".
The first two are "absolute" paths, meaning that thay start from the "root" 
("/") of the filesystem, and dig onward.
The last one is a "relative" path (it does not start with a "/"),. meaning 
that it starts from the current directory, and move backwards and onwards. 
Two special paths are defined for every folder: ".", meaning the current 
folder, and ".." meaning the current folder's parent.
  Under DOS/Windos, thigs are almost the same, with 2 differences: the 
"path separator" is backslash ("\") instead of a forward slash ("/"), and 
there is not just a single root (like / under Unix) for the filesystem, but 
one for each drive, identified by the drive letter followed by a colon 
(":") and a backslash ("\")  ("A:\" is usually the floppy disc, "C:\" 
usually the system HD, "D:\", "E:\" tend to be the CDs, etc...).
  Under MacOS I don't know haw it actually works, as of it I've seen only 
the surface (the GUI). As MacOS X is derived from a Unix kernel (the OS 
core), I guess it follows the Unix convention, using the POSIX style "/" as 
a path separator and starting from a single root. (This is confirmed by the 
chunks from your configure and make output).
  Note: POSIX stands for a kind of standard among different Unices, 
specifyng common formats and commands, like the pah separator, etc.
  History: I read that until MacOS 9, things were diferent, using a colon 
":" for the folder separator/current folder.

  When you run a program, the system needs a way to find it, and looking 
trough ALL of your HDs would take too long.
Under a Graphical Interface you usually run the program by clicking on an 
icon or menu item.
Under MacOS, if I remember correcly, the icon represent the "actual" 
program, and you usually have to navigate to it folder to run it. I guess 
you can also create "links" from the program to other locations, so that 
you can have many "links" to the programs you use most in a single, easy to 
access, location.
This is the way used under Windows, anyway, and in a way under Unix. The 
"link" points to the location where the program is, so that the system can 
find it and run it.
The first solution, then, is to (manually or via a link) explicitly tell 
the system where the program is.
  When you have lots of programs (eg., especially under a command line OS 
or when running from the "terminal", all the system commands to manipulate 
files and configure the system), this becomes increasingly cumbersome. The 
solution is to create a list of places where the executables are kept, and 
tell the system to search there when it needs to find a program. Such a 
list is usually an evironment variable (*) called PATH.
An example PATH under Unix might be 
PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/fwyzard/bin...
  Sidenote: as a security measure, under most Unices if you want to run a 
program from the current location, ie. where you "are" in the terminal 
window, you need to explicitly say so, running the program as 
"./myprogram". The leading "." indicates the currend directory, the "/" is 
the folder separator, followed by the program you want to run.

Back to our problem.
/usr indicates the fodler under which most "user level" programs go.
When you install programs from an "official" distribution, it is usually 
installed under /usr/bin (/bin for the most important system utilities); on 
the othe hand, programs manually installed, ie. "local" to your system, 
like GCC compiled from the sources, usually go into /usr/local/bin.

Assuming that compiling went along alright (after patching), and 
installation, too (with your -pword thing), the only problem that remains 
is hat he sysytem cannot find your newly made GCC.
To test that everything alse is OK, and that the only problem is the PATH, 
you can try this:
1.) go to /usr/local/bin (from the 2nd make install output, I assume that 
creating the dir worked) with
cd /usr/local/bin
2.) try to run gcc from there, with
./gcc -v
and
./gccc -v
(to test both your installations).

If this works, then the only problem is the missing PATH variable setting. 
To solve this you need to ask a MacOS user, as I don't know how to set it 
up on your system (maybe somewhere in a kind of Control Panel, maybe :-).

If this fail, try to send to the list the erros that you got, I (and 
hopefully somone with more experience with MaxOS X) will try to figure out 
what is wrong.
If this actually works, I think we're almost done.

> > The first step is the configuration: this stage sets things up to build 
> > GCC for your particular machine and usage, eg.: if you want to use it to 
> > compile for that same machine [native compiler] or to build binaries that 
> > will run on a different kind of machine (the target) [cross compiler]. 
> > You could alse make on a machine A a compiler that will run on machine B 
> > building binaries for machine C. :-)
> slightly separate question - this isn't what i'm trying to achieve at the 
> moment, but i'd really like to know for future:
> if the target machine and your machine are both macs and both running os x 
> (but maybe not the same version of os x, but say at least both 10.2 or 
> higher) is it ok to copy the compiled gcc from your machine to another 
> machine? copy gcc after it's been compiled on one machine, over to a 
> similar but different machine?
I think that it is quite possible yes, and that it will probably work.
The best way to do it I can figure out is to install your newly made GCC in 
an empty, all for itself, folder, then copy it with all its subfolders IN 
THE VERY SAME PLACE on the 2nd machine.
To specify the install directory, you need to add another option to 
configure, namely "--prefix=installdir". A good place could be 
/usr/opt/gcc, for example, or whatever you like:

../[folder where you unpacked gcc]/configure --enable-threads=posix 
--enable-shared --prefix=/usr/opt/gcc --program-prefix=fsf- 
[--disable-multilib if you want]

The --program-prefix is just like the --program-suffix command, but it 
adds, strangely enough, a prefix instead of a suffix. Use whichever you 
prefere :-) .

Then you must add /usr/opt/gcc/bin to your PATH (or run gcc as 
/usr/opt/gcc/bin/gcc, but that's a bit awkward, I admit).
If it works, it'll probably work on any other similar enough machine, 
provided you unpack it exactly in the same plae and configure PATH on that 
machine, too.

> does the installation process put files outside of the objdir folder, or 
> is the final executable gcc all contained in that objdir folder?
The final GCC is contained in the objdir folder, along with all the 
temporary thiongs it used to boostrap (all in almost 3 copies, remember). 
After installing (make install) you can safely delete the objdir folder 
(and the srcdir one, or course, when you're done building all the things 
you need); the installed GCC should be way smaller. For example, the latest 
RedHat Linux package for the core (C only) GCC 3.2.1 is slighlty more than 
11 MB.

> thanks again for a very helpful set of instructions,
>
> ben.
I hope this time we can make it to the end !
Good luck,
fwyzard

PS.
If in the end you get it working, would you mind writing a small summary of 
the instrctions and posting it to gcc@gcc.gnu.org, so that it can be linked 
from GCC 3.2 results page ?