Ticket #25120 (closed defect: fixed)
dos2unix doesn't ensure it's UsingTheRightCompiler
| Reported by: | andre.david@… | Owned by: | waqar@… |
|---|---|---|---|
| Priority: | Low | Milestone: | |
| Component: | ports | Version: | 1.8.2 |
| Keywords: | Cc: | nox@…, ryandesign@… | |
| Port: | dos2unix |
Description
I think the change in #19347 is biting me. I am trying to rebuild all ports with gcc44 as default compiler and I get
---> Verifying checksum(s) for dos2unix
DEBUG: Executing org.macports.checksum (dos2unix)
---> Checksumming dos2unix-4.1.2.tar.gz
DEBUG: Correct (md5) checksum for dos2unix-4.1.2.tar.gz
DEBUG: Correct (sha1) checksum for dos2unix-4.1.2.tar.gz
DEBUG: Correct (rmd160) checksum for dos2unix-4.1.2.tar.gz
---> Extracting dos2unix
DEBUG: Executing org.macports.extract (dos2unix)
---> Extracting dos2unix-4.1.2.tar.gz
DEBUG: setting option extract.args to /opt/local/var/macports/distfiles/dos2unix/dos2unix-4.1.2.tar.gz
DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.6'
DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_dos2unix/work" && /usr/bin/gzip -dc /opt/local/var/macports/distfiles/dos2unix/dos2unix-4.1.2.tar.gz | /usr/bin/gnutar --no-same-owner -xf -'
DEBUG: Executing org.macports.patch (dos2unix)
---> Configuring dos2unix
DEBUG: Using compiler 'Mac OS X gcc 4.2'
DEBUG: Executing org.macports.configure (dos2unix)
---> Building dos2unix
DEBUG: Executing proc-pre-org.macports.build-build-0
DEBUG: Executing org.macports.build (dos2unix)
DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.6'
DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_dos2unix/work/dos2unix-4.1.2" && /usr/bin/nice -n 20 /usr/bin/make -j4 all prefix=/opt/local CFLAGS_OS="-O2 -I/opt/local/include -arch x86_64 -arch i386" LDFLAGS_EXTRA="-L/opt/local/lib -lintl -arch x86_64 -arch i386"'
gcc -DVER_REVISION=\"4.1.2\" -DVER_DATE=\"2010-01-24\" -O2 -I/opt/local/include -arch x86_64 -arch i386 -DENABLE_NLS -DLOCALEDIR=\"/opt/local/share/locale\" -DPACKAGE=\"dos2unix\" -O2 -Wall -D_LARGEFILE_SOURCE -c dos2unix.c -o dos2unix.o
ln -sf dos2unix.1 mac2unix.1
cc1: error: unrecognized command line option "-arch"
cc1: error: unrecognized command line option "-arch"
make: *** [dos2unix.o] Error 1
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_dos2unix/work/dos2unix-4.1.2" && /usr/bin/nice -n 20 /usr/bin/make -j4 all prefix=/opt/local CFLAGS_OS="-O2 -I/opt/local/include -arch x86_64 -arch i386" LDFLAGS_EXTRA="-L/opt/local/lib -lintl -arch x86_64 -arch i386" " returned error 2
DEBUG: Backtrace: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_dos2unix/work/dos2unix-4.1.2" && /usr/bin/nice -n 20 /usr/bin/make -j4 all prefix=/opt/local CFLAGS_OS="-O2 -I/opt/local/include -arch x86_64 -arch i386" LDFLAGS_EXTRA="-L/opt/local/lib -lintl -arch x86_64 -arch i386" " returned error 2
while executing
"command_exec build"
(procedure "portbuild::build_main" line 9)
invoked from within
"$procedure $targetname"
Warning: the following items did not execute (for dos2unix): org.macports.destroot org.macports.build
DEBUG: couldn't read file "/opt/local/share/macports/Tcl/darwintrace1.0/pkgIndex.tcl": no such file or directory
while executing
"source [file join $dir pkgIndex.tcl]"
Error: Unable to upgrade port: 1
To report a bug, see <http://guide.macports.org/#project.tickets>
Basically, it seems that some smartness picks up the built-in XCode gcc 4.2 which then fails to build with -arch. All other ports are rebuilding fine (up to gcc in alphabetical order).
Hints appreciated.
Attachments
Change History
comment:2 Changed 3 years ago by jmr@…
Exactly the opposite problem actually. Apple's GCC supports -arch but FSF GCC does not, so the latter can't build universal binaries. The makefile is calling just "gcc" which you've probably configured to be a symlink pointing to gcc-mp-4.4 using gcc_select.
comment:3 Changed 3 years ago by jmr@…
- Cc nox@… added
This was previously working, but was broken by r62515.
comment:4 in reply to: ↑ description ; follow-up: ↓ 6 Changed 3 years ago by ryandesign@…
- Cc ryandesign@… added
Replying to andre.david@…:
I am trying to rebuild all ports with gcc44 as default compiler
I wasn't clear from your wording on exactly what you were trying to do, but if you used gcc_select to select MacPorts gcc44 and are now trying to rebuild all ports to use that gcc44, then that won't happen; MacPort is designed to use its built-in defaults for compilers (Apple gcc 4.2 on Snow Leopard, Apple gcc 4.0 on Leopard and Tiger). Ports are tested with those compilers. Ports are not tested with some arbitrary other compiler so we will not help you attempt to rebuild ports that way, and that's why MacPorts is specifically designed to not use the compiler you've gcc_select'ed. You've discovered that the dos2unix port has a bug: it actually does use the compiler you've gcc_select'ed, so we'll fix that bug.
comment:5 Changed 3 years ago by ryandesign@…
- Summary changed from dos2unix does not build universal variant to dos2unix doesn't ensure it's UsingTheRightCompiler
comment:6 in reply to: ↑ 4 Changed 3 years ago by andre.david@…
Sorry if I was not clear.
Replying to ryandesign@…:
MacPort is designed to use its built-in defaults for compilers (Apple gcc 4.2 on Snow Leopard, Apple gcc 4.0 on Leopard and Tiger).
But isn't this what #19347 should have fixed (move from gcc to ${configure.cc})? (Ok, inspecting the present Portfile it seems the change was lost somewhere down the line.)
Thanks.
comment:7 Changed 3 years ago by ryandesign@…
Yes, #19347 did fix it, by replacing the hardcoded "gcc" with "${configure.cc}" in the Portfile. At the time, the Portfile did not use dos2unix's Makefile. But then r62515 updated the port to version 4.1 and rearranged things so that the Makefile is now used, without telling the Makefile what compiler to use (which is necessary because this software does not have a configure script which would have done so for us) thus reintroducing the problem. The patch Joshua attached to this ticket fixes the problem again.


Please remember to cc the maintainer.