On Mon, 23 Nov 2009, Przemysław Czerpak wrote:
> > 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).
>
> So I hope that in next releases llvm-gcc will be configured to work
> correctly with .a files created by llvm-ar. I still do not see any
> reasons to touch Harbour.
the end-user has to configure them to work together. i have to
configure to work them together.
this is how this goes:
you can have llvm-gcc emit elf objects, in which case the standard elf
binutils can work with whatever llvm-gcc emits. this is the case i
don't care about (and this is the case that probably can be pulled off
with just using HB_CCPREFIX).
you can have llvm-gcc emit llvm bitcode, in which case the object
format is not elf, but a blob that the rest of the *llvm* toolchain
can work with (and consequently any *elf* toolchain can not). this is
the case i've been massaging for the past couple of days.
> And we have HB_CCPREFIX because it's standard method of using different
> GCC based compilers in single system.
*if* they use a similarly working toolchain, yes. but you can't
separate the compiler from the toolchain anyhow, and the toolchain
here is different enough to warrant a distinct target.
> I.e. for Suse Linux we have over
> 30 different GCC based compilers which like LLVM can be used in such way
> and this list is systematically growing up.
> IMHO HB_CCPREFIX is very nice solution to not introduce explicit support
> for each of them into Harbour core code and then update them to keep such
> builds alive. Instead using HB_CCPREFIX user can easy compile Harbour using
> any GCC based compiler installed in his system when he need it. I still
> do not understand why you said:
> "HB_CCPREFIX seems absolutely not the way to go"
> For me it's prefect solution. Of course of some configuration switches are
> still missing to easy use different GCC based compilers using HB_CCPREFIX
> then we should add them.
again, if they use a similarly working toolchain. HB_CCPREFIX is
perfectly ok what it is used for, but this is not that case.
i am attaching a diff as to where i am at now. gcc.mk and llvmgcc.mk
are not *that* different (much more different than gcc.mk and
clang.mk, though), i'd be curious to see what additional knobs would
you add to the HB_CCPREFIX stuff to merge these two, without creating
spaghetti in gcc.mk.
ifeq ($(HB_CCPREFIX),llvm-)
CFLAGS := -emit-llvm
else
CFLAGS :=
endif
? this is just as explicit support as it is with a distinct target,
just worse, for it is "hidden" (inside another target, that is).
add to that that in this case we are not in
let-the-compiler-do-the-linking-land anymore, and it gets even more
complicated.
HB_CCPREFIX is not for this this case. (i most certainly didn't mean
HB_CCPREFIX to be a bad way *in general*, i only meant, and still mean
HB_CCPREFIX is a bad way *for llvm-gcc*.)
now, as for the diff.
i have removed leaking CFLAGS to the linker, and there is no ill
effect i see in my build tests (the two that used to fail before that
still fail, all the rest builds and install just as they used to).
i'm hazarding a guess that if (big if) it affects anything, that is
not the gnu toolchain, and it's apparently not watcom either. someone
should do tests with msvc and borland and the rest of the gang, but i
don't really think there will be any fallout.
the rest just adds an llvmgcc target, which, at this stage compiles
and installs mostly fine (both c and c++ modes). the only thing i'm
missing is the libharbour{,mt}.so -> libharbour{mt}-2.0.0.so symlinks
in the installed lib/ directory. what makes these?
also, viktor, could you please add this to hbmk2? probably not in the
tree first, but sending me (or the list) a diff to that end would be a
big step forward.
thanks,
--
[-]
mkdir /nonexistentIndex: config/linux/llvmgcc.mk
===================================================================
--- config/linux/llvmgcc.mk (revision 0)
+++ config/linux/llvmgcc.mk (revision 0)
@@ -0,0 +1,65 @@
+#
+# $Id: gcc.mk 12895 2009-11-16 08:52:59Z vszakats $
+#
+
+ifeq ($(HB_BUILD_MODE),cpp)
+ HB_CMP := llvm-g++
+else
+ HB_CMP := llvm-gcc
+endif
+
+OBJ_EXT := .o
+LIB_PREF := lib
+LIB_EXT := .a
+
+HB_DYN_COPT := -DHB_DYNLIB -fpic
+
+CC := $(HB_CCACHE) $(HB_CCPREFIX)$(HB_CMP)$(HB_CCPOSTFIX)
+CC_IN := -c
+CC_OUT := -o
+
+CPPFLAGS := -I. -I$(HB_INC_COMPILE)
+CFLAGS := -emit-llvm
+LDFLAGS := -native
+
+ifneq ($(HB_BUILD_WARN),no)
+ CFLAGS += -Wall -W
+endif
+
+ifneq ($(HB_BUILD_OPTIM),no)
+ CFLAGS += -O3
+endif
+
+ifeq ($(HB_BUILD_DEBUG),yes)
+ CFLAGS += -g
+endif
+
+ifneq ($(filter $(HB_BUILD_STRIP),all lib),)
+ ARSTRIP = && strip -S $(LIB_DIR)/$@
+endif
+ifneq ($(filter $(HB_BUILD_STRIP),all bin),)
+ LDSTRIP := -s
+ DYSTRIP := -s
+endif
+
+# LD := $(HB_CCACHE) $(HB_CCPREFIX)$(HB_CMP)$(HB_CCPOSTFIX)
+LD := llvm-ld
+LD_OUT := -o$(subst x,x, )
+
+LIBPATHS := $(foreach dir,$(LIB_DIR) $(SYSLIBPATHS),-L$(dir))
+LDLIBS := $(foreach lib,$(HB_USER_LIBS) $(LIBS) $(SYSLIBS),-l$(lib))
+
+LDFLAGS += $(LIBPATHS)
+
+AR := llvm-ar
+ARFLAGS :=
+AR_RULE = ( $(AR) $(ARFLAGS) $(HB_USER_AFLAGS) rcs $(LIB_DIR)/$@ $(^F) $(ARSTRIP) ) || ( $(RM) $(LIB_DIR)/$@ && false )
+
+DY := $(LD)
+DFLAGS := $(LDFLAGS) $(LIBPATHS)
+DY_OUT := -o$(subst x,x, )
+DLIBS := $(foreach lib,$(HB_USER_LIBS) $(SYSLIBS),-l$(lib))
+
+DY_RULE = $(DY) $(DFLAGS) $(HB_USER_DFLAGS) $(DY_OUT)$(DYN_DIR)/$@ $^ $(DLIBS) $(DYSTRIP) && $(LN) $(@F) $(DYN_FILE2)
+
+include $(TOP)$(ROOT)config/rules.mk
Index: config/rules.mk
===================================================================
--- config/rules.mk (revision 12990)
+++ config/rules.mk (working copy)
@@ -63,6 +63,7 @@
# The rule to link an executable.
ifeq ($(LD_RULE),)
+ ## LD_RULE = $(LD) $(CFLAGS) $(LDFLAGS) $(HB_LDFLAGS) $(HB_USER_LDFLAGS) $(LD_OUT)$(subst /,$(DIRSEP),$(BIN_DIR)/$@) $(^F) $(LDLIBS) $(LDSTRIP)
LD_RULE = $(LD) $(LDFLAGS) $(HB_LDFLAGS) $(HB_USER_LDFLAGS) $(LD_OUT)$(subst /,$(DIRSEP),$(BIN_DIR)/$@) $(^F) $(LDLIBS) $(LDSTRIP)
endif
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
