I've been trying to package DragonEgg for Fedora Linux. Fedora 16 has
LLVM 2.9 and GCC 4.6, but not the necessary GCC patches. If I build
LLVM 3.0 on Fedora 16, then I can build DragonEgg 3.0, and it works
fine. However, I can't submit that to the repository.
On the other hand, Fedora 17, which just entered Beta, has LLVM 3.0 and
GCC 4.7. I wasn't able to build DragonEgg 3.0 with GCC 4.7 due to an
error compiling Backend.cpp, but yesterday I saw that commit #152558
fixes this. However, now when I try to build DragonEgg, I get a lot of
other errors.
On the one hand, I don't expect there to be any official support for
DragonEgg 3.0 with GCC 4.7. On the other hand, it would be nice to get
DragonEgg into Fedora 17 rather than having to wait another six months
for LLVM 3.1 to land in Fedora 18. Would anyone care to look at the
build problems I'm seeing? Perhaps these problems were already fixed in
other commits in the repository.
Some of the errors I'm getting are:
/builddir/build/BUILD/dragonegg-3.0.src/src/Trees.cpp: In function 'uint64_t
getFieldOffsetInBits(tree)':
/builddir/build/BUILD/dragonegg-3.0.src/src/Trees.cpp:191:56: error:
'BITS_PER_UNIT' was not declared in this scope
/builddir/build/BUILD/dragonegg-3.0.src/src/DefaultABI.cpp: In member function
'void DefaultABI::HandleArgument(tree, std::vector<llvm::Type*,
std::allocator<llvm::Type*> >&, llvm::Attributes*)':
/builddir/build/BUILD/dragonegg-3.0.src/src/DefaultABI.cpp:223:14: error:
'TARGET_64BIT' was not declared in this scope
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/plugin/include/tm_p.h:5:0,
from
/builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp:52:
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/plugin/include/tm-preds.h:191:13: error:
use of enum 'reg_class' without previous declaration
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/plugin/include/tm-preds.h:191:68: error:
invalid type in declaration before ';' token
/builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp: In member function
'{anonymous}::BitSlice {anonymous}::BitSlice::ExtendRange(SignedRange,
llvm::TargetFolder&) const':
/builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp:188:7: error:
'BYTES_BIG_ENDIAN' was not declared in this scope
/builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp: In member function
'{anonymous}::BitSlice {anonymous}::BitSlice::ReduceRange(SignedRange,
llvm::TargetFolder&) const':
The full build log is at:
http://koji.fedoraproject.org/koji/getfile?taskID=3925063&name=build.log
Once i can get DragonEgg into Fedora, I'm hoping to convince the package
maintainers for GCC in Red Hat Enterprise Linux 6 to include the patch
to GCC 4.4 necessary to build DragonEgg 2.8, since I expect it will be a
long time (years!) before LLVM 3.x shows up in RHEL7.
Thanks!
Eric
On Fri, Mar 23, 2012 at 04:57:55PM -0700, Eric Smith wrote:> I've been trying to package DragonEgg for Fedora Linux. Fedora 16 has > LLVM 2.9 and GCC 4.6, but not the necessary GCC patches. If I build > LLVM 3.0 on Fedora 16, then I can build DragonEgg 3.0, and it works > fine. However, I can't submit that to the repository. > > On the other hand, Fedora 17, which just entered Beta, has LLVM 3.0 and > GCC 4.7. I wasn't able to build DragonEgg 3.0 with GCC 4.7 due to an > error compiling Backend.cpp, but yesterday I saw that commit #152558 > fixes this. However, now when I try to build DragonEgg, I get a lot of > other errors. > > On the one hand, I don't expect there to be any official support for > DragonEgg 3.0 with GCC 4.7. On the other hand, it would be nice to get > DragonEgg into Fedora 17 rather than having to wait another six months > for LLVM 3.1 to land in Fedora 18. Would anyone care to look at the > build problems I'm seeing? Perhaps these problems were already fixed in > other commits in the repository.At r153413, the dragonegg compilation errors against gcc-4.7.0 using clang is... Compiling Constants.cpp /sw/src/fink.build/dragonegg-gcc47-3.1-0/dragonegg-3.1/src/Backend.cpp:1594:24: error: no member named 'same_body' in 'cgraph_node' for (alias = node->same_body; alias && alias->next; alias = alias->next) ; ~~~~ ^ 1 error generated. and using gcc-4.7.0 itself... Compiling Constants.cpp /sw/src/fink.build/dragonegg-gcc47-3.1-0/dragonegg-3.1/src/Backend.cpp: In function 'void emit_aliases(cgraph_node_set, varpool_node_set)': /sw/src/fink.build/dragonegg-gcc47-3.1-0/dragonegg-3.1/src/Backend.cpp:1594:24: error: 'struct cgraph_node' has no member named 'same_body' make: *** [Backend.o] Error 1 Hopefully this is the last compilation error blocking dragonegg on gcc 4.7.0. Jack ps This was from testing on x86_64-apple-darwin11.> > Some of the errors I'm getting are: > > /builddir/build/BUILD/dragonegg-3.0.src/src/Trees.cpp: In function 'uint64_t getFieldOffsetInBits(tree)': > /builddir/build/BUILD/dragonegg-3.0.src/src/Trees.cpp:191:56: error: 'BITS_PER_UNIT' was not declared in this scope > > /builddir/build/BUILD/dragonegg-3.0.src/src/DefaultABI.cpp: In member function 'void DefaultABI::HandleArgument(tree, std::vector<llvm::Type*, std::allocator<llvm::Type*> >&, llvm::Attributes*)': > /builddir/build/BUILD/dragonegg-3.0.src/src/DefaultABI.cpp:223:14: error: 'TARGET_64BIT' was not declared in this scope > In file included from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/plugin/include/tm_p.h:5:0, > from /builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp:52: > /usr/lib/gcc/x86_64-redhat-linux/4.7.0/plugin/include/tm-preds.h:191:13: error: use of enum 'reg_class' without previous declaration > /usr/lib/gcc/x86_64-redhat-linux/4.7.0/plugin/include/tm-preds.h:191:68: error: invalid type in declaration before ';' token > /builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp: In member function '{anonymous}::BitSlice {anonymous}::BitSlice::ExtendRange(SignedRange, llvm::TargetFolder&) const': > /builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp:188:7: error: 'BYTES_BIG_ENDIAN' was not declared in this scope > /builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp: In member function '{anonymous}::BitSlice {anonymous}::BitSlice::ReduceRange(SignedRange, llvm::TargetFolder&) const': > > > The full build log is at: > > http://koji.fedoraproject.org/koji/getfile?taskID=3925063&name=build.log > > Once i can get DragonEgg into Fedora, I'm hoping to convince the package > maintainers for GCC in Red Hat Enterprise Linux 6 to include the patch > to GCC 4.4 necessary to build DragonEgg 2.8, since I expect it will be a > long time (years!) before LLVM 3.x shows up in RHEL7. > > Thanks! > Eric > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi Eric,> I've been trying to package DragonEgg for Fedora Linux. Fedora 16 has > LLVM 2.9 and GCC 4.6, but not the necessary GCC patches. If I build > LLVM 3.0 on Fedora 16, then I can build DragonEgg 3.0, and it works > fine. However, I can't submit that to the repository. > > On the other hand, Fedora 17, which just entered Beta, has LLVM 3.0 and > GCC 4.7. I wasn't able to build DragonEgg 3.0 with GCC 4.7 due to an > error compiling Backend.cpp, but yesterday I saw that commit #152558 > fixes this.it was a warning not an error, but perhaps you build with -Werror? However, now when I try to build DragonEgg, I get a lot of> other errors.I've started porting dragonegg to gcc-4.7 (I fixed a few things this weekend already). The same-body alias implementation changed substantially it seems, and I also see a lot of compile failures in Convert.cpp related to synchronization primitives, probably coming from the GCC changes made to support C++-11 atomics. These two will require time, thought and care to update right. ABIHack.inc is also failing to compile, but this looks to be a mild problem. That said, getting it compiling is not the same as having it work well, or even work at all. For example, if gcc-4.7 is bootstrapped then it compiles itself using the first-stage C++ compiler which means that all names are mangled, while if gcc-4.7 is not bootstrapped then names are not mangled because it is compiled as C. Currently dragonegg expects names to not be mangled, but it will somehow have to detect gcc's with mangled names otherwise it will fail miserably. Ciao, Duncan.> On the one hand, I don't expect there to be any official support for > DragonEgg 3.0 with GCC 4.7. On the other hand, it would be nice to get > DragonEgg into Fedora 17 rather than having to wait another six months > for LLVM 3.1 to land in Fedora 18. Would anyone care to look at the > build problems I'm seeing? Perhaps these problems were already fixed in > other commits in the repository. > > Some of the errors I'm getting are: > > /builddir/build/BUILD/dragonegg-3.0.src/src/Trees.cpp: In function 'uint64_t getFieldOffsetInBits(tree)': > /builddir/build/BUILD/dragonegg-3.0.src/src/Trees.cpp:191:56: error: 'BITS_PER_UNIT' was not declared in this scope > > /builddir/build/BUILD/dragonegg-3.0.src/src/DefaultABI.cpp: In member function 'void DefaultABI::HandleArgument(tree, std::vector<llvm::Type*, std::allocator<llvm::Type*> >&, llvm::Attributes*)': > /builddir/build/BUILD/dragonegg-3.0.src/src/DefaultABI.cpp:223:14: error: 'TARGET_64BIT' was not declared in this scope > In file included from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/plugin/include/tm_p.h:5:0, > from /builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp:52: > /usr/lib/gcc/x86_64-redhat-linux/4.7.0/plugin/include/tm-preds.h:191:13: error: use of enum 'reg_class' without previous declaration > /usr/lib/gcc/x86_64-redhat-linux/4.7.0/plugin/include/tm-preds.h:191:68: error: invalid type in declaration before ';' token > /builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp: In member function '{anonymous}::BitSlice {anonymous}::BitSlice::ExtendRange(SignedRange, llvm::TargetFolder&) const': > /builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp:188:7: error: 'BYTES_BIG_ENDIAN' was not declared in this scope > /builddir/build/BUILD/dragonegg-3.0.src/src/Constants.cpp: In member function '{anonymous}::BitSlice {anonymous}::BitSlice::ReduceRange(SignedRange, llvm::TargetFolder&) const': > > > The full build log is at: > > http://koji.fedoraproject.org/koji/getfile?taskID=3925063&name=build.log > > Once i can get DragonEgg into Fedora, I'm hoping to convince the package > maintainers for GCC in Red Hat Enterprise Linux 6 to include the patch > to GCC 4.4 necessary to build DragonEgg 2.8, since I expect it will be a > long time (years!) before LLVM 3.x shows up in RHEL7. > > Thanks! > Eric > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Duncan Sands wrote: > That said, getting it compiling is not the same as having it work well, or even work at all. OK, it sounds like I'd best just wait for you to finish getting it working with GCC 4.7. If that makes it into 3.1, then I might be able to get a DragonEgg 3.1 package into Fedora 18, toward the end of this year. Assuming that Fedora hasn't already moved to GCC 4.8 by then. :-) Thanks! Eric