> The situation is very simple. llvm-ar cannot work correctly with > llvm-gc and it's a bug in this tools. It doesn't matter what type > of object is generated. I.e. in ICC where 'xiar' is used instead > of 'ar' we can use archives which contains meta code for link time > IPO without any problems. In LLVM not and without any doubts it's > sth what should be fixed by LLVM compiler authors or packagers who > create binary packages for given distribution. That's all. [...] > BTW new version of GCC will also support IPO when -O4 optimization is > used and LLVM-GCC already accepts this switch which can be used to force > generating byte code instead of machine code in .o files. Anyhow it also > does not help to resolve the link time problem and even with -O4 and .o > files containing byte code still native 'ld' is used instead of llvm-ld :-(
Thanks a lot. So, shortly the problem is that 'llvm-gcc' wrongly calls 'ld', instead of its own 'llvm-ld'. It would certainly be better if llvm-gcc could automatically (or via cmdline options?) call the correct ld tool. I made a test on the Windows llvm-gcc build, and there apparently a similar problem exist where llvm-gcc.exe tries to execute as.exe (which is not supplied) instead of llvm-as.exe (which is). This means I have to add MinGW bin dir to PATH in order to make llvm-gcc.exe work. If I rename supplied llvm-as.exe to as.exe, it chokes on incompatible cmdline handling, telling: "as: Unknown command line argument '-ohbver.o'. Try: 'as --help'" The linking problem is apparently the same as on Linux. ld.exe will be called instead of llvm-gc.exe, with same error. It's a little strange such problems are still in this software, or could be that we (I) miss the concept. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
