Le 1 févr. 10 à 16:07, Ryan Schmidt a écrit :
Does this solution is valid even if I want to test a third-party
software that calls gcc ? For instance, Matlab is completely
independent from Macports. Will the gcc_select program work only
for "macported" softwares ?
For instance, to make Matlab use the version of gcc 4.2 instead of
4.0 (i have both), i simply change the symbolic links in /usr/bin
so that i can swap from gcc-4.0 to gcc-4.2. I can then restore the
original links whenever a software needs the original gcc. This was
quite handy for me. Is gcc_select really a cleaner solution than
this ?
Yes, it is.
Apple's gcc_select will handle changing the symlinks in /usr/bin for
you.
Our gcc_select will make the same kind of symlinks but in /opt/local/
bin. So all you have to do is have /opt/local/bin in your PATH,
which the MacPorts installer should have already done for you, and
now any software you build that wants "gcc" will use MacPorts gcc.
Note that using gcc_select (Apple's or ours) will have no effect for
any port built using MacPorts. It only has effect for software you
build manually on the command line.
I understand. Indeed, my PATH does contain the /opt/local/bin.
However, as the order of appearance in PATH matters, the software I
build manually will use whichever gcc comes first, right ? In which
case, if the macports-gcc pointed by the /opt/local/bin and the one in
usr/bin are different, one will have to play a bit with the PATH's
order, is that correct ? In the present case, as /opt/local/bin comes
first in the PATH, the default will be to use the macported gcc. Is
that correct ?
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
