On Mon, 23 Nov 2009, Tamas TEVESZ wrote: Hi,
> > You have quite precise error message here. > > I've just checked that also in Suse11.2 llvm-ranlib does not create index > > which can be recognized by llvm-gcc. It's probably bug which should be > > reported to LLVM developers. > > As workaround I used ranlib instead of llvm-ranlib to create indexes and > > created full harbour build using HB_CCPREFIX=llvm- without any problems. > that is exactly what's happening, and according to llvm bugzilla, this > is what should be happening, see: > http://www.mail-archive.com/llvmb...@cs.uiuc.edu/msg03238.html Please note that we are calling llvm-gcc to link final application and it does not work. I haven't check if it does not call llvm-ld but native ld or llvm-ld does not work correctly. It doesn't matter for us. Important is only that calling llvm-gcc to create binaries does not work with libraries created by llvm-ar what is a problem which should be resolved by packager or llvm authors. It's not out job to add workarounds for such things into core harbour code. > so it may be that the solution is not HB_CCPREFIX after all, but a > separate llvmgcc target, which, for starters, only sets HB_CMP. I still to think that it's good idea to encode workarounds for problems with other packages into harbour core code. IMHO much simpler temporary solution is: ln -sf /usr/bin/ar /usr/bin/llvm/ar from root account until someone will have not create llvm-gcc packages with llvm-gcc which can work with llvm-ar correctly. > it seems that the supposed improvements using llvm start pouring when > it's also used for linking, see for example: > http://www.nntp.perl.org/group/perl.perl5.porters/2008/06/msg137461.html > this could be added as a next step, once an llvmgcc target is in > there. It will not give any real improvement to Harbour HVM because we already enabled inter procedural optimization in whole HVM code by introducing hvmall.c so it works for compiler which do not have link time IPO. Few months ago I tested using ICC that it gives in practice the same improvement and introducing link time IPO does give farther speed optimizations but strongly increase the size of final binaries. So if LLVM/GCC does not disable some compile time IPO which exist in GCC then at current state there is not chance that using LLVM or CLANG we will have faster final code because we do not leave any time critical code which can be improved yet by link time IPO. > HB_CCPREFIX seems absolutely not the way to go. Can you explain the above. I do not understand it. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
