On Mon, 23 Nov 2009, Przemysław Czerpak wrote: > > 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.
they work together correctly, if they are configured to work together correctly. my first stab, they were not. i'm much further now, and almost have a complete compilation+link cycle without workarounds like above (as i slowly start to understand how llvm + frontends work). > > 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. i wholeheartedly believe you, but i still do not see this as a futile excercise. if nothing else, *i* will learn something new. > > HB_CCPREFIX seems absolutely not the way to go. > > Can you explain the above. I do not understand it. i do not really understand what is it you do not understand. HB_CCPREFIX is just that, prepending some prefix to the compiler and binutils and stuff names. in this llvmgcc case, modifying several compiler options is also needed, so setting only prefix is not enough. -- [-] mkdir /nonexistent _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
