Opened 10 years ago

Closed 8 years ago

#42899 closed defect (fixed)

llvm-gcc42 fails to install after installing Xcode 5.1

Reported by: tcollett+macports@… Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version: 2.2.1
Keywords: Cc: erickt@…, hapaguy (Brian Kurt Fujikawa), sk-public@…, ryandesign (Ryan Carsten Schmidt), thorbenj-macports@…, larryv (Lawrence Velázquez)
Port: llvm-gcc42

Description

When attempting to install the llvm-gcc42 port (upon which various others depend) after installing Xcode 5.1 and the corresponding version of clang ("Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)"), it fails with the following error:

/usr/bin/clang++ -pipe -stdlib=libstdc++ -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/work/objroot/obj-llvmCore/obj-llvm/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/work/objroot/obj-llvmCore/obj-llvm/lib/Transforms/Hello -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/work/objroot/obj-llvmCore/src/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/work/objroot/obj-llvmCore/src/lib/Transforms/Hello  -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2  -g -fno-exceptions -fno-common -Woverloaded-virtual -DLLVM_VERSION_INFO='" Apple Build #2336-11"'  -mmacosx-version-min=10.9  -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings  -arch i386 -arch x86_64 -O2 -g -module -Wl,-rpath -Wl,/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/work/objroot/obj-llvmCore/obj-llvm/Release+Debug-Asserts/lib -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/work/objroot/obj-llvmCore/obj-llvm/Release+Debug-Asserts/lib -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/work/objroot/obj-llvmCore/obj-llvm/Release+Debug-Asserts/lib  -Wl,-flat_namespace -Wl,-undefined -Wl,suppress -dynamiclib -mmacosx-version-min=10.9 -o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/work/objroot/obj-llvmCore/obj-llvm/Release+Debug-Asserts/lib/LLVMHello.dylib /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/work/objroot/obj-llvmCore/obj-llvm/lib/Transforms/Hello/Release+Debug-Asserts/Hello.o \
	    -lpthread -lm 
In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/work/objroot/obj-llvmCore/src/lib/Transforms/InstCombine/InstCombineSelect.cpp:14:
In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/work/objroot/obj-llvmCore/src/lib/Transforms/InstCombine/InstCombine.h:13:
In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/work/objroot/obj-llvmCore/src/lib/Transforms/InstCombine/InstCombineWorklist.h:18:
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/work/objroot/obj-llvmCore/src/include/llvm/ADT/DenseMap.h:387:18: warning: explicitly assigning a variable of type 'bool' to itself [-Wself-assign]
        FoundVal = FoundVal; // silence warning.
        ~~~~~~~~ ^ ~~~~~~~~
clang: error: unknown argument: '-module' [-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning) in the future
make[5]: *** [/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-gcc42/llvm-gcc42/work/objroot/obj-llvmCore/obj-llvm/Release+Debug-Asserts/lib/LLVMHello.dylib] Error 1

Change History (18)

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

Cc: erickt@… added
Owner: changed from macports-tickets@… to jeremyhu@…

In the future, please Cc the port maintainers (port info --maintainers llvm-gcc42).

comment:2 Changed 10 years ago by hapaguy (Brian Kurt Fujikawa)

Cc: brian.fujikawa@… added

Cc Me!

comment:3 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

meh.

should just add -Wno-unused-command-line-argument-hard-error-in-future to configure.cflags.

comment:4 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

IMO, the real bug is with whatever is still trying to use this ancient relic. There's no good reason that we should still have to keep llvm-gcc on life support like this.

comment:5 Changed 10 years ago by sk-public@…

Cc: sk-public@… added

Cc Me!

comment:6 in reply to:  4 ; Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added

Replying to jeremyhu@…:

IMO, the real bug is with whatever is still trying to use this ancient relic. There's no good reason that we should still have to keep llvm-gcc on life support like this.

There absolutely is. Some ports blacklist clang, and llvm-gcc is the next best fallback MacPorts tries. Unless you would prefer that we remove that fallback and fallback to apple-gcc-4.2 instead? Yes, ideally ports would be fixed to compile with clang, but not everyone is proficient enough in C/C++ to accomplish that immediately, and often blacklisting clang is the simplest way to get a port to build immediately.

comment:7 Changed 10 years ago by thorbenj-macports@…

Adding "-Wunused-command-line-argument-hard-error-in-future" doesn't work:

:info:build clang: error: unknown argument: '-module' [-Wunused-command-line-argument-hard-error-in-future]
:info:build clang: note: this will be a hard error (cannot be downgraded to a warning) in the future

