Opened 8 years ago

Closed 6 years ago

#31167 closed defect (fixed)

gettext: pre-release Xcode 4.2's clang 3.0 compiles a flawed xgettext, complains of gettext:1:pass-c-format

Reported by: dossy@… Owned by: ryandesign (Ryan Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: clang Cc: hpacheco@…
Port: gettext

Description

Using MacPorts 2.0.3 on OS X Lion 10.7.1 and Xcode 4.2 (Developer Preview), building gettext-0.18.1.1 using Portfile r81158.

If your xgettext does this:

$ xgettext
xgettext: A --flag argument doesn't have the <keyword>:<argnum>:[pass-]<flag> syntax: gettext:1:pass-c-format

which I noticed when trying to install gnome-doc-utils which failed because of this, then you may be seeing a bug in clang.

Specifically:

$ clang --version
Apple clang version 3.0 (tags/Apple/clang-209.9.2) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.1.0
Thread model: posix

The clang bug is documented here:

http://lists.cs.uiuc.edu/pipermail/llvmbugs/2011-May/018101.html

I confirmed that this is what's biting me in the ass by building gettext using the same configure args that MacPorts does, but setting CC=gcc and CXX=g++, removing clang from the picture. It now builds an xgettext binary that does this, as expected:

$ xgettext
xgettext: no input file given
Try `xgettext --help' for more information.

Simple patch to do the override attached, but the bigger question is: why is MacPorts using clang?! What was wrong with gcc -O2 ... :-(

Attachments (1)

gettext-clang-borken.patch (475 bytes) - added by dossy@… 8 years ago.
patch to Portfile to force use of gcc/g++ instead of clang/clang++

Download all attachments as: .zip

Change History (18)

Changed 8 years ago by dossy@…

Attachment: gettext-clang-borken.patch added

patch to Portfile to force use of gcc/g++ instead of clang/clang++

comment:1 Changed 8 years ago by mf2k (Frank Schima)

Keywords: bug removed
Owner: changed from macports-tickets@… to ryandesign@…

comment:2 Changed 8 years ago by Veence (Vincent)

GCC use will eventually be deprecated and removed from Xcode at some point, if we understand Apple strategy correctly. So we better shift to clang as soon as we can.

Every compiler is buggy, even gcc, though it might not be so obvious. I am also fighting against clang in the Atlas port: different level of optimization produce different outputs or even may crash. But, what is nice with clang is that, when you find a bug, it is usually corrected within a day or two…

comment:3 Changed 8 years ago by dossy@…

@vince: Apple's pushing new Xcode releases within a day or two? Did I miss that memo on how to get these frequent updates to Xcode?

Fact is, clang isn't ready for mainstream use, yet. Please, stick with GCC until clang is production-ready for general use - or, at least give us MacPorts users an easy way to choose GCC vs. clang.

comment:4 Changed 8 years ago by dossy@…

I just found out that cairo won't build with clang either.

I guess I'll just have to remember to include "configure.compiler=gcc" on everything from now on. Is there a way to just stuff this in some dot-rc file so I don't have to remember to do this?

comment:5 Changed 8 years ago by raimue (Rainer Müller)

Please remember, if you have access to Xcode 4.2 previews you are most probably bound to a NDA.

Xcode 4.2 is an unreleased product and is not supported yet. The current 2.0.3 release uses clang if Xcode >= 4.2 is installed. If there is still a GCC version included in this new Xcode, you could change that in portconfigure.tcl.

comment:6 Changed 8 years ago by dossy@…

@raimue - yes, Xcode 4.2 still includes gcc 4.2.1.

I went ahead and replaced "clang" with "llvm-gcc-4.2" in portconfigure::configure_get_default_compiler. Wish there was a ~/.macportsrc or somesuch where I could set configure.compiler=gcc, though ...

comment:7 Changed 8 years ago by ryandesign (Ryan Schmidt)

We are not going to add an option for the user to specify which compiler to use because we do not support the user mucking with the compiler like that. It is up to the portfile author to choose which compiler(s) the port will use.

comment:8 Changed 8 years ago by Veence (Vincent)

Rainer, to whom where you speaking? An wen haben Sie sich gewendet?

There is no secret or NDA breaking under the fact that Apple pushes clang and will phase out GCC. Already, such breakthroughs like ARC will only be available using clang (and since this is included in clang SVN releases, it's public). It is evident that Apple has ceased all support of gcc to switch to LLVM, be it clang or dragonegg for other languages.

comment:9 Changed 7 years ago by ryandesign (Ryan Schmidt)

Cc: hpacheco@… added

Has duplicate #31905.

Sorry, I completely forgot this ticket. I guess I need to make gettext build with llvm-gcc-4.2 instead of clang.

comment:10 in reply to:  9 ; Changed 7 years ago by dossy@…

Replying to ryandesign@…:

Sorry, I completely forgot this ticket. I guess I need to make gettext build with llvm-gcc-4.2 instead of clang.

Yes, please, revert the change to MacPorts that uses clang at all, ever. It's still too buggy and just not ready for production use, yet.

comment:11 in reply to:  10 Changed 7 years ago by ryandesign (Ryan Schmidt)

Replying to dossy@…:

Yes, please, revert the change to MacPorts that uses clang at all, ever.

If you'd like to discuss that, you should send an email to the macports-dev group. This ticket is just about getting xgettext to work.

comment:12 Changed 7 years ago by ryandesign (Ryan Schmidt)

Resolution: wontfix
Status: newclosed
Summary: clang 3.0 bug compiles a flawed xgettext, complains of gettext:1:pass-c-formatgettext: pre-release Xcode 4.2's clang 3.0 compiles a flawed xgettext, complains of gettext:1:pass-c-format

The clang bug that caused this problem was allegedly fixed in May, and a brief survey of users of the final version of Xcode 4.2 turned up no users experiencing this problem. So I assume it was specific to the pre-release versions of Xcode 4.2 and has been fixed in the final release version. So I won't change the port just for that.

If you are experiencing the problem described in this ticket, install a final release version of Xcode and rebuild gettext with:

sudo port -n upgrade --force gettext

comment:13 Changed 7 years ago by dossy@…

The Xcode that I previously built with:

$ xcodebuild -version
Xcode 4.2
Build version 4D58

$ clang --version
Apple clang version 3.0 (tags/Apple/clang-209.9.2) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

Here is Xcode 4.2 installed fresh from the Mac App Store just now:

$ xcodebuild -version
Xcode 4.2
Build version 4D199

$ clang --version
Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

Here's rebuilding MacPorts gettext using clang:

$ sudo port selfupdate
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.0.3 installed,
MacPorts base version 2.0.3 downloaded.
--->  Updating the ports tree
--->  MacPorts base is already the latest version

The ports tree has been updated. To upgrade your installed ports, you should run
  port upgrade outdated

$ sudo port -n upgrade --force gettext
--->  Computing dependencies for gettext
--->  Cleaning gettext
--->  Unable to uninstall gettext @0.18.1.1_2+universal, the following ports depend on it:
...
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Deactivating gettext @0.18.1.1_2+universal
...
Warning: Deactivate forced.  Proceeding despite dependencies.
--->  Cleaning gettext
--->  Uninstalling gettext @0.18.1.1_2+universal
--->  Cleaning gettext
--->  Computing dependencies for gettext
--->  Fetching archive for gettext
--->  Attempting to fetch gettext-0.18.1.1_2+universal.darwin_11.i386-x86_64.tgz from http://packages.macports.org/gettext
--->  Fetching gettext
--->  Verifying checksum(s) for gettext
--->  Extracting gettext
--->  Applying patches to gettext
--->  Configuring gettext
--->  Building gettext
--->  Staging gettext into destroot
--->  Installing gettext @0.18.1.1_2+universal
--->  Activating gettext @0.18.1.1_2+universal
--->  Cleaning gettext

$ xgettext
xgettext: no input file given
Try `xgettext --help' for more information.

$ xgettext --version
xgettext (GNU gettext-tools) 0.18.1
Copyright (C) 1995-1998, 2000-2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Ulrich Drepper.

Looks like you're right, it's fixed in the Xcode 4.2 final. Thanks for the update.

comment:14 Changed 7 years ago by ryandesign (Ryan Schmidt)

Has duplicate #32254.

comment:15 Changed 7 years ago by ryandesign (Ryan Schmidt)

Has duplicate #34205.

comment:16 Changed 6 years ago by ryandesign (Ryan Schmidt)

Resolution: wontfix
Status: closedreopened

Has duplicate #37405.

comment:17 Changed 6 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: reopenedclosed

Fixed gettext to blacklist incompatible versions of clang in r100837.

Note: See TracTickets for help on using tickets.