Refresher on gcc port and the executables

[Tabitha McNerney]

On Wed, May 22, 2013 at 1:15 PM, Lawrence Velázquez <larryv at macports.org>wrote:

> On May 22, 2013, at 8:17 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> > On May 22, 2013, at 05:25, Tabitha McNerney wrote:
> >
> >> Its been some time since I looked more deeply at the GCC ports. On a
> new Mac recently I installed MacPorts and then specifically installed gcc47
> into my port prefix path /opt/local
> >>
> >> I looked today and realized there are several binaries (in
> /opt/local/bin), such as:
> >>
> >> gcc-ranlib-mp-4.7
> >> gcc-nm-mp-4.7
> >> gcc-mp-4.7
> >> gcc-ar-mp-4.7
> >> g++-mp-4.7
> >>
> >> and:
> >>
> >> x86_64-apple-darwin12-gcc-ranlib-mp-4.7
> >> x86_64-apple-darwin12-gcc-nm-mp-4.7
> >> x86_64-apple-darwin12-gcc-mp-4.7
> >> x86_64-apple-darwin12-gcc-ar-mp-4.7
> >> x86_64-apple-darwin12-gcc-4.7.2
> >> x86_64-apple-darwin12-g++-mp-4.7
> >>
> >> I forgot what the difference means in the above examples.
>
> There is no difference. They're hard links to the same files:
>
>     % for f in {gcc{-ranlib,,-nm,-ar},g++}-mp-4.7; do
>     for>            stat -f 'inode %i: %N'
> /opt/local/bin/{,x86_64-apple-darwin12-}$f;
>     for>            echo;
>     for> done
>     inode 40693975: /opt/local/bin/gcc-ranlib-mp-4.7
>     inode 40693975: /opt/local/bin/x86_64-apple-darwin12-gcc-ranlib-mp-4.7
>
>     inode 40693973: /opt/local/bin/gcc-mp-4.7
>     inode 40693973: /opt/local/bin/x86_64-apple-darwin12-gcc-mp-4.7
>
>     inode 40693974: /opt/local/bin/gcc-nm-mp-4.7
>     inode 40693974: /opt/local/bin/x86_64-apple-darwin12-gcc-nm-mp-4.7
>
>     inode 40693972: /opt/local/bin/gcc-ar-mp-4.7
>     inode 40693972: /opt/local/bin/x86_64-apple-darwin12-gcc-ar-mp-4.7
>
>     inode 40693966: /opt/local/bin/g++-mp-4.7
>     inode 40693966: /opt/local/bin/x86_64-apple-darwin12-g++-mp-4.7
>
> The argv[0] each executable sees does depend on the name used to call it,
> so runtime behavior might be different, or even incorrect. (I have not
> tried it.) But they're still just different names for the same files.
>


Thank you for pointing that out, I hadn't inspected enough to realize they
are hard links.



>
> >> If I want to compile some C or C++ code without any help from Apple's
> tools (for example the way I might do on a Linux system), would I simply
> use the top list (gcc* and g++*) and avoid the bottom list (x86*)?
> >
> > Yes.
>
> How divorced are you hoping to get from "Apple's tools"? Our GCC ports
> still use, at a minimum, Apple's assembler and archiver (via cctools) and
> linker (via ld64), as well as OS X's bundled zlib.
>

For a particular project I am working on, my boss asked me if there was a
way to compile some code from source (which depends on and will use of some
advanced cryptography potentially for highly sensitive business), such
that, in his words, "it is not dependent on any compiler tools from a
corporation like Apple, Google or Microsoft" and he said "it should be the
same as what is used by open source Linux distros". So this would mean gcc
but it makes me think I might need to do something unique such as making
gcc from source on my own since my boss doesn't want there to be any
company fingerprints (he's really worried but also its his job that could
be on the line). For special purposes, is it fairly easy to make gcc and
g++ from source, on OS X, in a way that is in fact "divorced" from the
Apple tools?



>
> >> I also have Xcode installed on this Mac and for some code to compile I
> do not want to use Apple's gcc bundled with Xcode. So given the above, do I
> need to use gcc_select and if so any suggestions on how best to do so?
> >
> > If you want "gcc" to be a MacPorts compiler instead, use "sudo port
> select gcc" (which was several years ago known as "gcc_select"). You can
> learn more about how to use "port select" by running "port help select".
>
> You might also be able to configure Xcode to run your desired compiler
> directly (e.g., "/opt/local/bin/gcc-mp-4.7").
>

If I do this, the same will apply from what you wrote above, true (about
the assembler, archiver, linker, zlib)?

Thank you for the suggestions!

-Tabitha



>
> vq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20130522/3d10f93c/attachment.html>