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

[dossy@…]

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 ... :-(

[dossy@…]

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

[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…

[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.

[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?

[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​.

[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 ...

[ryandesign (Ryan Carsten 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.

[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.

[ryandesign (Ryan Carsten Schmidt)]

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.

[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.

[ryandesign (Ryan Carsten 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.

[ryandesign (Ryan Carsten Schmidt)]

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

[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.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #32254.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #34205.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #37405.

[ryandesign (Ryan Carsten Schmidt)]

Fixed gettext to blacklist incompatible versions of clang in r100837.