llvm dev - Aug 2005 - [LLVMdev] cfrontend building

Am Montag, 8. August 2005 18:12 schrieb Reid Spencer:
> Stephan,
>
> I've seen this before. It happens when you do "make
bootstrap" in llvm-gcc.
> While "make bootstrap" is the correct way to build GCC, its not
the correct
> way to build llvm-gcc.
>
> Based on my experience with this, I suggest you completely erase your build
> tree and then follow the CFEBuildInstr.html instructions *to the letter*
> with zero deviations.
>
> If you didn't do "make bootstrap", then I don't have a
clue what this
> problem is :)
>
> Reid.
>
Hallo,

do you know if bootstrap is the default target?

This is what I'm doing:
<code>
inherit eutils

DESCRIPTION="C, C++ Frontend for Low Level Virtual _Machine"
HOMEPAGE="http://llvm.org/"
SRC_URI="http://llvm.cs.uiuc.edu/releases/${PV}/cfrontend-${PV}.source.tar.gz"

LICENSE="llvm"
SLOT="0"
KEYWORDS="~ppc ~sparc ~x86"
IUSE=""

DEPEND
S=${WORKDIR}/cfrontend

src_unpack() {
    unpack ${A}
    cd cfrontend
    mkdir build
}

src_compile() {
	cd ${S}/build
	../src/configure --prefix=/usr --disable-threads --disable-nls 
--disable-shared --enable-languages=c,c++ --program-prefix=llvm-
        emake || die
}

src_install() {
        emake DESTDIR=${D} install || die
}
</code>

maybe I should try emake all instead of emake... I'll try.

Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050808/b637af97/attachment.sig>

Answers inline ..

Stephan Wienczny wrote:
> 
> Hallo,
> 
> do you know if bootstrap is the default target?
No, "all" is the default.
> 
> This is what I'm doing:
> <code>
> inherit eutils
> 
> DESCRIPTION="C, C++ Frontend for Low Level Virtual _Machine"
> HOMEPAGE="http://llvm.org/"
>
SRC_URI="http://llvm.cs.uiuc.edu/releases/${PV}/cfrontend-${PV}.source.tar.gz"
> 
> LICENSE="llvm"
> SLOT="0"
> KEYWORDS="~ppc ~sparc ~x86"
> IUSE=""
> 
> DEPEND> 
> S=${WORKDIR}/cfrontend
> 
> src_unpack() {
>     unpack ${A}
>     cd cfrontend
>     mkdir build
I wouldn't put the "build" directory inside of the
"cfrontend" directory, put
it alongside instead. That is, reverse the order of the cd and mkdir commands 
above.
> }
> 
> src_compile() {
> 	cd ${S}/build
If you change the location of the build directory, this will need to change
too.
> 	../src/configure --prefix=/usr --disable-threads --disable-nls 
> --disable-shared --enable-languages=c,c++ --program-prefix=llvm-
>         emake || die
Is emake 100% compatible with GNU Make 3.79 or later?
> }
> 
> src_install() {
>         emake DESTDIR=${D} install || die
> }
> </code>
> 
> maybe I should try emake all instead of emake... I'll try.
"emake all" would certainly be more strongly directive but
shouldn't be
necessary. These steps look okay to me.
> 
> Stephan
Try it with the build directory not inside the cfrontend directory, that will 
probably solve things for you.

Reid

Am Montag, 8. August 2005 20:04 schrieb Reid Spencer:
> Answers inline ..
>
>
> Is emake 100% compatible with GNU Make 3.79 or later?
>
emake is a python function that calls make internally.
>
> Try it with the build directory not inside the cfrontend directory, that
> will probably solve things for you.
>
> Reid
Hallo,

I found the problem. The gcc sources are older than those on my system. I've
got some CFLAGS that the old gcc does not know, eg. -march=pentium-m. Are 
these flags filtered out everything works fine ;-)

What are the differences between the cfrontends.tar.gz and the corresponding 
gcc release? What would have to be done to get a new version of gcc working 
as frontend?

Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050809/5c18da26/attachment.sig>