Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 119296 - gnat-3.15p-r5 won't compile
Summary: gnat-3.15p-r5 won't compile
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: ada team [OBSOLETE]
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-17 08:58 UTC by Matti Bickel (RETIRED)
Modified: 2006-01-22 04:45 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matti Bickel (RETIRED) gentoo-dev 2006-01-17 08:58:28 UTC
I got the ghdl from bug 83877. That requires gnat-3.45 AND gnat-3.15 but anyway, here we go.
Gnat-3.45 compiled fine. Then it got to gnat-3.15 and screwed up during configure.
This is what i get from /var/tmp/portage/gnat-3.15p-r5/work/gcc-2.8.1/config.log:
configure:713: checking host system type
configure:734: checking target system type
configure:752: checking build system type
configure:779: checking for gcc
configure:856: checking whether the C compiler (gcc -O2 -gnatpgn ) works
configure:870: gcc -o conftest -O2 -gnatpgn   conftest.c  1>&5
cc1: error: unrecognised debug output level "natpgn"
configure: failed program was:
#line 866 "configure"
#include "confdefs.h"
main(){return(0);}

Well may it be due to the fact that i'm running gcc-4.0.2?

emerge info:
Portage 2.1_pre3-r1 (default-linux/x86/2005.1, gcc-4.0.2, glibc-2.3.6-r2, 2.6.15-rc7-20060101-2 i686)
=================================================================
System uname: 2.6.15-rc7-20060101-2 i686 AMD Athlon(tm) processor
Gentoo Base System version 1.12.0_pre14
dev-lang/python:     2.3.5-r2, 2.4.2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1-r1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon -O2 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig candy ccache distlocks sandbox sfperms strict userpriv usersandbox"
GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/ http://ftp.romnet.org/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://ftp.snt.utwente.nl/pub/os/linux/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="x86 ipv6 kdeenablefinal nptl opengl pic unicode zlib elibc_glibc kernel_linux userland_GNU"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Comment 1 George Shapovalov (RETIRED) gentoo-dev 2006-01-17 10:33:19 UTC
Yes, I noticed that recently. Unfortunately there does not seem to be an easy fix (I tried to rework it for the split). The problem is most likely not the gcc-4.x specifically bur rather an absence of a working gnat-3.15p or gcc-2.8.x on your system (the last one you are not supposed to have). Well, in short it is just broken. Looks like the bootstrap environment the ebuild creates (for the build) is "leaky" and when it was packages it went unnoticed because of the installed gnat-3.15 on the system where it was tested..

>That requires gnat-3.45 AND gnat-3.15 

As far as I can see this happens because of <=dev-lang/gnat-3.15p-r5, which does not make sense at all. Any gnat should be as good as that version, as Ada is pretty strict on standards and gnat adheres to them quite well.. Is ghdl based on gcc-2.8.1 by chance? If yes, I am afraid you will face more problems with ghdl itself after you are done with gnat..

Anyway, the best fix for you would be to emerge gnat-3.45 (please report on your result, I'll stabilize it then) and change that dependency to a plain and simple dev-lang/gnat. The only reason I can think of for having such version restriction is that gnat-3.4x was not quite working back in September, but it is all good now.

George
Comment 2 George Shapovalov (RETIRED) gentoo-dev 2006-01-17 10:39:26 UTC
Oh, on the principal issue of this bug.

The most likely resolution will be "wontfix" when I stabilize the gnat-3.45, add split gnat to portage and mask gnat-3.15p..

I'd suggest testing split gnat ebuilds as well, as we will be moving towards them soon and that dependency will have to be changed (to virtual/gnat most likely). They are coming to the portage (hopefully) today, p-masked first of course, but test reports are very appreciated (they are supposed to work at this stage). See #111340 for details (but do not use attached eclass and ebuilds - they have already changed)..

George
Comment 3 Matti Bickel (RETIRED) gentoo-dev 2006-01-17 11:17:25 UTC
That's fine with me. I've changed the depends of ghdl to just use dev-lang/gnat and it works like a charm.

I'll post this to the ghdl bug then.
Comment 4 George Shapovalov (RETIRED) gentoo-dev 2006-01-17 13:03:46 UTC
You mean it picked up gnat-3.45 and that one built fine and produced a working ghdl?
Good then, thanks for testing!

I am adding x86 and amd64 arch teams to CC then.

Arch teams: please stabilize dev-lang/gnat-3.45 It has passed as many tests as it could possibly pick up users at this point (it seems) and it is the "best working" version of all the gnats we have. Plus the latest version marked stable (x86 and ppc) does not seem to work anymore, so this is (semi)urgent. For this very reason I am bumping the severity of the bug to major (the package is a compiler and other packages depend on it, but it is rather rarely used, so critical status is not warranted). If you feel like it would be Ok for me to stabilize it, just say so, I'll change KEYWORDS myself then..

I mentioned ppc, but I doubt it works there and I have no means to track it on that arch myself (and fixing it is non-trivial, so I cannot really ask ppc arch team to do anything). So we will have to loose ppc until dholm gets back and sorts it out on that arch..

I removed the dependency on #111340 since that one is a tracker kind and will take much longer to resolve and this issue is internal to gnat (non-split one) anyway. Please feel free to close it when you stabilize the package..

George
Comment 5 Andrej Kacian (RETIRED) gentoo-dev 2006-01-17 17:58:04 UTC
gnat-3.45 installs fine on x86, and it builds random ada packages i throw at it. Marked stable on x86.
Comment 6 Chris Parrott (RETIRED) gentoo-dev 2006-01-17 19:51:07 UTC
I am an AT for amd64, so I do not have the power to mark this as stable.  However, I will relay my
experiences below:

I gave gnat-3.45 a go on amd64, and it built and installed just fine for me.

Furthermore, it built dev-ada/asis-3.44 with no trouble at all.  I also tried adding ~amd64 to 
dev-ada/gtkada-2.4.0 in my local portage overlay tree, and this built successfully for me on amd64 as
well.  (I will submit a separate bug requesting that dev-ada/gtkada-2.4.0 be keyworded ~amd64.)  A
sample GtkAda "hello world" program based on this compiled and executed just fine with gnat-3.45, as
well.

However, I did run into problems emerging dev-ada/adabindx-0.7.2-r1 when I tried adding ~amd64 to
it in my local portage overlay tree.  The problem appears to be related to the fact that some of the code
in adabindx is not 64-bit clean; thus gnat-3.45 is not actually at fault here.  (I will submit a separate
bug on this as well.)

Based on these experiences, I would recommend that dev-ada/gnat-3.45 be marked stable for amd64.
Comment 7 George Shapovalov (RETIRED) gentoo-dev 2006-01-22 03:57:47 UTC
Amd64 team: any progress? Or does the AT report (by Chris) mean that I can stabilize it myself? I would really like to close that "gap" that I mentioned in comment #4 (that we need to have a stable version to cover for a presently stable one that does not work as well..).

George
Comment 8 Simon Stelling (RETIRED) gentoo-dev 2006-01-22 04:30:58 UTC
george: feel free to mark it stable on amd64, you've got my blessing ;)
Comment 9 George Shapovalov (RETIRED) gentoo-dev 2006-01-22 04:45:18 UTC
Done, and the original issue is resolved as well.
Closing the bug.