help2man-1.36.4 configure fails as compiler cannot create executable

[omar_green@…]

Sent this note last night, and per the direction of Anders Björklund (who also counts this as a bug), I'm filing this bug report.

Most of the details of the bug are in the email, but the highlight is this: when configuring help2man-1.36.4, the compile doesn't finish as $(CC) has been doubly defined as "CC='/usr/bin/gcc-4.0 /usr/bin/gcc-4.0'" This eventually throws off the linker, and fails the configure.

There's an additional problem of the gcc -V flag not working. Looks like within OS X, the lowercase "v" must be used, if the intent is to extract the version of gcc in use.

Anders indicates in his email that the problem is related to bug #13930 "and friends," his phrase, and that he suspects "something wrong between base/libtool/portfile interaction..."

The original email follows.

---

Hi all:

Total n00b to macports here, but I'm having problems using macports to install Ruby-on-Rails on an Intel MacBook Pro, and I think I've managed to track the problem down. Didn't want to post a bug to the bug list without verifying that I'm not just imagining things.

So, I'm on a MacBook Pro, running OS X 10.4.11, and macports 1.600. I found my initial install instructions here: ​http://wiki.rubyonrails.org/rails/pages/Installation

Installed Xcode 2.5 with no problems, along with macports. Was even able to get the ruby install going before I hit a problem: installing rubygems.

The rubygems install fails on trying to configure help2man.

My builds have been failing with the following info:

---> Configuring help2man Error: Target org.macports.configure returned: configure failure: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macport s.org_release_ports_textproc_help2man/work/help2man-1.36.4" && ./configure --prefix=/opt/local --mandir=/opt/local/share/man --infodir=/opt/local/share/info " returned error 77 Command output: checking for perl... /opt/local/bin/perl checking for gcc... /usr/bin/gcc-4.0 /usr/bin/gcc-4.0 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details.

Having looked through the config.log, I noticed something peculiar.

ac_cv_env_CC_value='/usr/bin/gcc-4.0 /usr/bin/gcc-4.0'

and

CC='/usr/bin/gcc-4.0 /usr/bin/gcc-4.0'

The result is that $CC is doubly defined which seems the screw up the linker, as is evidenced here:

configure:1632: $? = 1 configure:1655: checking for C compiler default output file name configure:1658: /usr/bin/gcc-4.0 /usr/bin/gcc-4.0 -O2 -I/opt/local/include -L/opt/local/lib conftest.c >&5 /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: /usr/bin/gcc-4.0 is input for the dynamic link editor, is not relocatable by the static link editor again collect2: ld returned 1 exit status

I also noticed that the "-V" flag for gcc-4.0 is causing an error.

configure:1629: /usr/bin/gcc-4.0 /usr/bin/gcc-4.0 -V </dev/null >&5 gcc-4.0: argument to `-V' is missing

I did attempt to do the configure and make manually from directly within the build directory, and they completed no problem. This problem only seems to happen when I run:

sudo port install rb-rubygems.

I wouldn't have necessarily thought this was a bug (maybe double referencing CC is just how you guys roll), but I stumbled on a different bug while Googling around trying to diagnose the problem (completely different system, but consistent behavior):

​http://www.nabble.com/problem-linking-td12382127.html

Seeing this changed my mind, so I decided to roll up my sleeves and send an email. Please forgive me if this is total spam.

So, can someone here verify that what I'm seeing isn't normal and let me know if this is covered in the bug log or not? I did do a search of the bug log, with all the terms I could think of, but didn't find anything.

Thanks in advance for all your help.

Best,

-O