DarwinPorts and C++ Compiler issue

[brianlan]

Hello everyone I am fairly new to "porting" of software to the mac... So please bear with me.

So here is what I have done. First I installed DarwinPorts 1.3.1-1.4.dmg from the offical site. Next I downloaded the latest copy of XCode tools 2.4 from apple and installed it. Now I have been using the Port Authority GUI to manage the install of ports from DarwinPort's. I managed to install 'nget' from list with ease, no errors, and it works great...

But I quickly realized that 'nget' is not what I really wanted. So I went back to install 'hellanzb' from the list of available programs. It went through all the motions of compiling the source and what not, after about 10 mins of compiling various things, it tried to compile 'par2' which I guess is a dependency of 'hellanzb'. Now it errors out stating the follow error message...


---> Configuring par2
checking build system type... i686-apple-darwin8.7.1
checking host system type... i686-apple-darwin8.7.1
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking for C++ compiler default output file name... configure: error: C++ compiler cannot create executables
See `config.log' for more details.
Warning: the following items did not execute (for par2): com.apple.activate com.apple.configure com.apple.build com.apple.destroot com.apple.install


Now I know I just installed Xcode 2.4, what could be causing the C++ compiler to not allow creation of executibles? I think that 'nget' used the C compiler, but I am not sure... Why would one compiler come out of the box configured to create executibles and one not?

Thanks a bunch for the help!

BRIANLAN

[hayne]

I see from the log messages that you have an Intel Mac - which one?

Note that the log messages said to look in "config.log" for more details. What is in that file?

[polymorph]

stegdetect won't build on my intel mac. This appears to be the relevant part of the logs:

configure:1445: checking for C++ compiler version
configure:1448: /usr/bin/g++-3.3 --version </dev/null >&5
g++-3.3 (GCC) 3.3 20030304 (Apple Computer, Inc. build 1819)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:1451: $? = 0
configure:1453: /usr/bin/g++-3.3 -v </dev/null >&5
Using built-in specs.
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1819)
configure:1456: $? = 0
configure:1458: /usr/bin/g++-3.3 -V </dev/null >&5
g++-3.3: `-V' option must have argument
configure:1461: $? = 1
configure:1481: checking for C++ compiler default output
configure:1484: /usr/bin/g++-3.3 conftest.cc >&5
g++-3.3: installation problem, cannot exec `cc1plus': No such file or directory
configure:1487: $? = 1
configure: failed program was:
#line 1465 "configure"
#include "confdefs.h"

I reinstalled XCode Tools from the installation CD without any luck. The compiler seems to be where it's expected so I'm at a loss....

$ ls -l /usr/bin/gcc*
lrwxr-xr-x 1 root wheel 7 Aug 16 08:29 /usr/bin/gcc -> gcc-4.0
-r-xr-xr-x 1 root wheel 264712 Jan 13 2006 /usr/bin/gcc-3.3
-rwxr-xr-x 1 root wheel 80484 Jan 13 2006 /usr/bin/gcc-4.0
$ ls -l /usr/bin/g++*
lrwxr-xr-x 1 root wheel 7 Aug 16 08:29 /usr/bin/g++ -> g++-4.0
-r-xr-xr-x 1 root wheel 268808 Jan 13 2006 /usr/bin/g++-3.3
-rwxr-xr-x 1 root wheel 80484 Jan 13 2006 /usr/bin/g++-4.0
$

[Danielo]

I have the same problem... I'm on a spanking new Mac Pro with the default installation.

It seems that the x86 version of the compiler was simply not included on the install disks. Actually:


danielo> find /usr -name "cc1plus"
/usr/libexec/gcc/darwin/ppc/3.3/cc1plus
/usr/libexec/gcc/darwin/ppc/3.3-fast/cc1plus
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/cc1plus
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/cc1plus


Opening gcc3.3.pkg with PackageMaker I find that, indeed, there is only ppc under /usr/libexec/gcc/darwin.

[hayne]

Opening gcc3.3.pkg with PackageMaker I find that, indeed, there is only ppc under /usr/libexec/gcc/darwin.
I think you need to use gcc 4 (not 3.3)

[blb]

The issue is that some ports have been specifically configured to build with gcc3.3; usually because they won't build successfully with gcc4 (which is more picky with certain code). This either means an upstream change with the code or a port maintainer that knows enough about the issues to fix it him/her self.

[Danielo]

The issue is that some ports have been specifically configured to build with gcc3.3; usually because they won't build successfully with gcc4 (which is more picky with certain code). This either means an upstream change with the code or a port maintainer that knows enough about the issues to fix it him/her self.

I sent a question to the xcode-users list, but I should have read the release notes before:

http://developer.apple.com/releasenotes/DeveloperTools/GCC3.html


The gcc 3.3 compiler does not support generating code for x86.

So that's it. The changes needed to move a codebase from gcc 3 to gcc 4 can be important, and I imagine that many of the ports that currently require gcc 3 will end up being removed. That includes all older versions of gcc, which is a bummer.

[blb]

...
So that's it. The changes needed to move a codebase from gcc 3 to gcc 4 can be important, and I imagine that many of the ports that currently require gcc 3 will end up being removed. That includes all older versions of gcc, which is a bummer.

Yeah, older versions of gcc could definitely be an issue for Intel-based, but hopefully ports will, in time, be updated for gcc4 by the software author or a motivated person submitting patches.

[dmacks]

Updating the code to gcc4 doesn't involve (necessarily) removing support for gcc3.3 and below. The most common situations involve code structures that were poorly written but acceptible enough for the compiler to figure out what to do (and in some cases used to cause compiler warnings anyway. gcc3.1 was more strict about those issues than 2.95, gcc3.3 more than that, and now gcc4 is even more strict about lots of formerly-tolerably-bad code.