OR, maybe port invocation is to blame:

# port install llvm-gcc42 configure.cflags-append "-Wno-unused-command-line-argument-hard-error-in-future"

Which is what I understood from: https://guide.macports.org/chunked/reference.phases.html#reference.phases.installation

comment:8 Changed 10 years ago by thorbenj-macports@…

Cc: thorbenj-macports@… added

Cc Me!

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

Replying to thorbenj-macports@…:

OR, maybe port invocation is to blame:

# port install llvm-gcc42 configure.cflags-append "-Wno-unused-command-line-argument-hard-error-in-future"

Which is what I understood from: https://guide.macports.org/chunked/reference.phases.html#reference.phases.installation

If that's the command you ran, certainly you should not do that. Just run "sudo port install llvm-gcc42". Overriding portfile variables at the command line is not supported.

comment:10 in reply to:  6 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Replying to ryandesign@…:

Replying to jeremyhu@…:

IMO, the real bug is with whatever is still trying to use this ancient relic. There's no good reason that we should still have to keep llvm-gcc on life support like this.

There absolutely is. Some ports blacklist clang, and llvm-gcc is the next best fallback MacPorts tries.

Yes. That's my point. Some ports blacklist clang. Those ports really need to be fixed to build with clang.

Unless you would prefer that we remove that fallback and fallback to apple-gcc-4.2 instead?

No. I would prefer it if ports were updated to not depend on a 7 year old compiler.

Yes, ideally ports would be fixed to compile with clang, but not everyone is proficient enough in C/C++ to accomplish that immediately, and often blacklisting clang is the simplest way to get a port to build immediately.

Yes, but that is not a long-term solution. Such ports have been that way for 3+ years now. They need to be fixed.

Yes, we should fix llvm-gcc's build, but we also should really fix the dependent ports to not use llvm-gcc.

Last edited 9 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:11 Changed 10 years ago by thorbenj-macports@…

Obviously I did originally run "# port install llvm-gcc42"* or I would not have ended up on this bug report.

(* To be clear, I tried to port install something else first (from KDE4), and that depended on llvm-gcc42)

I'd like to point out that comment:3 and comment:9 contradict each other. If it weren't for comment:3 I would not have tried to override CFLAGS as a possible solution to this bug.

Last edited 10 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

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

comment:3 doesn't say who should add that or where...

comment:13 Changed 10 years ago by tcollett+macports@…

It seems to me that whatever the best long-term solution might be, as long as llvm-gcc42 is an active port, it should build cleanly on supported systems.

comment:14 in reply to:  13 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Replying to tcollett+macports@…:

It seems to me that whatever the best long-term solution might be, as long as llvm-gcc42 is an active port, it should build cleanly on supported systems.

Nobody is disagreeing with you. It does cleanly build on supported systems. Apple dropped support for llvm-gcc42 quite some time ago. I've continued to make changes to the llvm-gcc42 port to make it usable on newer (and older) systems, but the fact is that the compiler is 7 years old, is not C++11 compatible, and has other major drawbacks.

There are a ton of ports that simply don't work on Mavericks because they contain C++ code and blacklist clang.

The fact is that "supported" systems for llvm-gcc-4.2 may mean "not the latest systems" at some point very soon. There are plenty of ports that don't build with current tools; llvm-gcc is one of them. When I get some cycles, I'll try to put together a fix to get it building again with recent tools, but port maintainers need to face the fact that they should not be relying on a 7 year old compiler that is clearly no longer supported.

comment:15 in reply to:  9 Changed 10 years ago by jmroot (Joshua Root)

Replying to ryandesign@…:

Replying to thorbenj-macports@…:

OR, maybe port invocation is to blame:

# port install llvm-gcc42 configure.cflags-append "-Wno-unused-command-line-argument-hard-error-in-future"

Which is what I understood from: https://guide.macports.org/chunked/reference.phases.html#reference.phases.installation

If that's the command you ran, certainly you should not do that. Just run "sudo port install llvm-gcc42". Overriding portfile variables at the command line is not supported.

More to the point, configure.cflags-append is not a variable. Also, saying to “just" install the port normally kind of misses the point; the idea was to check if disabling that warning made the build not fail.

comment:16 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

r118148 should address the issue for now, but I'm keeping this open to address it with a proper fix later.

comment:17 Changed 9 years ago by larryv (Lawrence Velázquez)

Cc: larryv@… added

Cc Me!

comment:18 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: newclosed

Moving to closed.

Note: See TracTickets for help on using tickets.