I think I've found a bug in configure for help2man, but would like to verify
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
Omar Green wrote:
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)
No it's not a particular rolling style, Some ports are getting GCC twice - that's a bug. (did you file a ticket?) Some ports are getting no GCC - that's a bug too. (bug #13930 and friends) I would suspect something wrong between base/libtool/portfile interaction... It's supposed to look something like: "checking for gcc... /usr/bin/gcc-4.0" But some aren't expecting $CC to be a path. --anders
I''ve entered in a bug for this now, bug #14213. Set the priority to normal, and I have no idea how you guys prioritize. Thanks a bunch, Anders for the swift reply. Guess, for now I'll have to get the install of Ruby done manually. Best, -O Anders F Björklund wrote:
Omar Green wrote:
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)
No it's not a particular rolling style, Some ports are getting GCC twice - that's a bug. (did you file a ticket?) Some ports are getting no GCC - that's a bug too. (bug #13930 and friends)
I would suspect something wrong between base/libtool/portfile interaction... It's supposed to look something like: "checking for gcc... /usr/bin/gcc-4.0" But some aren't expecting $CC to be a path.
--anders
On Feb 6, 2008, at 15:27, Omar Green wrote:
Anders F Björklund wrote:
Omar Green wrote:
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)
No it's not a particular rolling style, Some ports are getting GCC twice - that's a bug. (did you file a ticket?) Some ports are getting no GCC - that's a bug too. (bug #13930 and friends) I would suspect something wrong between base/libtool/portfile interaction... It's supposed to look something like: "checking for gcc... /usr/bin/gcc-4.0" But some aren't expecting $CC to be a path.
I''ve entered in a bug for this now, bug #14213.
Thanks!
Set the priority to normal, and I have no idea how you guys prioritize.
FYI, priorities are explained in the guide: http://guide.macports.org/#project.tickets.guidelines "High - Reserved for the use of MacPorts team members, as they are the best fit to determine which reports warrant a higher priority over others." "Normal - The default. For normal port failures, non-critical enhancement requests, non-critical port failures." "Low - For mostly cosmetic improvements, documentation corrections/ improvements, etc." Though these descriptions could use some work. Users may be left to wonder under what priority they should file critical port failures or critical enhancement requests, or by what criteria a failure or enhancement request can be designated as critical.
Thanks a bunch, Anders for the swift reply. Guess, for now I'll have to get the install of Ruby done manually.
participants (3)
-
Anders F Björklund
-
Omar Green
-
Ryan Schmidt