llvm-3.2 does not build / universal variants semantics should be changed

[Veence (Vincent)]

When building llvm-3.2 I get this error:

lvm[1]: Compiling llvm-config.cpp for Release+Debug+Asserts build
if  /usr/bin/clang++ -I/opt/local/var/macports/build/_Users_vincent_Developpement_Macports_trunk_dports_lang_llvm-3.2/llvm-3.2/work/llvm-3.2.src/include -I/opt/local/var/macports/build/_Users_vincent_Developpement_Macports_trunk_dports_lang_llvm-3.2/llvm-3.2/work/llvm-3.2.src/tools/llvm-config  -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/opt/local/var/macports/build/_Users_vincent_Developpement_Macports_trunk_dports_lang_llvm-3.2/llvm-3.2/work/llvm-3.2.src/tools/llvm-config/Release+Debug+Asserts -O3  -g -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual   -m64 -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings  -Wcovered-switch-default -c -MMD -MP -MF "/opt/local/var/macports/build/_Users_vincent_Developpement_Macports_trunk_dports_lang_llvm-3.2/llvm-3.2/work/llvm-3.2.src/tools/llvm-config/Release+Debug+Asserts/llvm-config.d.tmp" -MT "/opt/local/var/macports/build/_Users_vincent_Developpement_Macports_trunk_dports_lang_llvm-3.2/llvm-3.2/work/llvm-3.2.src/tools/llvm-config/Release+Debug+Asserts/llvm-config.o" -MT "/opt/local/var/macports/build/_Users_vincent_Developpement_Macports_trunk_dports_lang_llvm-3.2/llvm-3.2/work/llvm-3.2.src/tools/llvm-config/Release+Debug+Asserts/llvm-config.d" llvm-config.cpp -o /opt/local/var/macports/build/_Users_vincent_Developpement_Macports_trunk_dports_lang_llvm-3.2/llvm-3.2/work/llvm-3.2.src/tools/llvm-config/Release+Debug+Asserts/llvm-config.o ; \
	        then /bin/mv -f "/opt/local/var/macports/build/_Users_vincent_Developpement_Macports_trunk_dports_lang_llvm-3.2/llvm-3.2/work/llvm-3.2.src/tools/llvm-config/Release+Debug+Asserts/llvm-config.d.tmp" "/opt/local/var/macports/build/_Users_vincent_Developpement_Macports_trunk_dports_lang_llvm-3.2/llvm-3.2/work/llvm-3.2.src/tools/llvm-config/Release+Debug+Asserts/llvm-config.d"; else /bin/rm "/opt/local/var/macports/build/_Users_vincent_Developpement_Macports_trunk_dports_lang_llvm-3.2/llvm-3.2/work/llvm-3.2.src/tools/llvm-config/Release+Debug+Asserts/llvm-config.d.tmp"; exit 1; fi
llvm-config.cpp:45:10: fatal error: 'LibraryDependencies.inc' file not found
#include "LibraryDependencies.inc"
         ^
1 error generated.
rm: /opt/local/var/macports/build/_Users_vincent_Developpement_Macports_trunk_dports_lang_llvm-3.2/llvm-3.2/work/llvm-3.2.src/tools/llvm-config/Release+Debug+Asserts/llvm-config.d.tmp: No such file or directory

Besides, the ‘universal’ variant should not mean building a universal compiler, but building a compiler than can compile for both i386/x86-64, which is the default case. The classical meaning of ‘universal’ should be transferred to some other variant.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to vince@…:

When building llvm-3.2 I get this error:

Attach main.log

Besides, the ‘universal’ variant should not mean building a universal compiler, but building a compiler than can compile for both i386/x86-64, which is the default case. The classical meaning of ‘universal’ should be transferred to some other variant.

No. +universal means that the built binaries will run on either machine. This is true for *all* ports. Making it have a different meaning (ie CTARGET rather than CHOST) for toolchain ports is nonsensical. Furthermore, there is no reason to care about CTARGET for llvm because it is not as restricted as gcc and can support multiple targets with the same build.

[Veence (Vincent)]

Replying to jeremyhu@…:

No. +universal means that the built binaries will run on either machine. This is true for *all* ports. Making it have a different meaning (ie CTARGET rather than CHOST) for toolchain ports is nonsensical. Furthermore, there is no reason to care about CTARGET for llvm because it is not as restricted as gcc and can support multiple targets with the same build.

Have a look at gccXX ports:

-> port installed gcc47
The following ports are currently installed:
  gcc47 @4.7.2_2+universal (active)
-> file /opt/local/bin/gcc-mp-4.7 
/opt/local/bin/gcc-mp-4.7: Mach-O 64-bit executable x86_64

The universal flag in this case enables the multilib option, which means: "please generate a compiler that can be used for both x86-64 and i386 code generation" ; there is no way to generate a ‘universal binary‘ gcc. I don’t see why llvm/clang would not adhere to the same convention, which seems reasonable to me: consider a port like atlas which depends on gcc47 for its +gcc47 variant. If I build a universal atlas, I don’t care about gcc being a universal binary: what I desire is a gcc that can compile atlas for both x86 and i386 (or ppc and ppc64); that’s exactly what the universal variant of gcc offers me.

Now if I build clang/llvm without the universal variant, I also get a compiler able to generate code for both x86/i386, that’s what I want. But if I now desire to build atlas with the universal variant, macports will rebuild clang with the +universal option, which is at minimum a waste of resources…

[Veence (Vincent)]

Logfile (gzipped)

[jmroot (Joshua Root)]

You probably want depends_skip_archcheck clang-3.1 in atlas. Having +universal control multilib in gcc really is weird, and only came about because it allowed universal dependents to build without getting stuck on arch checking, and because actual universal builds of the gcc ports don't work. They should probably just enable multilib all the time and disable the universal variant (if it can't be made to work properly).

[Veence (Vincent)]

I agree it can seem weird, but MacPorts dependencies primarily target library linking, while depending on a compiler never assumes this meaning: no port links against compiler libs beyond STL, libfortran or other vital libs that are precisely affected by the --multilib flag.

For instance, does I really need a universal llvm-3.2 to build a universal cctools ? No. So why should Macports force me to build a universal llvm-3.2 to get a universal cctools?

[jeremyhu (Jeremy Huddleston Sequoia)]

+universal affects CHOST. The fact that gccXX uses it to affect CTARGET is a bug in the gcc ports.

cctools links against llvm-3.2, so if you want a +universal cctools, you certainly need a +universal llvm-3.2

[jeremyhu (Jeremy Huddleston Sequoia)]

Your build failure is because you're using python3.

#32575

[Veence (Vincent)]

Replying to jeremyhu@…:

+universal affects CHOST. The fact that gccXX uses it to affect CTARGET is a bug in the gcc ports.

Well, let’s not quibble. It may be a bug, but I find it useful – I consider it a positive mutation. :) Is the failure of llvm-3.2 with python3 caused by some python script not being upgraded? In which case a simple 2to3 pass might be enough to fix this issue?

[deesto (John S. De Stefano Jr.)]

Cc Me!

[larryv (Lawrence Velázquez)]

Cc Me!