Content of configure.cc variable is sometimes duplicated.

[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

[nox@…]

Are you really running MP 1.6.0 or are you running a trunk/ build?

[afb@…]

trunk should identify as "1.7.0" with port version, so that should be easy to distingush from release...

[afb@…]

and no, I wasn't able to reproduce this. but "CC='/usr/bin/gcc-4.0 /usr/bin/gcc-4.0'" is broken.

[omar_green@…]

The version of macports I used is the same as is available from the download page. When queried for it's version, it reports 1.600 as the version.

[omar_green@…]

Update....

Been working a little on a workaround for this, since afb couldn't replicate my problem, and it seems I've found one. After successfully installing macports 1.6.0 onto my MacBook Pro (OS X 10.4.8) and performing a selfupdate (i.e. sudo port -v selfupdate), I was able to make some progress.

sudo port install rb-rubygems now installs correctly, without any hitches.

Getting things to work also required I switch over completely to X-Windows, and that I remove the original ruby installation (which I did manually) after I did the selfupdate.

I then re-installed ruby (with some grief), and then installed rb-rubygems. Compiles complete just fine after. Hopefully, this will cast some light on the nature of the problem.

What happens during a selfupdate?

[kballard (Lily Ballard)]

Since you say the selfupdate fixed it, I'll go ahead and mark this closed.

For future reference, selfupdate makes sure you have the latest code (and installs it if not), and then runs a port sync, which updates all your Portfiles.

[tobypeterson]

Milestone MacPorts base bugs deleted