Bug#1027065: Clarification
On bookworm (testing) I get:
$ gm2 --version
gm2 (Debian 12.2.0-10) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gm2 hello.mod
hello.mod:1:2: error: expecting one of: ‘IMPLEMENTATION’ ‘MODULE’ ‘DEFINITION’
1 | FROM StrIO IMPORT WriteString, WriteLn;
| ^~~~
hello.mod:1:2: error: compilation failed
Adding a first line, "MODULE hello;" makes the program legal but then I
get the same symptoms as in the original bug report.
Adding -fpim2 or -fpim3 to the compiler command line has no effect.
Adding -fiso silences the compiler even though StrIO is not an ISO
module. Therefore a complete workaround is:
$ cat hello.mod
MODULE hello;
FROM StrIO IMPORT WriteString, WriteLn;
BEGIN
WriteString('hello world');
WriteLn
END hello.
$ gm2 -fiso hello.mod -o hello
$ ./hello
hello world
It seems that libm2pim.so lacks some necessary functions which
libm2iso.so has.
--
Ludovic Brenta.
Bug#950747: projectl: Projectl fails to run with current libgphobos76
severity 951294 important severity 951423 important merge 950747 951294 951423 thanks Hi Matthias, I thought you were going to make gcc-9 (and gnat-9, for Ada) the default in the medium term and migrate to gcc-10 only later. Maybe I misunderstood? Can you please clarify? Are binNMUs planned for all other packages affected? -- Ludovic Brenta.
Bug#814978: gcc-5: gnat paths are wrong due to ada-gcc-name.diff
On Wed, 17 Feb 2016 11:50:04 +0100, Matthias Klose wrote: this might be a bad merge/update; Ludovic, Nicolas, could you have a look? GCC 6 likely has the same issue. Will do. -- Ludovic.
Bug#802838: ada: gnatgcc-5 and gnatmake symlinks
Matthias Klose writes: > I've never understood why this link moved to the versioned gnat > package and didn't stay in the unversioned gnat package. So maybe we > changed that when preparing the ada cross compiler? > > The cross compiler builds shouldn't ship such unversioned links at > all. I very much would prefer to have these links in the unversioned > gnat package again. My first reaction is to agree wholeheartedly but one of Nicolas' greatest qualities is that he discusses and documents such changes beforehand: https://lists.debian.org/debian-ada/2014/04/msg0.html I think the problem he wanted to solve was to be able to build gnat-x.y with itself even during the transition period when gnat pointed to an earlier, or later, on nonexistent, gnat-x'.y'. Now I'm not sure how such a situation could arise, or how it could prevent building gnat-x.y. > Not sure about gnatmake and others. I'm not an gnat developer. If it > is possible that the versioned tools can be used on its own, then > again I would prefer to ship these in the gnat package. No, the "versioned" tools cannot be used on their own. We don't want to require users to type gnatmake-x.y instead of gnatmake; and there is a whole bunch of user-facing programs that call each other, too, like gnatls, gprbuild, etc. -- Ludovic Brenta.
Re: gcc-5 version against upstream
Azat Khuzhin writes: > "Update to SVN 20150911 (r227671, 5.2.1) from the gcc-5-branch. [...] > $ git show [...] > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@227671 > 138bc75d-0d04-0410-961f-82ee72b054a4 ^ [...] > Am I missing something about debian versions VS upstream? Yes, Debian tracks the release branch gcc-5-branch as opposed to trunk. HTH -- Ludovic Brenta.
Re: malloc/free details in gcc5.1
mudongliang wrote: Hello, I want to look at the details of malloc/free in the gcc5.1(I have downloaded). But I don't know the file structure of gcc! Where is the file containing malloc/free ? And is there any advice about reading the source code about gcc? Besides , what's the relationship between gcc and debian-gcc ? How can I do a contribution to debian-gcc ? Thank you! mudongliang In case you are not subscribed to the debian-gcc list to which you post, please read my answer to your first post: https://lists.debian.org/debian-gcc/2015/04/msg00112.html -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8dcd250a9465bc4a5c02bb749c8c4...@ludovic-brenta.org
Re: Basic question about malloc
mudongliang wrote: But the result has no feature about a ,b ,c! Can someone tell me what's wrong with me? My GCC version is gcc (Debian 4.9.2-10) 4.9.2 mudongliang malloc is not part of gcc, it is part of glibc. I think that recent versions of glibc deliberately return random addresses, so the addresses are unpredictable and cannot be used to write malware. This is probably documented in the sources of glibc but first, see malloc(3) and mallopt(3) (e.g. "man malloc" and "man mallopt" on the command line). -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/af4bb28d8b1bc50d41a8bc44520a2...@ludovic-brenta.org
Bug#769797: marked as done (gnat-4.9: FTBFS: Needs update for gcc-4.9-4.9.2)
Neil Williams writes: >> unless you tell me how the b-d >> >> gcc-4.9-source (<< 4.9.2) >> >> is satisfied in unstable, please leave this issue open. > > That doesn't make sense. gnat-4.9 in unstable has build-dependencies > which can be satisfied in unstable. gnat-4.9 in testing has > build-dependencies which can be satisfied in testing. > > Why would the build-dependency gcc-4.9-source (<< 4.9.2) in gnat-4.9 in > *testing* be relevant when checked in unstable? Correct but I think Matthias' mail alludes to his freeze exception request (#774221) which, if and when granted, will break the build-dependency of gnat-4.9 in testing and require that gnat-4.9 also migrate from unstable to testing; I commented to that effect in the request. So, this bug is technically closed but might resurface in the near future. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnlsmt96@ludovic-brenta.org
Re: Merge gnat back to gcc
YunQiang Su writes: > I update this patch for more modification for gnat* to gnat*-4.9. Your new patch still has the same problems (noise, size) and is barely usable. Please do not send a debdiff again; send a diff against the Subversion repository for the packaging[1] instead. [1] http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.9/ -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4r0sx21@ludovic-brenta.org
Re: Merge gnat back to gcc
YunQiang Su writes: > I update this patch, and tested it in 3 situations: > > 1. normal native build >in a chroot, with dpkg-buildpackage -B, it works well >while build it with pbuilder, I met this problem >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713170 > 2. cross build, aka dpkg-buildpackage -amips64el >it works well with in a chroot env. > 3. cross build with target != host, and with_deps_on_target_arch_pkgs=yes > it also works well. Hello, Sorry for not replying earlier. We will not merge gnat-4.9 into gcc-4.9; we will keep them separate source packages. This is because gnat-4.9 has additional build dependencies that should not be imposed on gcc-4.9. Consequently, the changes you reverted in comperr.adb, gnatlink.adb (i.e. debiab/patches/ada-gcc-name.diff) will be retained. In your patch, I see changes to src/gcc/ada/osint.adb. Could you explain why you needed these changes on mips64el? I cannot see why this change is needed. Your debdiff mangled the changes you may have made: --- gcc-4.9-4.9.2/debian/patches/ada-libgnatprj.diff +++ gcc-4.9-4.9.2/debian/patches/ada-libgnatprj.diff @@ -8,10 +8,10 @@ # !!! Must be applied after ada-libgnatvsn.dpatch -Index: b/src/gcc/ada/gcc-interface/config-lang.in +Index: gcc-4.9-4.9.2/src/gcc/ada/gcc-interface/config-lang.in === a/src/gcc/ada/gcc-interface/config-lang.in -+++ b/src/gcc/ada/gcc-interface/config-lang.in +--- gcc-4.9-4.9.2.orig/src/gcc/ada/gcc-interface/config-lang.in 2014-11-10 03:22:59.713708557 +0800 gcc-4.9-4.9.2/src/gcc/ada/gcc-interface/config-lang.in 2014-11-10 03:22:59.705708557 +0800 @@ -34,8 +34,8 @@ outputs="ada/gcc-interface/Makefile ada/Makefile" @@ -23,184 +23,11 @@ # Ada is not enabled by default for the time being. build_by_default=no -Index: b/src/gnattools/Makefile.in +Index: gcc-4.9-4.9.2/src/libgnatprj/Makefile.in === so I cannot see what you changed in src/gnattools/Makefile.in. And it seems you completely removed src/gnattools/Makefile.in from debian/patches/ada-libgnatvsn.diff later on; why? The same applies to the rest of your *huge* patch. It would be much more efficient if you could: - work with two separate source packages: gcc-4.9 and gnat-4.9 - send small, focused patches that apply to files under debian/ and nothing else. A debdiff is too big for us to review. - eliminate noise from your patches, such as: @@ -1527,10 +292,10 @@ fi AC_ARG_ENABLE(libssp, -Index: b/src/libgnatprj/configure.ac +Index: gcc-4.9-4.9.2/src/libgnatprj/configure.ac === /dev/null -+++ b/src/libgnatprj/configure.ac +--- /dev/null 1970-01-01 00:00:00.0 + gcc-4.9-4.9.2/src/libgnatprj/configure.ac 2014-11-10 03:22:59.709708557 +0800 @@ -0,0 +1,146 @@ +# Configure script for libada. +# Copyright 2003, 2004 Free Software Foundation, Inc. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mtqp77u@ludovic-brenta.org
Bug#769797: gnat-4.9: FTBFS: Needs update for gcc-4.9-4.9.2
Matthias Klose writes: > known. please wait for the gcc-4.9 4.9.2-2 upload before syncing. OK. Are you planning to request a freeze exception so that 4.9.2 goes into jessie? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r3x3p3v7@ludovic-brenta.org
Bug#759038: gnat-4.9: gnat1 and libgnatvsn-dev versions differ
I tried my proposed patch but reverted it. The patch did not solve the
problem because the problem was actually simpler; in asis,
A4G.GNAT_Int.Tree_In_With_Version_Check would raise an exception
whenever Gnatvsn.Gnat_Version_String did *not* contain an opening paren
"(". ASIS did not actually check that the Gnatvsn.Gnat_Version_String
in the compiler (gnat1) was the same as that in libgnatvsn; instead it
would try to compare only the "date" portion of the two strings,
assuming this portion was between a "(" and a "-". Moreover, this was
an optional check that the various GNAT tools enabled when they didn't
have to.
I fixed the problem in asis and uploaded yesterday. Therefore, the
actual contents of the Gnatvsn.Gnat_Version_String does not really
matter anymore.
While I would have preferred simplicity and seeing only $(BASEVER), I
made libgnatvsn use $(FULLVER) as well for consistency.
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87k33tfaqq@ludovic-brenta.org
Bug#759038: gnat-4.9: gnat1 and libgnatvsn-dev versions differ
I have committed a proposed change to gcc-base-version.diff as revision 7691. I will try to experiment with this and gnat-4.9 when I have time and will not upload before doko approves of this change. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fvenbrpk@ludovic-brenta.org
Bug#759038: Bug#765467: asis-programs: Version mismatch between GNAT 4.9.1 vs. ASIS 4.9
affects 759038 asis-programs block 765467 by 759038 thanks I have traced #765467 to a discrepancy between debian/patches/ada-libgnatvsn.diff and debian/patches/gcc-base-version.diff, which are patches applied to both gcc-4.9 and gnat-4.9. gcc-base-version.diff changes src/gcc/Makefile.in so that it builds version.o with the flag -DBASEVER=$(FULLVER_s) (where FULLVER_s has the value 4.9.1 and is introduced by this patch; upstream uses only BASEVER_s). This is a recent change introduced for #759038. ada-libgnatvsn.diff rebuilds version.o with -fPIC, so it can be included into libgnatvsn.so.4.9, and passes -DBASEVER=$(BASEVER_s), like upstream does. But the value of BASEVER_s is 4.9, not 4.9.1. Consequently: /usr/bin/gcc-4.9, linked statically with version.o, emits 4.9.1 /usr/bin/gnatpp, linked dynamically with version.o from libgnatvsn4.9, expects 4.9. I think the change made for #759038 should be reverted; as Matthias said, we should use "4.9" consistently, not "4.9.1". I disagree with Nicolas when he says that "gcc -dumpversion" should report 4.9.1; it should report 4.9 instead because Debian only ever uses the tip of the gcc-4_9-branch plus patches, and never exactly "4.9.1". Furthermore, 4.9.2 is looming on the horizon and will not change the format of ASIS tree files, so 4.9 is really the version that should be in the tree files. Assuming this change is reverted, gnat1 will still emit "4.9.1" into the tree files; this is the real issue. Linking gnat1 dynamically against libgnatvsn.so.4.9 might be desirable but seems like a lot of work, and also means that ada-libgnatvsn.diff would become even more intrusive than it already is (and it is not upstreamable without a lot more work because upstream supports many more cross-compiler configurations than we do ATM). In theory, gnat1 is linked statically with version.o, so emits whatever is configured into version.o. Why gnat1 would emit "4.9.1" as reported in #759038 escapes me ATM. gcc-base-version.diff was introduced back in 2011 to change the directories where various pieces of GCC are installed, e.g. /usr/lib/gcc/$(target)/4.6.1 to /usr/lib/gcc/$(target)/4.6 (changing BASEVER from 4.6.1 to 4.6). At the same time, this patch introduced FULLVER (value: 4.6.1). I am not sure why FULLVER is needed at all nowadays. Why not remove FULLVER altogether? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oatdcclu@ludovic-brenta.org
Bug#759407: gnat-4.9: gnat1 not found on kfreebsd-i386
Emilio Pozuelo Monfort writes: > On 21/09/14 02:31, Ludovic Brenta wrote: >> Nicolas Boulenguez writes: >>> A bootstrap issue will remain: building a new gnat-4.9 package >>> installing these symlinks requires a working compiler. >> >> I am now uploading gnat-4.9 4.9.1-2 which solves this problem. I >> bootstrapped it on a kfreebsd-i386 virtual machine in which I created >> the symlinks manually, so that gnat-4.9 4.9.1-1 worked again as the >> bootstrap compiler. >> >> Since this is a policy violation (official packages must be built on >> real hardware, not on virtual machines) I intend to upload -3 to have it >> rebuilt on kfreebsd-i386 with -2. > > Which part of policy is that? Heh, I can't find it back. I thought I remembered this rule from years ago. Maybe I am mistaken. Maybe the package I just uploaded is perfectly fine after all. Or, maybe it is a rule imposed by DSA on porter machines. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mw0u1ww@ludovic-brenta.org
Bug#759407: gnat-4.9: gnat1 not found on kfreebsd-i386
Nicolas Boulenguez writes: > A bootstrap issue will remain: building a new gnat-4.9 package > installing these symlinks requires a working compiler. I am now uploading gnat-4.9 4.9.1-2 which solves this problem. I bootstrapped it on a kfreebsd-i386 virtual machine in which I created the symlinks manually, so that gnat-4.9 4.9.1-1 worked again as the bootstrap compiler. Since this is a policy violation (official packages must be built on real hardware, not on virtual machines) I intend to upload -3 to have it rebuilt on kfreebsd-i386 with -2. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zjdtu84l@ludovic-brenta.org
Bug#759407: gnat-4.9: gnat1 not found on kfreebsd-i386
reassign 759407 src:gcc-4.9 thanks Hello, Svante is correct on one point: some version of gcc-4.9 broke gnat-4.9 on kfreebsd-i386 at least. Proof: on August 11, gnat-4.9 (=4.9.1-1) worked perfectly well when combined with gcc-4.9 (exact version unspecified): https://buildd.debian.org/status/fetch.php?pkg=libtemplates-parser&arch=kfreebsd-i386&ver=11.8.2014-3&stamp=1407787293 The symptoms appeared later, still with gnat-4.9 (=4.9.1-1) but with a later gcc-4.9; not a snapshot. On August 24: https://buildd.debian.org/status/fetch.php?pkg=gnat-gps&arch=kfreebsd-i386&ver=5.3-3&stamp=1408919003 Between these two dates (August 11 and August 24), there were no uploads of gnat-4.9 but there were some uploads of gcc-4.9, therefore gcc-4.9 must have broken something, possibly in the target triplet or directory where it looks for gnat1. Possibly, this bug has already been fixed by the last change in this upload: gcc-4.9 (4.9.1-11) unstable; urgency=medium * Update to SVN 20140830 (r214759) from the gcc-4_9-branch. * Update cross installation patches for the branch. * Use the base version (4.9) when accessing files in gcc_lib_dir. -- Matthias Klose Sat, 30 Aug 2014 22:05:47 +0200 I'll try to check this (on kfreebsd-i386) over the weekend. This particular bug is for kfreebsd-i386 only. hurd-i386 has similar symptoms on different dates (for example, the build of gnat-gps (=5.3-3) succeeded on hurd-i386 when it failed on kfreebsd-i386). I propose to use #761248 (severity important) to track the issue on hurd-i386, if it is different. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ae69c6a2f76f76844c117071e3292...@ludovic-brenta.org
Re: gnat-4.8 update
Andrey Gursky writes: > While gcc 4.8.2 has been updated to 4.8.3, gnat-4.8 has gone except > gnat-4.8-doc [1]. Correct. gnat-4.8-doc should go, too. You should use gnat-4.9 instead. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oaxwtyii@ludovic-brenta.org
Why does gcc-4.9 suddenly build-depend on gdb?
Hello, I see this was added without any comment in revision 7370. As a consequence, gcc-4.9 and gnat-4.9 both fail to build on the hurd-i386 buildd due to the missing build-dependency. Could you please explain why gcc must build-depend on gdb? --- branches/sid/gcc-4.9/debian/control.m4 2014/05/08 12:17:38 7367 +++ branches/sid/gcc-4.9/debian/control.m4 2014/05/13 08:51:00 7370 @@ -70,6 +70,7 @@ autogen, zlib1g-dev, gawk, lzma, xz-utils, patchutils, BINUTILS_BUILD_DEP, binutils-hppa64 (>= BINUTILSBDV) [hppa], gperf (>= 3.0.1), bison (>= 1:2.3), flex, gettext, + gdb (>= 7.6.2-1.1), texinfo (>= 4.3), locales, sharutils, procps, FORTRAN_BUILD_DEP JAVA_BUILD_DEP GNAT_BUILD_DEP GO_BUILD_DEP GDC_BUILD_DEP CLOOG_BUILD_DEP MPC_BUILD_DEP MPFR_BUILD_DEP GMP_BUILD_DEP -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6faf413fa366c15ea62bf71013c61...@ludovic-brenta.org
Bug#749869: gnat-4.9-base: arch-dependent file in "Multi-Arch: same" package
tags 749869 pending thanks I have moved the offending file to the architecture-dependent package gnat-4.9. This mirrors a similar arrangement in gcc-4.9 and gcc-4.9-base. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874n04dx8v@ludovic-brenta.org
Bug#749574: gnat-4.9: Gnatlink fails with CONSTRAINT_ERROR in gnatlink.adb
I have found the reason why upstream gnatlink appears to work where
Debian's gnatlink fails.
Consider this program:
with Ada.Text_IO;
procedure A is
type String_Access is access String;
G : constant String (3 .. 5) := "345";
H : constant String_Access := new String'(G);
begin
if G (1 .. 2) = "ab" then -- line 1
Ada.Text_IO.Put_Line ("True");
else
Ada.Text_IO.Put_Line ("False");
end if;
if H.all (1 .. 2) = "ab" then -- line 2
Ada.Text_IO.Put_Line ("True");
else
Ada.Text_IO.Put_Line ("False");
end if;
end A;
If you compile normally, GNAT correctly warns that Constraint_Error will
be raised at run time at line 1 since the bounds of G are static (3..5)
and different from the ones in the "if" statement; and this is exactly
what happens if you run the program.
If you compile with -gnatpg, you get no warning and the program runs and
prints:
False
False
Well, gnatlink.adb contains such a construct at line 2195. Upstream
compiles gnatlink.adb with -gnatpg and Debian compiles it without
-gnatpg, thereby forcing conformance with Ada semantics. This explains
the difference in behavior.
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87tx88qphd@ludovic-brenta.org
Bug#749574: gnat-4.9: Gnatlink fails with CONSTRAINT_ERROR in gnatlink.adb
I have been able to fix this problem by patching gnatlink.adb; patch attached. I am puzzled by your report that this bug is not triggered in the home-built upstream gnat-4.9 snapshot (gcc-4.9-20140112). Could you please try the following in the directory containing mai_read_config.adb: cat > gdb-gnatlink <From: Ludovic Brenta Forwarded: no Bug-Debian: http://bugs.debian.org/749574 Description: Constraint_Error, range check failed at gnatlink.adb:2195, when called from gnatmake with -D option The procedure gnatlink assumes that the Linker_Options.Table contains access values to strings whose 'First index is always 1. This assumption is wrong for the string returned by function Base_Name. . Instead of fixing the assumption in many places, this patch changes the function Base_Name always to return a string with 'First=1. . This looks like an upstream bug but strangely the reporter of this bug says it does not happen on GCC built from upstream sources. Further investigation is required to determine whether or not to forward this bug and patch upstream. Index: b/src/gcc/ada/gnatlink.adb === --- a/src/gcc/ada/gnatlink.adb +++ b/src/gcc/ada/gnatlink.adb @@ -273,7 +273,12 @@ Findex2 := File_Name'Last + 1; end if; - return File_Name (Findex1 .. Findex2 - 1); + declare + Result : String (1 .. Findex2 - Findex1); + begin + Result (1 .. Findex2 - Findex1) := File_Name (Findex1 .. Findex2 - 1); + return Result; + end; end Base_Name; ---
Re: removal of upstream gnat support for KFreeBSD
Robert Millan wrote: On 22/05/14 12:02, Matthias Klose wrote: Hi, in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56274 Arnaud Charlet proposes to remove the KFreeBSD Ada support upstream, unless somebody cares about the port. Please can the Debian gnat maintainers or the Debian KFreeBSD porters forward the KFreeBSD changes upstream? It currently builds in 4.9. Hi Matthias Please refer to Debian maintainer duties in Developers' Reference section 3.1.4. I think I am the target of this reply as I maintain gnat in Debian. I don't know what role you had so far with the ada-kfreebsd patches for gnat, or in the existing support for GNU/kFreeBSD in GNAT upstream, or with the specific PR ada/56274. Are you trying to say that you refuse to forward ada-kfreebsd.diff upstream and that I should do it myself? See, the problem is that I do not use GNU/kFreeBSD myself and I cannot commit with upstream to maintain this patch, if I should submit it. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1b5797364afae16937f3727f455a9...@ludovic-brenta.org
Bug#673772: gnat-4.8: mips: ATC with syscalls not working
I have requested removal of gnat-4.8 from the archive; can you tell me if this bug is still presend in gnat-4.9? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k3a3w58m@ludovic-brenta.org
Bug#717014: gnat-4.8: on some archs, a library using Elementary_Functions needs -lm
I have requested removal of gnat-4.8 from the archive; can you tell me if this bug is still presend in gnat-4.9? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87iopnw56y@ludovic-brenta.org
Bug#687642: armel armhf: gcc -shared reads libgnarl.a instead of .so
I have requested removal of gnat-4.8 from the archive; can you tell me if this bug is still presend in gnat-4.9? IIUC, upstream has improved support for arm in this new release. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87siorw5c9@ludovic-brenta.org
Bug#666106: gnat-4.8: kfreebsd-i386: Exceptions with tracebacks in task rendezvous cause STORAGE_ERROR
I have requested removal of gnat-4.8 from the archive. Can you please tell me whether this bug is still present in gnat-4.9? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oazfw5ad@ludovic-brenta.org
Re: please don't break GCC snapshot builds
On Fri, 25 Apr 2014 15:37:38 +0100, Ludovic Brenta wrote: Matthias Klose wrote: Please don't break GCC snapshot builds by not applying needed patches for the snapshot builds. At least the ppc64el build is broken, now fixed in the vcs. I didn't check other targets like, arm, mips, the Hurd and KFreeBSD. Could you please elaborate on what exactly caused the breakage? I specifically made as many patches as possible unconditional and applied them as early as possible. You moved ada-ppc64el from unconditional, early to unconditional, late. Therefore I assume that there is a conflict between ada-ppc64el and some other patch that is applied only on snapshot builds? Perhaps the problem is with this other patch, then? Actually I noticed the following only now: [lots of patches including all Ada- and Go-related patches...] # all patches below this line are applied for gcc-snapshot builds as well ifeq ($(single_package),yes) debian_patches = endif [more patches] I think this construct is *extremely* error-prone; this line blindly erases the carefully-crafted debian_patches variable and starts afresh. In my opinion, the only patches that should be applied only on the stable branch are svn-updates.diff and the various backporting patches; and this should be made more obvious from the names of the variables. For example: stable_only_patches = \ svn-updates \ $(if $(with_linaro_branch),gcc-linaro-revert) \ $(if $(with_linaro_branch),gcc-linaro) \ all_branch_patches = gcc-textdomain # note: currently "stable only"; why? [...] # No more patches beyond this line! ifeq ($(single_package),yes) debian_patches = $(all_branch_patches) else debian_patches = $(stable_only_patches) $(all_branch_patches) endif -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/36ce079a21dede9635ea93e097577...@ludovic-brenta.org
Re: please don't break GCC snapshot builds
Matthias Klose wrote: Please don't break GCC snapshot builds by not applying needed patches for the snapshot builds. At least the ppc64el build is broken, now fixed in the vcs. I didn't check other targets like, arm, mips, the Hurd and KFreeBSD. Could you please elaborate on what exactly caused the breakage? I specifically made as many patches as possible unconditional and applied them as early as possible. You moved ada-ppc64el from unconditional, early to unconditional, late. Therefore I assume that there is a conflict between ada-ppc64el and some other patch that is applied only on snapshot builds? Perhaps the problem is with this other patch, then? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/13759b0c165b1c10b9987521f2ad1...@ludovic-brenta.org
Bug#745372: When build apt (1.0.1) with gcc-4.9, it cannot start with libstdc++6 (4.8)
Everything looks fine on amd64 but the bug was reported on mips64el. Perhaps there is a discrepancy between architectures? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ef295bea3e0d312f0dfc606d6ff97...@ludovic-brenta.org
Bug#742590: gnat-4.9: FTBFS on powerpc, Storage_Error in two source files
Package: src:gnat-4.9 Version: 4.9-20140218-1 Severity: serious Symptoms from the buildd log: /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -W -Wall -gnatpg -nostdinc a-direct.adb -o a-direct.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-direct.o] Error 1 make[7]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada/rts-static-zcx' make[6]: *** [rts-static-zcx/libgnat.a] Error 2 make[6]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[5]: *** [gnatlib-static-zcx] Error 2 make[5]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[4]: *** [gnatlib-static-zcx] Error 2 make[4]: *** Waiting for unfinished jobs /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -W -Wall -gnatpg -nostdinc a-direct.adb -o a-direct.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-direct.o] Error 1 make[7]: *** Waiting for unfinished jobs /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -fPIC -W -Wall -gnatpg -nostdinc -fPIC a-direct.adb -o a-direct.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-direct.o] Error 1 make[7]: *** Waiting for unfinished jobs /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -W -Wall -gnatpg -nostdinc -g -O1 -fno-inline \ -fno-toplevel-reorder a-except.adb -o a-except.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-except.o] Error 1 make[7]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada/rts-static-sjlj' make[6]: *** [rts-static-sjlj/libgnat.a] Error 2 make[6]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[5]: *** [gnatlib-static-sjlj] Error 2 make[5]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[4]: *** [gnatlib-static-sjlj] Error 2 /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -fPIC -W -Wall -gnatpg -nostdinc -fPIC -g -O1 -fno-inline \ -fno-toplevel-reorder a-except.adb -o a-except.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-except.o] Error 1 make[7]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada/rts-shared-zcx' make[6]: *** [rts-shared-zcx/libgnat-4.9.so] Error 2 make[6]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[5]: *** [gnatlib-shared-zcx] Error 2 make[5]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[4]: *** [gnatlib-shared-zcx] Error 2 make[4]: Leaving directory `/«PKGBUILDDIR»/build/libada' make[3]: *** [all-libada] Error 2 make[3]: Leaving directory `/«PKGBUILDDIR»/build' make[2]: *** [bootstrap] Error 2 make[2]: Leaving directory `/«PKGBUILDDIR»/build' Note that none of these exceptions are raised when using the bootstrap compiler (gnat-4.6) to compile a-except.adb. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f6ed76ed772986db6fbaa27644d43...@ludovic-brenta.org
Bug#740286: gnat-4.9: s-osinte-posix.adb is wrong about timespec.tv_nsec compared to gnat-4.8
The thread I referenced ends here: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02069.html So it seems upstream is aware of the issue but has been unable to find the time to fix it properly. If you send a proper patch to them, I think they'd be delighted. Note that x32 seems *not* to adhere to POSIX in this respect as it defines "long" to be 32-bit but uses a 64-bit value for timespec.tv_nsec. You cannot change that but you can try to support all architectures in a clean way as Arno suggested. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/32064d432041f12f2b8403081126e...@ludovic-brenta.org
Bug#740286: gnat-4.9: s-osinte-posix.adb is wrong about timespec.tv_nsec compared to gnat-4.8
The reasons for the upstream change are explained in the bug report I referenced: http://gcc.gnu.org/PR54040, and discussed in detail in the thread referenced there, viz.: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01504.html Since the decision to use time_t instead of long has been discussed and approved upstream, I think you should take your objections there, i.e. by following up to that thread. I will not change s-osinte-posix.adb without approval from upstream but I will take your suggestion to change ada-kfreebsd.diff to use s-osinte-posix.adb, introducing time_t in the private part of s-osinte-kfreebsd-gnu.ads. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3c1bfa3e3388f2840b2d37563dec1...@ludovic-brenta.org
Bug#740286: gnat-4.9: s-osinte-posix.adb is wrong about timespec.tv_nsec compared to gnat-4.8
Ludovic Brenta writes: > Svante Signell writes: >> Ping, adding this bug report to debian-ada too. Who is Ada upstream? > > Patience. I'm waiting for Matthias to upload a newer gcc-4.9-source > containing the fix for your bug #740153, then I will upload a gnat-4.9 > incorporating this and your patch. Now that the newer gcc-4.9 has been uploaded, I am reviewing this issue and I discovered that the change you complain about was in fact made upstream (that was not clear to me from your bug report): commit e3a1f6b50495473f677f413d8740808a3fde5a9a Author: hjl Date: Fri Nov 15 12:06:25 2013 + Add and use System.Linux.time_t for time_t PR ada/54040 * s-linux-x32.ads: New file. * s-osprim-x32.adb: Likewise. * s-linux.ads (time_t): New type. * s-linux-alpha.ads (time_t): Likewise. * s-linux-hppa.ads (time_t): Likewise. * s-linux-mipsel.ads (time_t): Likewise. * s-linux-sparc.ads (time_t): Likewise. * s-osinte-linux.ads (time_t): Mark it private. Replace long with System.Linux.time_t. (timespec): Replace long with time_t. * s-osinte-posix.adb (To_Timespec): Likewise. * s-taprop-linux.adb (timeval): Replace C.long with System.OS_Interface.time_t. * gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS): Replace s-linux.ads with s-linux-x32.ads, s-osprim-posix.adb with s-osprim-x32.adb for x32. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@204840 138bc75d-0d04-0410-961f-82ee72b054a4 I also see that s-osinte-gnu.ads, which is used solely by hurd-i386 and added by the Debian patch ada-hurd.diff, has this to say about the matter: type time_t is new long; type timespec is record tv_sec : time_t; tv_nsec : long; end record; pragma Convention (C, timespec); I propose to make "time_t" a subtype, rather than a derived type, of long. This should keep everyone happy. Comments? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871txsbx77@ludovic-brenta.org
Re: gnat changes for gcc-4.9
Matthias Klose writes: > thanks for merging back the Ada changes. r7211 did basically remove > the go-use-gold.diff patch, which I did undo again. OK. > upstream now has zcx exception support for ARM, so would it be > possible to drop the sjlj based exception support for the jessie > release? Is anybody using this on platforms where the zcx support is > available? Asking because the current support isn't good enough for > cross-building the package. I'd be more than happy to switch to ZCX by default on ARM but I'm reluctant to drop support for SJLJ entirely (it is provided as an optional run-time library package, gnat-x.y-sjlj, containing only the static library). Many cross targets in particular require SJLJ. (i.e. when GNAT is built as a cross-compiler, not when it is cross-built as a native compiler for another arch). I seem to remember that distributed programs using PolyORB also require (or used to require) SJLJ. Currently, all architectures use ZCX by default, except arm, armel and armhf. Removing this special case would probably make it less difficult to cross-build the package. I'd be happy further to improve this. For starters, is it OK if I apply this change: # # old_revision [7bba5de1abb7ad3b6377861211f78f74e2e5b873] # # patch "debian/rules.defs" # from [9bcc0582ad336443ec66faf5d20bc39e3bb8afd7] #to [0ffcd613785071cd79a4f771b5ff9de624d9577a] # --- debian/rules.defs 9bcc0582ad336443ec66faf5d20bc39e3bb8afd7 +++ debian/rules.defs 0ffcd613785071cd79a4f771b5ff9de624d9577a @@ -536,29 +536,8 @@ ifeq ($(with_ada),yes) ifeq ($(with_ada),yes) enabled_languages += ada with_libgnat := yes - # There are two exception handling mechanisms: ZCX (Zero-Cost - # eXceptions) and SJLJ (setjump/longjump), selected and supported by - # libgnat. Thus we build both versions of libgnat on architectures - # that support both (see ada-sjlj.diff). Most cpus support both - # mechanisms; here, we declare the few that support only one. - libgnat_zcx_only_cpus := - libgnat_sjlj_only_cpus := arm armel armhf - ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(libgnat_sjlj_only_cpus))) -with_gnat_zcx := no - else -with_gnat_zcx := yes - endif - ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(libgnat_zcx_only_cpus))) -with_gnat_sjlj := no - else -with_gnat_sjlj := yes - endif - ifeq ($(with_gnat_zcx)-$(with_gnat_sjlj),no-no) -# TODO: support cpus that do not support exceptions at all, -# perhaps by building a restricted runtime library? For now, flag -# this as a packaging error. -$(error this target supports neither ZCX nor SJLJ) - endif + with_gnat_zcx := yes + with_gnat_sjlj := yes endif # C++ - I'm hesitant as to whether I should drop the two variables, with_gnat_zcx and with_gnat_sjlj, entirely. Removing them implies dropping support for any future architecture that supports only one mechanism (all current architectures do support both, now). But it would simplify the Debian build machinery quite a bit. > Also is there any progress in upstreaming the libgnatproj* additions? No progress so far, sorry. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874n2rdzp6@ludovic-brenta.org
Bug#740286: gnat-4.9: s-osinte-posix.adb is wrong about timespec.tv_nsec compared to gnat-4.8
Svante Signell writes: > Ping, adding this bug report to debian-ada too. Who is Ada upstream? Patience. I'm waiting for Matthias to upload a newer gcc-4.9-source containing the fix for your bug #740153, then I will upload a gnat-4.9 incorporating this and your patch. In the mean time, Xavier, do you have any comments on this specific bug? In particular, how do you think Svante's change might affect GNU/kFreeBSD? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wqfsfsx7@ludovic-brenta.org
Re: Bug#713124: gnat-4.6: FTBFS: unsatisfiable build-dependency: automake (< 1:1.12) but 1:1.13.3-1 is to be installed
Is there any reason to specify "Build-Depends: automake (< 1:1.12)"? I can build this package without it. Patch attached. Thanks but please modify debian/control.m4 and debian/rules.conf, not debian/control, which is generated. I cannot answer your question myself because these build-dependencies are from the GCC sources. doko, can you shed some light on this? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/7a70258ebf6ca426e6570641f9144...@ludovic-brenta.org
Latest gnat-4.9 merged into branches/sid/gcc-4.9
Hi, I have finally merged the latest changes from gnat-4.9 into gcc-4.9; this is Subversion revision 7211. I must warn about one change that Xavier Grave made to debian/patches/go-use-gold.diff, which is in theory unrelated to Ada. Without this change, the patch fails to apply on the 20140218 sources. Feel free to revert that change if necessary. Also, the three patches: ada-s-osinte-gnu.adb.diff ada-s-taprop-gnu.adb.diff gcc_ada_gcc-interface_Makefile.in.diff are now merged into a single patch, ada-hurd.diff, which is applied on all architectures if Ada is enabled. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhwj9fdt.fsf...@ludovic-brenta.org
Re: Re. gcc-4.9_4.9-20140303-1_amd64.changes ACCEPTED into experimental
Matthias Klose writes: > Am 04.03.2014 11:17, schrieb Svante Signell: >> Since gcc-4.9_4.9-20140218-1 does not build on GNU/Hurd due to a >> minor error in gcc/lto/lto.c, see bug #740153, I had hopes that this >> version could have included that patch (and forwarded upstream). The >> currently main reason to have gcc-4.9 building on GNU/Hurd since it >> is needed for gnat-4.9, and we are working on making it build on >> GNU/Hurd too. > > Sorry, I missed that patch. Now applied. > > I don't see myself responsible for forwarding hurd specific or gnat > specific patches. That really should be the responsibility of the > porters or the debian ada maintainers. You can CC me when report the > issue upstream (including a ChangeLog entry). > > Plus, until now I didn't see any merging back of gnat-4.9 specific > patches into gcc-4.9. It's unfortunate that this doesn't happen on a > regular basis. Ludovic, any update on this? Yes, that's unfortunate and a consequence of my limited available time. I'm back from a week of skiing, catching up on my 300+ emails and I will try to merge back from gnat-4.9 to gcc-4.9 when time permits. Sorry about that. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87iornbnuj@ludovic-brenta.org
Upstream sources in future uploads of gnat-4.8
Hello, I have decided to include the upstream sources in future uploads of gnat-4.8, staring with 4.8.1-1 in a couple of weeks (if all goes well). Merging gnat-4.8 into the gcc-4.8 source package is also an option but I prefer to keep the two separate because I have too little time available for Debian to keep up with the rapid pace of uploads of gcc-x.y and because subversion, where the Debian packaging is kept, is not well equipped to handle parallel branches of development especially merging. It occurred to me that maybe the best thing to do would be to turn gnat-4.8 into a proper 3.0 (quilt) source package where the .orig.tar.gz would contain the already-unpacked upstream sources (i.e. not a tarball inside a tarball) and the debian/patches/series file would be maintained directly unser source control, rather than generated by "debian/rules patch". I understand that generating debian/patches/series is currently necessary to distinguish between native and cross-compilers. I think it would be acceptable to have a "fixed" set of patches in debian/patches/series plus a "variable" set of patches, applied on top of the "fixed" set, for cross-compilers. The "fixed" set would be applied directly by dpkg-source and the "variable" set would be constructed & applied later by debian/rules patch. What do you think of this? (The contents of debian/patches/series should not depend on the language front-ends being compiled, either). Ideally we could get rid of "debian/rules unpack" entirely and simplify the code base of Debian packaging. The fixed set of patches, i.e. debian/patches/series, would also simplify debian/rules.patch quite a bit. Ideas, objections? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hahg7rou@ludovic-brenta.org
Re: gnat-4.8_4.8.0-1~exp1_amd64.changes is NEW
Matthias Klose writes: > Am 25.04.2013 23:17, schrieb Ludovic Brenta: >>> Ludovic, seen that the gnat-4.7 and gnat-4.8 uploads did wait in NEW >>> for the last three months, please could you make these available on >>> people.debian.org too? >> >> Done, at last. Sorry for the delay. This build (4.8.0-1~exp2) includes >> your patch for gnatmake -shared. For which, a big thank you. Did you >> come up with this patch on your own, or did you receive it from someone >> else? >> >> You can get the files from http://people.debian.org/~lbrenta/gnat-4.8. > > when merging back these changes, I did notice that some files were not removed > when merging from gcc into gnat: > > - old libobjc[23] files > - debian/patches/arm-multilib.diff > - cross-*-trunk.diff > - debian/patches/gcc-powerpc-nof-trunk.diff > - debian/patches/libjava-disable-static.diff > - debian/patches/m68k-allow-gnu99.diff > - debian/patches/m68k-fp-cmp-zero.diff > - debian/patches/mudflap-varargs.diff > - debian/patches/no_fpr_in_libgcc.diff > - pr43804.diff, pr47487.diff, pr48226.diff, pr48830.diff, pr49030.diff, >pr49169.diff, pr49696.diff, pr49756.diff, pr50114.diff, pr50193.diff, Thanks, I've corrected that, though I couldn't find the revision(s) that deleted these files in the gcc-4.8 branch. Not a big problem though. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc78z1sm@ludovic-brenta.org
Re: gnat-4.8_4.8.0-1~exp1_amd64.changes is NEW
Matthias Klose writes: > Am 18.04.2013 22:48, schrieb Debian FTP Masters: >> binary:libgnatprj4.8-dev is NEW. >> binary:libgnat-4.8 is NEW. >> binary:gnat-4.8-sjlj is NEW. >> binary:libgnatvsn4.8-dev is NEW. >> binary:libgnatvsn4.8-dbg is NEW. >> binary:libgnatprj4.8-dbg is NEW. >> binary:libgnatprj4.8 is NEW. >> binary:libgnatvsn4.8 is NEW. >> binary:libgnat-4.8-dbg is NEW. >> binary:gnat-4.8 is NEW. >> binary:gnat-4.8-base is NEW. >> source:gnat-4.8 is NEW. >> >> Your package contains new components which requires manual editing of >> the override file. It is ok otherwise, so please be patient. New >> packages are usually added to the override file about once a week. > > Ludovic, seen that the gnat-4.7 and gnat-4.8 uploads did wait in NEW > for the last three months, please could you make these available on > people.debian.org too? Done, at last. Sorry for the delay. This build (4.8.0-1~exp2) includes your patch for gnatmake -shared. For which, a big thank you. Did you come up with this patch on your own, or did you receive it from someone else? You can get the files from http://people.debian.org/~lbrenta/gnat-4.8. Note that I strongly recommend against including gnat-4.8 in Ubuntu 13.04, whenever that ships, and also in 13.10 because I don't think that the other Ada packages will have migrated by then. Also, I anticipate that I might change the aliversion of libgnatvsn and libgnatprj before the package stabilizes; this would invalidate any binary package that depends on them. I'm uploading to experimental for a reason :) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obd21f9n@ludovic-brenta.org
Re: GCC-4.8 on the horizon
Eric Botcazou writes: >> - [CCing Eric for this] the gnatprj and gnatvsn libs are built >>for Debian only. Is there any way, that these libs could be >>integrated into upstream (maybe conditionally)? > > What's the status of these libraries? Who owns the copyright? These libraries are built from the GCC sources, so the FSF owns the copyright. libgnatvsn contains those packages, under GPL with Runtime Library Exception, that are shared with ASIS for GNAT. libgnatprj contains the pure GPL units for the project manager: part of gnatmake, shared with GPS, and using libgnatvsn. Only changes to the GCC build machinery are necessary to produce these two libraries. If you're going to attend FOSDEM, I suggest we meet to discuss this in more detail. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/876233sgw0@ludovic-brenta.org
Re: GCC and Built-Using
On Fri, 04 Jan 2013 15:05:46 +0100, Matthias Klose wrote: Am 04.01.2013 14:54, schrieb Ansgar Burchardt: Matthias Klose writes: I won't change this. Please feel free to open a bug against debian-policy and subscribe me. The current wording of 7.8 in the footnote 56 suggests that the exact binary version is recorded, which is not needed for the gnat-*, gcj-* builds, and seems to be over engineered. Built-Using records source versions used, not binary versions. It needs to be an exact version to tell dak which version of the referenced source package it should keep. (And that's the only use of this field, it does not affect installations or anything else.) but it's not relevant which version is used. The only thing used is the upstream tarball, which doesn't change. How about packaging this upstream tarball (i.e. gcc-x.y-source) independently of all other packages, such that a new upload of gcc-x.y does not change gcc-x.y-source? For one thing, it would avoid wasting bandwidth re-uploading the upstream tarball with each upload of gcc-x.y. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/f5935c79b4cef349a386c39b74dcb...@ludovic-brenta.org
Re: GCC-4.8 on the horizon
Matthias Klose wrote: Hi, experimental now has gcc-4.8 packages. There are some things I would like to see: - a lot of patches from 4.6 still does apply. Please could you evaluate these patches, and send these upstream if required? would love to see these for 4.8.0 upstream. I've been really busy in real life these past months; I've been able to find some time to start porting my patches to GCC 4.7. All patches up to ada-libgnatprj.diff apply cleanly but the build fails; I'm investigating. During the christmas vacation I plan to try and start work on GCC 4.8. - [CCing Eric for this] the gnatprj and gnatvsn libs are built for Debian only. Is there any way, that these libs could be integrated into upstream (maybe conditionally)? This reminds me of [1] which I sent upstream and that, apparently, everyone has forgotten about -- myself included. Applying that to GCC would remove one Debian-specific patch. Eric, could you please have a look at it? I don't think I can find the time to re-submit this patch against 4.8 until January. [1] http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00594.html -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e3025dfbc7aced3d7bd2ec099f116...@ludovic-brenta.org
Re: Bug#669513: Removal of gnat-4.4 due to RC bug #669513
Tobias Hansen writes: > Am 06.12.2012 20:57, schrieb Tobias Hansen: >> Am 06.12.2012 20:44, schrieb Ludovic Brenta: >>> Tobias Hansen writes: >>>> since we have gnat-4.6 in wheezy and gnat-4.4 does not build anymore >>>> (see #669513), can gnat-4.4 be removed? >>> >>> Yes but maybe notify the maintainers of the sole package still depending >>> on it, ghdl. This package is the reason I've refrained from asking for >>> removal of gnat-4.4 sthus far. >>> >>> Thanks for your time and concern >> >> Since you are a gnat-4.4 uploader, will you file the removal request? I >> will file a bug against ghdl. By the way, ghdl is not in wheezy anymore, >> only in unstable. >> > > I filed a bug against ghdl, #695303, and it really needs gnat-4.4 for > now. The FTBFS of gnat-4.4 can probably be fixed in unstable by updating > it to the most recent version. But to fix #669513 in wheezy, gnat-4.4 > should be removed. I'll file a request for that ok? Yes please. I've been stuck in real life recently :) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9tjdk3t@ludovic-brenta.org
Re: Bug#669513: Removal of gnat-4.4 due to RC bug #669513
Tobias Hansen writes: > since we have gnat-4.6 in wheezy and gnat-4.4 does not build anymore > (see #669513), can gnat-4.4 be removed? Yes but maybe notify the maintainers of the sole package still depending on it, ghdl. This package is the reason I've refrained from asking for removal of gnat-4.4 sthus far. Thanks for your time and concern -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3svdkyk@ludovic-brenta.org
Bug#687642: gnat-4.6: libgnarl-4.6.a should be rebuilt with -fPIC, libaws FBTFS
Konstantinos Margaritis wrote: libgnarl-4.6.a is the *static* library, it should definitely not be compiled with -fPIC. The *shared* library, libgnarl-4.6.so, is already built with -fPIC. If you have time before I do, please investigate why gnatmake, invoked thus: gnatmake -j1 -fPIC -p -Pdebian/build_aws.gpr -Xkind=dynamic \ -Xsoname=libaws.so.2.10.2 tries to link the new shared library against the static version of libgnarl-4.6. If we're lucky, the problem is in build_aws.gpr; if we're unlucky, it is in gnatmake itself and only strikes on armhf because all other architectures are OK. I have a hunch that the latter is closer to the truth :/ This is what I get: # gnatmake -j1 -fPIC -p -Pdebian/build_aws.gpr -Xkind=dynamic -Xsoname=libaws.so.2.10.2 building dynamic library for project build_aws gcc-4.6 -shared -o /root/libaws-2.10.2/debian/tmp/dynamic//libaws.so.2.10.2 ... /root/libaws-2.10.2/debian/tmp/obj-dynamic/aws-services-directory.o ... /usr//bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/4.6/adalib//libgnarl-4.6.a(s-taprop.o): relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/arm-linux-gnueabihf/4.6/adalib//4.6.a: could not read symbols: Bad value collect2: ld returned 1 exit status gnatmake: gcc-4.6 execution error This confirms what I said: gnatmake (or gnatlink) is trying to link the *shared* libaws.so.2.10.2 against the *static* libgnarl-4.6.a, which is *wrong*. I don't know in which program this bug is in: either build_aws.gpr or gnatmake or gnatlink. It still looks like a problem in libgnarl-4.6.a to me. armhf is built with Thumb2 which according to some more knowledgeable people than myself, has only 25 bits for largest relocation vs 27 bits in arm mode. Usually, this is not a problem but some packages do fail to build because of this. What works without -fPIC on most architectures, can potentially need -fPIC on armhf (and I've filed quite a few bugs about this myself. No. As I said previously, it is necessary to link the *shared* libaws.so.2.10.2 against the *shared* libgnarl-4.6.so.1. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2592c8605c52786ccc2596ae3b308...@ludovic-brenta.org
Re: Changes to gcc's documents (particularly gnat's)
Guo Yixuan writes: > -* GNAT Reference Manual: (gnat_rm-4.4). > +* GNAT 4.4 Reference Manual: (gnat_rm-4.4). > > This will make gnat-4.4-doc and gnat-4.6-doc co-installable, for > example. (Although I know gnat-4.4 and gnat-4.6 conflicts, > co-installable is a good idea, IMO.) Please tell me if it's not > appropriate or there're better ideas. I wouldn't say it is appropriate but it is unnecessary. The plan for wheezy is not to support gnat-4.4 at all; if I could remove it altogether I would. Only one package, ghdl, still needs it. If you've already done the work and there is now more commonality with the other languages, then keep the split. Thanks for your time and contribution! -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5ipwtoc@ludovic-brenta.org
Bug#687642: gnat-4.6: libgnarl-4.6.a should be rebuilt with -fPIC, libaws FBTFS
libgnarl-4.6.a is the *static* library, it should definitely not be compiled with -fPIC. The *shared* library, libgnarl-4.6.so, is already built with -fPIC. If you have time before I do, please investigate why gnatmake, invoked thus: gnatmake -j1 -fPIC -p -Pdebian/build_aws.gpr -Xkind=dynamic \ -Xsoname=libaws.so.2.10.2 tries to link the new shared library against the static version of libgnarl-4.6. If we're lucky, the problem is in build_aws.gpr; if we're unlucky, it is in gnatmake itself and only strikes on armhf because all other architectures are OK. I have a hunch that the latter is closer to the truth :/ Thanks for the bug report. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/fc6ac9acf769e34a324ccebdae5d1...@ludovic-brenta.org
Bug#683004: FTBFS on kfreebsd-*: Internal error: abort in get_output_file_with_visibility
reassign 683004 src:gcc-4.6 severity 683004 important forcemerge 683004 637236 affects 637236 + src:gcj-4.6 thanks Duplicate bug report, this time affecting gcj-4.6. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lii4q09t@ludovic-brenta.org
Bug#623382: Ping - gnat fatal error - gone away?
reassign 623382 gnat 4.4+1 close 623382 gnat/4.4+1.1 thanks This bug was, in fact, in gnat rather than gnat-4.4. If has been fixed and closed for several months and I wonder why you followed up on this bug. Perhaps it is not properly marked as closed; I'm attempting to fix that. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcirkpol@ludovic-brenta.org
Bug#667184: gnat-4.6: intermittent FTBFS, race condition in Makefiles with too many parallel processes
retitle 667184 gnat-4.6: intermittent FTBFS, race condition in gnattools/Makefile severity 667184 important user debian-gcc@lists.debian.org usertags - ftbfs-gcc-4.7 thanks This bug has nothing to do with gcc-4.7. Analysis of the full log file reveals that the bootstrap used 10 parallel processes, which triggered this race condition. Building the executable program 'gnatfind' requires the object file xref_lib.o, which does not exist yet because another gnatmake is still building it. I think the problem is that make is running several gnatmake processes in parallel in the same directory (one for each tool to build). The various gnatmake processes step on each other's toes. The fix is to run the gnatmake processes sequentially but pass the parallel option to each of them, so they can run parallel compilations as needed. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bdbcab8e0723777a3e9dfdab7076f...@ludovic-brenta.org
debian/rules2 runs the libstdc++-v3 testsuite against the *installed* library
This fails for me when building gnat-4.6: make[1]: Entering directory `/home/lbrenta/src/debian/gnat-4.6-4.6.3' rm -f test-protocol chmod 755 /home/lbrenta/src/debian/gnat-4.6-4.6.3/src/contrib/test_summary : # libstdc++6 built from newer gcc-4.x source, run testsuite against the installed lib sed 's/-L[^ ]*//g' /home/lbrenta/src/debian/gnat-4.6-4.6.3/build/x86_64-linux-gnu/libstdc++-v3/scripts/testsuite_flags \ > /home/lbrenta/src/debian/gnat-4.6-4.6.3/build/x86_64-linux-gnu/libstdc++-v3/scripts/testsuite_flags.installed /bin/bash: /home/lbrenta/src/debian/gnat-4.6-4.6.3/build/x86_64-linux-gnu/libstdc++-v3/scripts/testsuite_flags.installed: No such file or directory make[1]: *** [stamps/06-check-stamp] Error 1 In debian/rules2 I see: ifneq ($(with_common_libs),yes) : # libstdc++6 built from newer gcc-4.x source, run testsuite against the installed lib sed 's/-L[^ ]*//g' $(buildlibdir)/libstdc++-v3/scripts/testsuite_flags \ > $(buildlibdir)/libstdc++-v3/scripts/testsuite_flags.installed The 'sed' line is the one that fails. I am not building libstdc++, so I don't have the $(buildlibdir)/libstdc++-v3/ directory at all. I can understand there is some value in running all versions of the testsuite (from gcc-4.*) against the installed library (now built from gcc-4.7 only) but there appears to be no place where we run the testsuite against the *just-built* library. Is this intentional? Also, the test "ifneq ($(with_common_libs),yes)" seems entirely wrong to me. When with_common_libs = yes, we are not running the testsuite, even if we build it; when with_common_libs = no, we are assuming that we just built the libstdc++ and we run the testsuite against another version of the library. Should the test not be, simply, "ifeq ($(with_libcxx),yes)"? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87397zmhwp@ludovic-brenta.org
Re: gcc-4.6_4.6.3-4_multi.changes ACCEPTED into unstable
This upload does not seem to correspond to any revision in Subversion. The latest revision (r5970) starts with: gcc-4.6 (4.6.3-4) UNRELEASED; urgency=low Are there any other changes in this upload besides those in r5970? -- Ludovic Brenta. > Changes: > gcc-4.6 (4.6.3-4) unstable; urgency=low > . > [ Matthias Klose ] > * Update to SVN 20120416 (r186492) from the gcc-4_6-branch. > - Fix PR middle-end/52894, PR target/52717, PR target/52775, > PR target/52775. > * Update the Linaro support to the 4.6-2012.04 release. > * Fix PR middle-end/52870, taken from the trunk (Ulrich Weigand). > Linaro only. LP: #968766. > * Fix ICE (regression) in Linaro gcc-4.6 (Ulrich Weigand). > LP: #972648. > * Don't build ARM biarch runtime libraries, now built from the > gcc-4.7 sources. > * Set the ARM hard-float linker path according to the consensus: > http://lists.linaro.org/pipermail/cross-distro/2012-April/000261.html > . > [ Samuel Thibault ] > * ada-s-osinte-gnu.adb.diff, ada-s-osinte-gnu.ads.diff, > ada-s-taprop-gnu.adb.diff, gcc_ada_gcc-interface_Makefile.in.diff: > Add ada support for GNU/Hurd, thanks Svante Signell for the patches > and bootstrap! (Closes: #668425). -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d375m0e3@ludovic-brenta.org
Bug#247020: gnat: Illegal program not detected, self renames
retitle 247020 [Fixed in 4.7] Illegal program not detected, self renames thanks -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/694793a8a7bf791739b69a8364a78...@ludovic-brenta.org
Bug#247020: gnat: Illegal program not detected, self renames
rename 247020 [Fixed in 4.7] Illegal program not detected, self renames thanks -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0947a4eeca7b73cb2511cb9bd5975...@ludovic-brenta.org
Bug#642981: gnat-4.6: ICE in update_ssa_across_abnormal_edges, at tree-inline.c:1853
affects 642981 gnat-gps thanks This bug also affects four source files of gnat-gps 5.0 on armel only: gcc-4.6 -c -g -O2 -gnatafno -gnatVa -I- -gnatA /build/buildd-gnat-gps_5.0-2-armel-1dgOLi/gnat-gps-5.0/browsers/src/browsers-call_graph.adb +===GNAT BUG DETECTED==+ | 4.6.2 (arm-unknown-linux-gnueabi) GCC error: | | in update_ssa_across_abnormal_edges, at tree-inline.c:1853 | gcc-4.6 -c -g -O2 -gnatafno -gnatVa -I- -gnatA /build/buildd-gnat-gps_5.0-2-armel-1dgOLi/gnat-gps-5.0/kernel/src/gps-kernel-hooks.adb +===GNAT BUG DETECTED==+ | 4.6.2 (arm-unknown-linux-gnueabi) GCC error: | | in update_ssa_across_abnormal_edges, at tree-inline.c:1853 | | Error detected around /build/buildd-gnat-gps_5.0-2-armel-1dgOLi/gnat-gps-5.0/kernel/src/gps-kernel-hooks.adb:1651:25| gcc-4.6 -c -g -O2 -gnatafno -gnatVa -I- -gnatA /build/buildd-gnat-gps_5.0-2-armel-1dgOLi/gnat-gps-5.0/src_editor/src/src_editor_box.adb +===GNAT BUG DETECTED==+ | 4.6.2 (arm-unknown-linux-gnueabi) GCC error: | | in update_ssa_across_abnormal_edges, at tree-inline.c:1853 | | Error detected around /build/buildd-gnat-gps_5.0-2-armel-1dgOLi/gnat-gps-5.0/src_editor/src/src_editor_box.adb:1552:7| gcc-4.6 -c -g -O2 -gnatafno -gnatVa -I- -gnatA /build/buildd-gnat-gps_5.0-2-armel-1dgOLi/gnat-gps-5.0/ada_module/core/src/ada_semantic_tree-units.adb +===GNAT BUG DETECTED==+ | 4.6.2 (arm-unknown-linux-gnueabi) GCC error: | | in update_ssa_across_abnormal_edges, at tree-inline.c:1853 | | Error detected around /build/buildd-gnat-gps_5.0-2-armel-1dgOLi/gnat-gps-5.0/ada_module/core/src/ada_semantic_tree-units.adb:461:23| I'll apply the same workaround as in libtemplates-parser. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k45g8gju@ludovic-brenta.org
Bug#650764: gnat-4.4: FTBFS: sinput.adb:776:19: deallocation from empty storage pool
_Intr). * sem_intr.adb (Check_Intrinsic_Call): Add check for deallocation from empty storage pool, moved here from Exp_Intr and made into error. (Check_Intrinsic_Call): Remove assumption in generating not-null free warning that the name of the instantiation is Free. * sinput.adb (Tree_Read): Document use of illegal free call allowed in GNAT mode. * types.ads: Remove storage size clauses from big types (since we may need to do deallocations, which are now illegal for empty pools). So I think that backporting the entire commit (affecting exp_intr.adb, sem_intr.adb, sinput.adb and most importantly types.ads) to gnat-4.4 should resolve this bug. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjl1272o@ludovic-brenta.org
Bug#649306: gnat-4.6: FTBFS on armel (configure: error: GNAT is required to build ada)
Julien Cristau writes: > On Sat, Nov 19, 2011 at 23:43:03 +0100, Ludovic Brenta wrote: > >> doko, you said merging gcc-4.6 4.6.2-4 into gnat-4.6 would fix this >> FTBFS but it hasn't. The buildd log does not indicate the exact version >> of gcc-4.6 installed on the machine; perhaps I should tighten the > > It does, it was gcc-4.6_4.6.2-4. See the 'Toolchain package versions' > line. Thanks but I see all four of: g++-4.4_4.4.6-11 g++-4.6_4.6.2-4 gcc-4.4_4.4.6-11 gcc-4.6_4.6.2-4 in that line. Mmm. I also see: : # configure cd /build/buildd-gnat-4.6_4.6.2-2-armel-bK1oIn/gnat-4.6-4.6.2/build \ && PATH=/build/buildd-gnat-4.6_4.6.2-2-armel-bK1oIn/gnat-4.6-4.6.2/bin:/usr/lib/arm-linux-gnueabi/gcc/bin:$PATH \ CC="gcc-4.4" \ further down. This is a result of this in debia/rules2: ifeq ($(REVERSE_CROSS),yes) CC= else CC= $(if $(filter yes,$(with_ada)),gnatgcc,gcc) ifneq ($(PKGSOURCE),gcc-snapshot) # doesn't bootstrap using gcc-4.5 on armel ifneq (,$(filter $(DEB_TARGET_ARCH), armel)) CC = gcc-4.4 endif endif ifeq (,$(findstring gnat,$(PKGSOURCE))) ifneq (,$(filter $(DEB_TARGET_ARCH), kfreebsd-amd64 kfreebsd-i386)) CC = gcc-4.4 endif endif endif I see that Matthias has just removed this bit in svn; this means that merging from gcc-4.6 4.6.2-5 will actually fix this bug. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762ifvav4@ludovic-brenta.org
Bug#649307: gnat-4.6: FTBFS on kfreebsd-amd64 (gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998)
Julien Cristau writes: > On Sat, Nov 19, 2011 at 23:32:48 +0100, Ludovic Brenta wrote: > >> retitle 649307 FTBFS on kfreebsd-amd64: gengtype: Internal error: abort in >> get_output_file_with_visibility, at gengtype.c:1998 >> reassign 649307 src:gcc-4.6 >> severity 649307 important >> forcemerge 649307 637236 >> thanks >> >> Julien and everyone else, please stop filing FTBFS bugs automatically >> against gcc-4.6 or gnat-4.6. We monitor the buildds and are aware of >> FTBFS, so these bugs are not useful for us and only take away some of >> our precious time for triaging. Thanks. > They may not be useful to you bug they're useful to everyone else. Yes, I see you used the new bug to block the bug for the transition of Perl. Nevertheless, if you would have googled for "gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998" you would have found #637236, which you could have used just as well to block the transition bug. > Why are you downgrading this bug? - Because gnat-4.6/kfreebsd-amd64 has just been uploaded by some kind soul. - Because the bug only happens on buildds and intermittently, as documented in #637236. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa7rvhxv@ludovic-brenta.org
Bug#649306: gnat-4.6: FTBFS on armel (configure: error: GNAT is required to build ada)
tags 649306 help thanks doko, you said merging gcc-4.6 4.6.2-4 into gnat-4.6 would fix this FTBFS but it hasn't. The buildd log does not indicate the exact version of gcc-4.6 installed on the machine; perhaps I should tighten the build-dependencies og gnat-4.6 to gcc-4.6 (>= 4.6.2-4) ? Do you have any other suggestions? Should an ARM porter have a look? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hb1zvimg@ludovic-brenta.org
Bug#649307: gnat-4.6: FTBFS on kfreebsd-amd64 (gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998)
retitle 649307 FTBFS on kfreebsd-amd64: gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998 reassign 649307 src:gcc-4.6 severity 649307 important forcemerge 649307 637236 thanks Julien and everyone else, please stop filing FTBFS bugs automatically against gcc-4.6 or gnat-4.6. We monitor the buildds and are aware of FTBFS, so these bugs are not useful for us and only take away some of our precious time for triaging. Thanks. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lirbvj3j@ludovic-brenta.org
Bug#637236: gcc-4.6/gcj-4.6 build failures on kfreebsd-amd64 are back again
Robert Millan writes: >> Matthias tried to disable parallel builds on kfreebsd-*: >> >> ifneq (,$(filter $(DEB_TARGET_ARCH), kfreebsd-amd64 kfreebsd-i386)) >> USE_NJOBS = no >> endif >> >> but it looks like the DEB_BUILD_OPTIONS on fano overrode him: >> >> # Support parallel= in DEB_BUILD_OPTIONS (see #209008) >> ifneq (,$(filter parallel=%,$(subst $(COMMA), ,$(DEB_BUILD_OPTIONS >> NJOBS := -j $(subst parallel=,,$(filter parallel=%,$(subst $(COMMA), >> ,$(DEB_BUILD_OPTIONS >> endif >> >> The package FTBFS on fano (the kfreebsd-amd64 buildd). >> >> As Matthias is travelling, I'll try to upload 4.6.1-3 this weekend. > > Cool, thanks! The build on fano failed again despite using only one job :( At this point I'll have to leave it to kFreeBSD porters to find the real cause. There must be a difference between the buildds and asdfasdf.debian.net. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877h3mf95k@ludovic-brenta.org
Re: gcc-4.6/gcj-4.6 build failures on kfreebsd-amd64 are back again
Robert Millan writes: > 2011/10/27 Matthias Klose : >> looks like bug #637236 is back again. is this a buildd issue again? >> can the package be built locally? > > The #637236 log suggests that the problem is likely to be a race > condition. About one month ago, Petr asked [1] if parallel build > could be disabled. In the bug log this question remains unanswered. > > Could parallel build be disabled, either unconditionally or > specifically for (kfreebsd-)amd64? > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637236#37 Matthias tried to disable parallel builds on kfreebsd-*: ifneq (,$(filter $(DEB_TARGET_ARCH), kfreebsd-amd64 kfreebsd-i386)) USE_NJOBS = no endif but it looks like the DEB_BUILD_OPTIONS on fano overrode him: # Support parallel= in DEB_BUILD_OPTIONS (see #209008) ifneq (,$(filter parallel=%,$(subst $(COMMA), ,$(DEB_BUILD_OPTIONS NJOBS := -j $(subst parallel=,,$(filter parallel=%,$(subst $(COMMA), ,$(DEB_BUILD_OPTIONS endif The package FTBFS on fano (the kfreebsd-amd64 buildd). As Matthias is travelling, I'll try to upload 4.6.1-3 this weekend. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjmcg2i8@ludovic-brenta.org
Bug#644849: gnat-4.6: does not work with current gcc-4.6
Matthias, this bug is going to cause all future uploads of GNAT to FTBFS, because gnat-4.6 is already the default and the buildds will install the broken gcc-4.6 and try to build gnat-4.6 with it. So, I think the solution has to be in gcc-4.6. In the past, we used to have symlinks like /usr/lib/gcc/x86_64-linux-gnu/4.6.1 -> 4.6. Do you have any objection against reintroducing these symlinks? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uumounp@ludovic-brenta.org
Bug#642981: gnat-4.6: ICE in update_ssa_across_abnormal_edges, at tree-inline.c:1853
Disabling inlining (i.e. removing -gnatn from the compiler options) works around the bug. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3efroh2@ludovic-brenta.org
Bug#642981: gnat-4.6: ICE in update_ssa_across_abnormal_edges, at tree-inline.c:1853
retitle 642981 gnat-4.6: ICE in update_ssa_across_abnormal_edges, at tree-inline.c:1853 thanks This bug exists even with -O1 and -O0, it is not in the optimizer. Investigation continues. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hb3rroyt@ludovic-brenta.org
Bug#642980: gnat-4.6: ICE in interpret_loop_phi, at tree-scalar-evolution.c:1645
This bug is in the optimizer. Compiling with -O0 avoids it; -O1 and -O2 both trigger the bug. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/07d9e992081dbd71d67c6533f4488...@ludovic-brenta.org
Bug#642128: gnat-4.6: fails to build spark on kfreebsd
Євгеній Мещеряков writes: > 29 вересня 2011 о 20:15 +0200 Євгеній Мещеряков написав(-ла): >> Hmm, that symbol looks global to me: >> >> $ nm -D /lib/x86_64-kfreebsd-gnu/libpthread.so.0 | grep >> pthread_mutexattr_destroy >> 7b70 T __pthread_mutexattr_destroy >> 7b70 T pthread_mutexattr_destroy > > I can also build a C program: [...] Try removing the --gc-sections linker options, per [1]. It looks like it is this option that triggers a bug in ld. If this works, please close the gnat-4.6 bug and check whether a corresponding bug is already open against ld. [1] https://lists.gnu.org/archive/html/bug-binutils/2011-09/msg00128.html -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877h4rw3uv@ludovic-brenta.org
Bug#635126: gcc-4.6: miscompilation with -ftree-sra
severity 635126 important thanks Downgrading this bug as an easy workaround has been found. This will allow gcc-4.6 to migrate to testing. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cf916b3bdff527fbb6b112b64db34...@ludovic-brenta.org
Bug#637236: gcc-4.6: FTBFS on kfreebsd-amd64: gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998
severity 637236 important thanks It appears that gcc-4.6 4.6.1-13 built successfully on the buildd, fano.d.o. Downgrading this bug so gcc-4.6 can migrate to testing. However the buildd logs contain a disturbing history of failures, retries and eventual successes: 4.6.1-13 OK on fano FTBFS on fasch FTBFS on fasch FTBFS on fano 4.6.1-12 OK on fano 4.6.1-11 OK on fasch FTBFS on fasch FTBFS on fano 4.6.1-10 OK on fasch FTBFS on fasch 4.6.1-9 OK on fasch FTBFS on fasch FTBFS on fasch FTBFS on fano etc. I would very much like to understand the changes on both buildd machines that allow the package to build, or cause it to FTBFS. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/66bb10a64c88621c2f96066062957...@ludovic-brenta.org
Bug#642128: gnat-4.6: fails to build spark on kfreebsd
tags 642128 sid pending thanks I think I have a solution for this problem. As it turns out, GNU/kFreeBSD does not support these optional parts of POSIX threads whereas FreeBSD does. I'll upload within 48 hours. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7ba5e239e99dc69dd52b29b8a4fb7...@ludovic-brenta.org
Bug#642981: gnat-4.6:
Package: gnat-4.6 Version: 4.6.1-5 Severity: important Tags: upstream sid libtemplates-parser FTBFS with the following ICE: gcc-4.6 -c -gnat05 -gnatwcfijkmruv -gnaty3abcefhiIklmnoprstx -Wall -O2 -gnatn -I- -gnatA /build/buildd-libtemplates-parser_11.6-1-armel-7ATaJo/libtemplates-parser-11.6/src/templates_parser.adb /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb: In function 'Templates_Parser.Filter.Filter_Map.Insert.New_Node': /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb:536:13: warning: 'E' may be used uninitialized in this function [-Wuninitialized] /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb: In function 'Templates_Parser.Macro.Rewrite.Set_Var.Insert.New_Node': /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb:536:13: warning: 'E' may be used uninitialized in this function [-Wuninitialized] /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb: In function 'Templates_Parser.Macro.Rewrite.Set_Var.Copy_Node': /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb:165:10: warning: 'E' may be used uninitialized in this function [-Wuninitialized] /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb: In function 'Templates_Parser.Macro.Registry.Insert.New_Node': /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb:536:13: warning: 'E' may be used uninitialized in this function [-Wuninitialized] /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihase.adb: In function 'Templates_Parser.Tag_Values.Query_Element': /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihase.adb:1080:18: warning: '' may be used uninitialized in this function [-Wuninitialized] /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb: In function 'Templates_Parser.Association_Map.Insert.New_Node': /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb:536:13: warning: 'E' may be used uninitialized in this function [-Wuninitialized] /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb: In function 'Templates_Parser.Association_Map.Copy_Node': /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb:165:10: warning: 'E' may be used uninitialized in this function [-Wuninitialized] /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb: In function 'Templates_Parser.Macro.Registry.Copy_Node': /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb:165:10: warning: 'E' may be used uninitialized in this function [-Wuninitialized] /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb: In function 'Templates_Parser.Filter.Filter_Map.Copy_Node': /usr/lib/gcc/arm-linux-gnueabi/4.6.1/adainclude/a-cihama.adb:165:10: warning: 'E' may be used uninitialized in this function [-Wuninitialized] +===GNAT BUG DETECTED==+ | 4.6.1 (arm-unknown-linux-gnueabi) GCC error: | | in update_ssa_across_abnormal_edges, at tree-inline.c:1853 | | Error detected around /build/buildd-libtemplates-parser_11.6-1-armel-7ATaJo/libtemplates-parser-11.6/src/templates_parser-filter.adb:824:15| [...] raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423 gnatmake: "/build/buildd-libtemplates-parser_11.6-1-armel-7ATaJo/libtemplates-parser-11.6/src/templates_parser.adb" compilation error make[1]: *** [build] Error 4 -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/eaaa7053e9fbacbb48dc5f0b63ad6...@ludovic-brenta.org
Bug#642980: gnat-4.6: TYPES.UNRECOVERABLE_ERROR : comperr.adb:423
Package: gnat-4.6 Version: 4.6.1-5 Severity: important Tags: upstream sid asis FTBFS on kfreebsd-amd64, mips and mipsel with the following: gcc-4.6 -c -fPIC -g -O2 -gnatafno -gnatwa -gnatVa -I- -gnatA /build/buildd-asis_2010-2-kfreebsd-amd64-k7wLVQ/asis-2010/asis/asis-text.adb +===GNAT BUG DETECTED==+ | 4.6.1 (x86_64-pc-kfreebsd-gnu) GCC error: | | in interpret_loop_phi, at tree-scalar-evolution.c:1645 | | Error detected around /build/buildd-asis_2010-2-kfreebsd-amd64-k7wLVQ/asis-2010/asis/asis-text.adb:1069:1| [...] raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423 gnatmake: "/build/buildd-asis_2010-2-kfreebsd-amd64-k7wLVQ/asis-2010/asis/asis-text.adb" compilation error -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8d96ce47338bc70002f93646c8b16...@ludovic-brenta.org
Bug#640314: gnat-4.4: FTBFS: collect2: ld returned 1 exit status
Mònica Ramírez Arceda writes: >> /build/gnat-4.4-zZBW7n/gnat-4.4-4.4.6/build/gnattools/xref_lib.o: file not >> recognized: File truncated Filesystem full? Please look earlier in the build log for confirmation. >> collect2: ld returned 1 exit status > > The full build log is available from: > > http://people.debian.org/~lucas/logs/2011-09-02/gnat-4.4_4.4.6-5_lsid64.buildlog "The requested URL /~lucas/logs/2011-09-02/gnat-4.4_4.4.6-5_lsid64.buildlog was not found on this server." -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehzwz8zd@ludovic-brenta.org
Re: sparse and multiarch include paths
Josh Triplett writes: > When trying to use sparse on some low-level userspace code, I ran into > the following error: > > /usr/include/bits/socket.h:381:11: error: unable to open 'asm/socket.h' See http://bugs.debian.org/638418 Hope this helps -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkiy1ld2@ludovic-brenta.org
Bug#637418: gnat-4.6 ftbfs with eglibc-2.13-16
tags 637418 upstream forwarded 637418 http://gcc.gnu.org/PR50048 thanks -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87liuz6alw@ludovic-brenta.org
Re: Bug#637418: gnat-4.6 ftbfs with eglibc-2.13-16
tags 637418 pending thanks On Thu, 11 Aug 2011 10:42:31 +0200, Matthias Klose wrote: clone 637418 -1 reassign -1 linux-libc-dev block 637418 by -1 thanks looks like a kernel headers issue doko: the difference is that with the i386/x86-64 headers, asm/sigcontext.h was not included with the i386 headers it is so it looks like a bug in the kernel headers, but triggered by eglibc changes I found that patching src/gcc/ada/gcc-interface/Makefile.in, in the constant INCLUDES, to replace -I- (deprecated) with -iquote allowed gnat-4.6 to build on i386. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/6ae6bfff4c6f212e2a2022250f514...@ludovic-brenta.org
Bug#637236: FTBFS on kfreebsd-amd64: gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998
Package: src:gcc-4.6 Version: 4.6.1-3 Severity: serious Tags: help >From the buildd logs on kfreebsd-amd64[1]: gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998 I got this error also when building gnat-4.6 on a different buildd[2], but not on asdfasdf.debian.net, the porter box, where the package builds fine. Could this error be specific to the two buildd machines? [1] https://buildd.debian.org/status/fetch.php?pkg=gcc-4.6&arch=kfreebsd-amd64&ver=4.6.1-6&stamp=1312911887 [2] https://buildd.debian.org/status/fetch.php?pkg=gnat-4.6&arch=kfreebsd-amd64&ver=4.6.1-3&stamp=1312911422 -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ty9q5srm@ludovic-brenta.org
Bug#636291: gnat on kfreebsd
Thorsten Glaser wrote: > when I looked at this at Debconf 11, I copied two functions from the > Linux or FreeBSD (don’t remember, used the one that looked more fitting) > file over. The exact diff I sent to Christoph Egger, don’t have it with > me any more. > > Christoph, can you send the patch here for difference? It differs from > http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00139.html I've already uploaded (yesterday evening) with my proposed patch but if your patch is better, I'll be happy to upload with yours. > Ludovic, I have copyright assignment to the FSF (also for GCC) standing, > so this shouldn’t be a problem. OK but in this particular case, I don't think an assignment is necessary since the patch consists in copying FSF-owned material from one FSF-owned file to another. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/35f4bce85fa0f3946e74e9d4f9895f89@localhost
Bug#636692: gnat-4.6: FTBFS on kfreebsd-*: "s-taprop.adb:856:10: "pthread_attr_setaffinity_np" is undefined (more references follow)"
notforwarded 636692 http://gcc.gnu.org/PR49444 forwarded 636692 http://gcc.gnu.org/PR49944 thanks -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r550ot4x@ludovic-brenta.org
Bug#636692: gnat-4.6: FTBFS on kfreebsd-*: "s-taprop.adb:856:10: "pthread_attr_setaffinity_np" is undefined (more references follow)"
forwarded 636692 http://gcc.gnu.org/PR49444 thanks -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjpgot68@ludovic-brenta.org
Bug#636692: gnat-4.6: FTBFS on kfreebsd-*: "s-taprop.adb:856:10: "pthread_attr_setaffinity_np" is undefined (more references follow)"
Package: src:gnat-4.6 Version: 4.6.1-1 Severity: serious Tags: upstream In the build logs at https://buildd.debian.org/status/fetch.php?pkg=gnat-4.6&arch=kfreebsd-amd64&ver=4.6.1-2&stamp=1311435165 we see: /build/buildd-gnat-4.6_4.6.1-2-kfreebsd-amd64-Jts3n3/gnat-4.6-4.6.1/build/./gcc/xgcc -B/build/buildd-gnat-4.6_4.6.1-2-kfreebsd-amd64-Jts3n3/gnat-4.6-4.6.1/build/./gcc/ -c -g -O2 -W -Wall -gnatpg s-taprop.adb -o s-taprop.o s-taprop.adb:717:32: "lwp_self" is undefined s-taprop.adb:856:10: "pthread_attr_setaffinity_np" is undefined (more references follow) This bug is about the second failure. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wresp0tn@ludovic-brenta.org
Re: Recent svn update broke kbsd-gnu.diff
Ludovic Brenta writes: > The following commit broke kbsd-gnu.diff: > > r5442 | doko | 2011-07-23 08:20:31 +0200 (Sat, 23 Jul 2011) | 2 lines > > * Update to SVN 20110723 (r176672) from the gcc-4_6-branch. > > Specifically, it introduces a new hunk that patches gcc/config.gcc at > lines 1281 and following. This hunk conflicts with a hunk in > kbsd-gnu.diff. > > Maybe it would be nice to apply kbsd-gnu.diff unconditionally, instead > of only on kfreebsd-*, so that such breakage becomes visible more > immediately? Sorry for the noise, I was working off of 4.6.1-5 and noticed only after sending this mail that Aurelien had already corrected this in r5453. Still, applying kbsd-gnu.diff unconditionally would be a good idea IMHO. I'll refrain from making the change myself; I'll leave the decision to Aurelien and Matthias. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r554qfd4@ludovic-brenta.org
Recent svn update broke kbsd-gnu.diff
The following commit broke kbsd-gnu.diff: r5442 | doko | 2011-07-23 08:20:31 +0200 (Sat, 23 Jul 2011) | 2 lines * Update to SVN 20110723 (r176672) from the gcc-4_6-branch. Specifically, it introduces a new hunk that patches gcc/config.gcc at lines 1281 and following. This hunk conflicts with a hunk in kbsd-gnu.diff. Maybe it would be nice to apply kbsd-gnu.diff unconditionally, instead of only on kfreebsd-*, so that such breakage becomes visible more immediately? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o20sgqj@ludovic-brenta.org
Bug#636291: gnat-4.6: FTBFS on kfreebsd-* with s-taprop.adb:717:32: "lwp_self" is undefined
Package: src:gnat-4.6 Version: 4.6.1-1 Severity: serious Tags: upstream /build/buildd-gnat-4.6_4.6.1-2-kfreebsd-amd64-Jts3n3/gnat-4.6-4.6.1/build/./gcc/xgcc -B/build/buildd-gnat-4.6_4.6.1-2-kfreebsd-amd64-Jts3n3/gnat-4.6-4.6.1/build/./gcc/ -c -g -O2 -W -Wall -gnatpg s-taprop.adb -o s-taprop.o s-taprop.adb:717:32: "lwp_self" is undefined s-taprop.adb:856:10: "pthread_attr_setaffinity_np" is undefined (more references follow) I have traced this to the following commit: commit a0d9619fa08b438aaeda58cb70100b803942e9fe Author: charlet Date: Wed Apr 15 10:06:20 2009 + 2009-04-15 Nicolas Roche * adaint.c: Add function __gnat_lwp_self that retrieves the LWP of the current thread. * s-osinte-linux.ads: Import the __gnat_lwp_self function as lwp_self * s-taprop-linux.adb (Enter_Task): Store the LWP in the TCB git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@146097 138bc75d-0d04-0410-961f-82ee72b054a4 The function __gnat_lwp_self exists in adaint.c only #if defined(linux), so it may not apply to kfreebsd-*. The problem exists because kfreebsd-* uses s-osinte-kfreebsd-gnu.ads, which does not import the function, but also uses s-taprop-linux.adb, which does use the function. I am not sure what to do: either introduce a new file s-taprop-kfreebsd-gnu.adb or provide the function __gnat_lwp_self also on kfreebsd-* and import it in s-osinte-kfreebsd-gnu.ads. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3gosk6b@ludovic-brenta.org
Bug#634546: gnat-4.6: FTBFS: make[4]: *** No rule to make target `../gcc/ada/rts-shared-zcx/libgnat-.so', needed by `gnattools-native'. Stop.
tags 634546 unreproducible moreinfo thanks I have rebuilt gnat-4.6 successfully on amd64 on multiple occasions since you filed this bug, including the upload of 4.6.1-2. Please close the bug or provide more details. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipqgsmsf@ludovic-brenta.org
Bug#635112: gnat-4.6: probably miscompiled on powerpc
tags 635112 upstream pending forwarded 635112 http://gcc.gnu.org/PR49819 thanks Євгеній Мещеряков writes: > severity 635112 serious > thanks > > I also noticed that gnat-4.6 on powerpc constans no g-trasym.adb, but it > is present on x86_64. Also build log for gnat-4.6 contains this: > >cp: cannot stat `rts-shared-zcx/g-trasym.adb': No such file or directory >cp: cannot stat `rts-static-sjlj/g-trasym.adb': No such file or directory > > I guess there are wrong depencencies between make targets somewhere. Thanks, this led me to finding the problem, which is in the upstream sources. It is easy to correct; I'll upload a fix today or the day after. I've forwarded the bug as http://gcc.gnu.org/PR49819. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aac5x5q3@ludovic-brenta.org
Re: Could multiarch conflict singel arch?
Mats Erik Andersson wrote: > Hello there, > > I must throw in a word of caution. On my main development machine, > running single arch i686, I find that gcc-4.5_4.5.3-3 and gcc-4.4_4.4.6-6 > are gravely brokon on my machine: They can not generate executables! > > Downgrading gcc and cpp to 4.5_4.5.3-1 and 4.4_4.4.6-3 restores the > expected functionality. These are the version before activation of > mutliarch support! Are you all sure that there is no implicit > infrastructure dependency? Yes indeed, see bugs #631906 (for gcc-4.4), #631926 (for gcc-4.5) and #631627 (for gcc-4.6). And my earlier message on this list: http://lists.debian.org/debian-gcc/2011/06/msg00209.html -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/fd97b80c5ade2a3caaf3ccca60677f60@localhost
Bug#631926: /usr/bin/ld: cannot find -lgcc_s
tags 631926 wheezy pending thanks This bug affects testing/wheezy only (not sid) and can be closed when libgcc1 (>= 1:4.6.0-12) migrates to testing. The current version in sid is 1:4.6.1-1. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/544b377b3053ee1ff1a23f190f0e1d47@localhost
Bug#631627: gcc-defaults version 4:4.4.5-1 non-functional on Wheezy (missing libgcc_s.so)
tags 631627 wheezy pending found 631627 gcc-4.6/4.6.0-10 notfound 631627 gcc-4.6/4.6.0-12 severity 631627 important thanks This bug is present only in testing and will disappear when libgcc1 (>= 1:4.6.0-12) migrates to testing. The version currently in unstable is 1:4.6.1-1. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/95ea965b416bea9d0602baa60c3fe60f@localhost
Bug#631906: gcc-4.4: cannot find -lgcc_s after upgrade to 4.4.6-6
Thanks for submitting this bug for gcc-4.4; a similar one (#631627) exists for gcc-4.6. My analysis of this bug (with workaround) is here: http://lists.debian.org/debian-gcc/2011/06/msg00209.html -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ee41186db887cd50266eadfc449116d9@localhost
Migration of multiarch into testing
I think I have found the root cause of #631627 and #631817 but I would like confirmation. My theory is: * on 2011-06-08, gcc-4.6 4.6.0-12 (and libgcc1) to unstable introduced support for multiarch. * on 2011-06-09, eglibc 2.13-6 was built on unstable against the multiarch-aware libgcc1. * on 2011-06-12, eglibc 2.13-7 was built on unstable against the multiarch-aware libgcc1. * on 2011-06-25, eglibc 2.13-7 migrated to testing. But libgcc1 (currently at 4.6.0-14) still has not migrated to testing. As a consequence, ld looks for libgcc_s.so in the wrong (multiarch-aware) place. If my theory is correct, the fix is simply to allow libgcc1 to migrate to testing. There is a mysterious problem there; the PTS says the package should have migrated five days ago but is out of date on powerpc; the buildd logs indicate the build succeeded on 2011-06-18. Had libgcc1 migrated to testing in time, this problem would never have appeared. I am wondering why the renowned Debian Advanded Package Manager (i.e. apt) failed to detect the incompatibility. Perhaps eglibc should have had a Breaks: libgcc1 (<< 4.6.0-12)? Could someone confirm my theory? Could someone investigate why libgcc1 has not migrated into testing yet? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20110627t173234-...@post.gmane.org
Bug#631817: libgcc1: missing link libgccc_s.so -> libgcc_s.so.1
Pedro Larroy wrote: > l /lib/x86_64-linux-gnu/libgcc_s.so.1 > ls: cannot access /lib/x86_64-linux-gnu/libgcc_s.so.1: No such file or > directory > > l /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/ > ls: cannot access /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/: > No such file or directory [...] > ii gcc-4.6 4.6.0-10 Further research indicates that the version of gcc-4.6 currently in testing is not yet multiarch-aware; the first version with multiarch was 4.6.0-12; the latest version is 4.6.0-14. It should have migrated to testing five days ago but hasn't. The reasons are unclear; the PTS says the package is out of date on powerpc but the build succeeded on 2011-06-18. Could someone please allow 4.6.0-14 to migrate? Pedro, could you please try to reproduce the problem with gcc-4.6 (=4.6.0-14)? (i.e. install it manually with dpkg, or update your system to sid, or create a sid chroot) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4680651ef6405c03c2708606869b7725@localhost
Bug#631817: libgcc1: missing link libgccc_s.so -> libgcc_s.so.1
reassign 631627 gcc-4.6 reassign 631817 gcc-4.6 severity 631817 grave merge 631627 631817 clone 631627 -1 reassign -1 gcc-4.4 thanks Pedro Larroy writes: > The link libgccc_s.so -> libgcc_s.so.1 is missing in /lib so link > fails when this library is needed This link is not supposed to be in libgcc1 (run-time package) but in gcc-4.6 (build-time package). It seems that the transition to multilib introduced this bug. Could you please tell me whether these two files exist on your system: on amd64: /lib/x86_64-linux-gnu/libgcc_s.so.1 (provided by package libgcc1) /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/libgcc_s.so (provided by package gcc-4.6) on i386: /lib/i386-linux-gnu/libgcc_s.so.1 (provided by package libgcc1) /usr/lib/i386-linux-gnu/gcc/i486-linux-gnu/4.6/libgcc_s.so (provided by package gcc-4.6) And please tell us what libgcc_s.so points to exactly. I suspect that one of these paths are wrong, or the symlink is wrong, or the compiler driver looks in the wrong place. The same problem exists with gcc-4.4; cloning this bug accordingly. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ba0f9e3212d3c92edd73f8ba2ce98470@localhost
Bug#631627: Gnat on Debian testing not working any more
Erik Pessers writes: > Dear all, > > Today I resynced a Debian (testing) PC (apt-get update -t testing). > > After the upgrading, Gnat Ada compiler no longer works for me. GCC and > Gnat packages were updated, and now when trying to run gnatmake I get > errors on the linking step: > >$ gnatmake test_cli > gnatbind -x test_cli.ali > gnatlink test_cli.ali > /usr/bin/ld: cannot find -lgcc_s > collect2: ld returned 1 exit status > gnatlink: error when calling /usr/bin/gcc-4.4 > gnatmake: *** link failed. > > > /usr/lib/gcc/x64-linux/4.4 directories seem to be purged; > replaced by /usr/lib/gcc/x64-linux-gnu/4.6 and ../4.6.1 > > libgcc_s.so is on the system, but in the new > /usr/lib/gcc/x64-linux-gnu/4.6 directories. > > Debian packages installed are now: > > gnat_4.4+1.1_amd64.deb > gcc_4%3a4.6.0-5_amd64.deb > > Any advice? This looks like http://bugs.debian.org/631627 filed yesterday against gcc, so it is probably common to all languages :( I think instances of the bug are in both gcc-4.4 (affecting gnat) and gcc-4.6 (affecting gcc). I've CC'd the bug report. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uyge9ka@ludovic-brenta.org
Re: Upgrading gcc-4.6-source from 4.6.0-2 to 4.6.0-4: +45.2 MiB???
Matthias Klose writes: > On 04/22/2011 11:20 AM, Ludovic Brenta wrote: >> Hello, >> >> I see in aptitude: >> >>--\ Versions of gcc-4.6-source (2) >> id 4.6.0-2 -60.1 MB >> pi 4.6.0-4 +105 MB >> >> Why the big difference? Is this intentional? > > welcome working with a .0 GCC release ;-P I assume new po files, but > diffstat may be more precise. OK, I had a better look and it seems this is all due to: $ ll -S debian/patches/ | head -n 4 total 45340 -rw-r--r-- 1 lbrenta lbrenta 22634086 2011-04-22T13:41:48 svn-updates.diff -rw-r--r-- 1 lbrenta lbrenta 22379153 2011-04-22T13:41:47 gcc-linaro.diff -rw-r--r-- 1 lbrenta lbrenta 456638 2011-04-22T13:41:47 svn-updates-linaro.diff -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zknijl6u@ludovic-brenta.org
Upgrading gcc-4.6-source from 4.6.0-2 to 4.6.0-4: +45.2 MiB???
Hello, I see in aptitude: --\ Versions of gcc-4.6-source (2) id 4.6.0-2 -60.1 MB pi 4.6.0-4 +105 MB Why the big difference? Is this intentional? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o5qlk1r@ludovic-brenta.org
Is m68k-allow-gnu99.diff still needed?
I am confused by the history of this patch: - created on 2008-07-05 in the gcc-4.3 branch by doko - converted to quilt and updated several times on the gcc-4.4 branch - removed on 2010-06-16 in the gcc-4.4 branch by doko (rev 4510), or perhaps renamed to gcc-m68k-support-for-tls-backport.diff? Commit message was: * Add M68K TLS support, backport from the 4.5 branch. Closes: #586060. - it is still present however in the gcc-4.5 and gcc-4.6 branches, where it has been refreshed a couple of times and is still being applied (by rules.patch). Is this patch still needed in GCC 4.5 and 4.6? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkopsbzz@ludovic-brenta.org
