I'm trying to write an gentoo ebuild for the c frontend. When make runs
libstdc++/configure I get some problems:
configure tries to determine the object extensionbut fails. This is the
output:
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... checking for perl... perl
checking build system type... i686-pc-linux-gnu
checking host system type... /bin/install -c
checking whether build environment is sane... i686-pc-linux-gnu
checking for i686-pc-linux-gnu-ar... i686-pc-linux-gnu-ar
checking for i686-pc-linux-gnu-ranlib... i686-pc-linux-gnu-ranlib
checking for
i686-pc-linux-gnu-gcc... /var/tmp/portage/llvm-gcc-1.5/work/cfrontend/build/gcc/xgcc
-B/var/tmp/portage/llvm-gcc-1.5/work/cfrontend/build/gcc/
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/
-isystem /usr/i686-pc-linux-gnu/include
-isystem /usr/i686-pc-linux-gnu/sys-include
checking for suffix of object files... configure: error: cannot compute suffix
of object files: cannot compile
See `config.log' for more details.
make: *** [configure-target-libiberty] Fehler 1
make: *** Warte auf noch nicht beendete Prozesse...
The config.log does not help. I think there might be some problem with the
xgcc... Do you have an idea what could be wrong?
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
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.
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?
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
Ok, great!
What are the differences between the cfrontends.tar.gz and the corresponding
gcc release?
It's a pretty big diff. All of the code for translating to llvm form, plus minor patches here and there to cause GCC to produce more type-safe LLVM code (e.g. not lowering address arithmetic etc). Total it's probably about 15K LOC.
What would have to be done to get a new version of gcc working as frontend?
It's a pretty significant job. You could try to merging in new bits from GCC mainline, but it's a nasty job: debugging failures requires pretty strong understanding of how GCC works. Easier would be to patch the llvm-gcc X86 configuration stuff to accept and ignore that switch.
If it's any consolation, it seems fairly likely that there will be a new llvm-gcc in development in the next couple of months, based on GCC mainline.
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
Good. Glad you found it.
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?
There are several new files in the gcc directory, all beginning with llvm. Most of the rest of GCC is untouched, but there are some differences. Chris Lattner is the author of this code so you'd need to get his attention for details. One thing you could do is compare the current HEAD revision in CVS with and older revision that contained just the GCC sources. Upgrading in the 3.X line shouldn't be too difficult. I imagine upgrading to the 4.X GCC releases would be a major project (much changed in GCC).
It's a pretty significant job. You could try to merging in new bits from
GCC mainline, but it's a nasty job: debugging failures requires pretty
strong understanding of how GCC works. Easier would be to patch the
llvm-gcc X86 configuration stuff to accept and ignore that switch.
I looked at those files. Where did you integrate LLVM into GCC? Did you change
the gimplifier to produce LLVM code or make LLVM a GCC backend?
If it's any consolation, it seems fairly likely that there will be a new
llvm-gcc in development in the next couple of months, based on GCC
mainline.
