Since bug#64373 has degenerated to "gnat doesn't build on amd64", I've reopened this bug on x86/ppc. The problem is that CFLAGS is set on line 33 in the ebuild, and configure uses that in compiling one of its C test programs. Since gcc uses -gnagpg -gnata by default anyway, I suggest either dropping this, or, if you don't want -gnata, using ADAFLAGS instead. Reproducible: Always Steps to Reproduce: 1. emerge gnat Actual Results: creating cache ./config.cache checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking build system type... i686-pc-linux-gnu checking for a BSD compatible install... /bin/install -c cc1: error: unrecognised debug output level "natpgn" *** The command 'gcc -o conftest -O -gnatpgn conftest.c' failed. *** You must set the environment variable CC to a working compiler. Expected Results: Should've at least gotten to the compile stage (that fails as well for me; see bug#86484)
This one was fixed in 3.44 as well. Please test. George
This with 3.44 and 3.44-r1: creating cache ./config.cache checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking build system type... x86_64-unknown-linux-gnu checking for a BSD compatible install... /bin/install -c /usr/bin/ld: cannot find -lgcc_s collect2: ld returned 1 exit status *** The command 'gcc -o conftest -march=opteron -O2 -fomit-frame-pointer conftest.c' failed. *** You must set the environment variable CC to a working compiler. I can compile other C files with -lgcc_s fine, so it must be something in the ebuild's environment.
Hm, can you please post your emerge info? I would need to reproduce the bug if I am to fix it.. Also, the gnat (and gcc for that matter) is quite picky about what flags you use. Limiting them seems the only reasonable immediate approach I can take. It is nice to give more freedom, but I would really like to first get it all working.. George
Sure: Portage 2.0.51.22-r3 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14.2 x86_64) ================================================================= System uname: 2.6.14.2 x86_64 AMD Opteron(tm) Processor 242 Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 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 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=opteron -O2 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=opteron -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.averse.net/pub/gentoo/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/" LC_ALL="en_AU.utf8" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X alsa apache2 audiofile avi bitmap-fonts bzip2 cdr crypt cups curl dbus dvdr eds emboss encode esd exif expat fam ffmpeg flac foomatic foomaticdb fortran gd gdbm gif glut gmp gpm gstreamer gtk gtk2 guile idn imagemagick imlib ipv6 jack java jikes jpeg junit lcms libwww lua lzw lzw-tiff mad matroska mhash mikmod mng motif mozilla mp3 mpeg ncurses nls offensive ogg oggvorbis openal opengl pam pcre pdflib perl png python quicktime readline recode sdl slang spell sqlite ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales vorbis xine xml xml2 xmms xpm xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LDFLAGS, LINGUAS
Hm, quite puzzling, I don't see any relevant differences from what I have here.. I tried upping my CFLAGS and passing some of your USE's, but it does not trigger here.. Also, what do you mean by this: >I can compile other C files with -lgcc_s fine, so it must be something in the >ebuild's environment. Are you trying to pass -lgcc_s explicitly? It is a "gcc standard library", it is implied pretty much always. If you do pass some extra arguments, please provide them here. Please then indicate the exact command you are using to emerge gnat, unless it is simply emerge gnat of course.. I tried to google for this problem and as AFAICS this is most often related to broken gcc, rarely to multilib. Now, I see you are running the default profile, this includes multilib, so it should be Ok (I have the same one). As for broken gcc, well the ebuild uses provided gcc binary for bootstrapping and should not cause this problem, unless you have some environment vars set that can interfere.. Since not all of them are listed in einfo, I'll post a list below, please check if you have any of them defined system-wide.. GCC_EXEC_PREFIX ADA_OBJECTS_PATH ADA_INCLUDE_PATH LDFLAGS LD_LIBRARY_PATH CC especially LD* ones.. You may want to look into the ebuild to check if you have any other vars defined that are referenced there, just in case.. George
My emerge command was just "emerge gnat". When it failed, I tried compiling some random C files I had around with, eg. "gcc -lgcc_s test.c" just to check if the library paths or something was messed up. I didn't mess around with the environment of the ebuild. As for environment variables, # env |grep CC GCC_SPECS= # env |grep ADA # env |grep LD Anyway, I'll play around with building it manually to try and find the problem.
/var/tmp/portage/gnat-3.44-r2/work/usr/lib/gcc/x86_64-linux-gnu/3.4.5/libgcc_s.so is a symbolic link to /lib/libgcc_s.so.1. This file does not exist on my system either so the configure script fails since the bootstrap gcc is unable to run. George, add your /lib/libgcc_s.so.1 to the bootstrap package and symlink to that one instead. I tried symlinking it to the one from my system gcc but that didn't work.
Thanks David. Fixed now (I repackaged the bootstrap compiler). I will check tomorrow whether new package has propagated to mirrors and then unmask gnat and asis.. George
Hm, looks like I need to put the new version specifically up on distfiles-local, so that it gets pushed to mirrors finally. Just did it, more waiting until mirrors pick it up.. If anybody is impatient, just get the file directly from SRC_URI.. George
Ok, looks like the updated bootstrap compiler form amd64 has propagated to the mirrors. This bug is fixed for all reported problems. Original one should be fixed too, but some reports on x86 would be really wellcome. Oh, and I finally unmasked gnat-3.44-r2 :), on amd64 only for now. Needs testing on x86 and it will probably need some work on ppc.. George
Does not work on x86 yet, reopening the bug. src_unpack and setup are fine, in src_compile goes until bootstrap completion then claims that it does not know about gnatlib_and_tools target. In fact it behaves like it did not enable ada at all! No ada stuff got compiled, not even ada subdir (build/gcc/ada) is copied over, gcc/Makefile does not have ada related vars defined either. This is quite confusing, as this is identical ebuild code as for amd64. I will attach the diff of Makefiles next. George
Created attachment 75651 [details] diff -u gcc/Makefile(x86) gcc/Makefile(amd64) Overall structure is the same, just ada stuff is missing, while ebuild explicitly has --enable-languages=c,ada passed to configure..
Ok, I got the fix for x86, had to repackage bootstrap and make sure the right gcc is picked up for compiling. For some reason x86 was picking system gcc instead of provided one, while amd64 seemed Ok. Changing some local's to export's took care of it.. Both -r1 (~x86 only) and -r2 (~x86 and ~amd64) are in the tree and unmasked.. Closing the bug. George
