i am concerned that between gcc versions, there are often changes in the
C++ (and maybe others) ABI, and moving all of our packages to the new
version is likely going to be a painful process. If the g++-3.2 ABI is
already frozen (?) and we move directly to it then we may save ourselves
some
While preparing gcc-3.1 packages I noticed many eh-related regressions
fixed in the trunk, when dwarf2 support was added. With Dave's
guidance I made a diff of the pa subdirectory from the trunk and
applied it to the branch. Although many FAILS are gone, there are some
new (diff below).
In
by deneb.enyo.de with local (Exim 3.34 #4)
id 171vWc-0005rb-00; Sun, 28 Apr 2002 22:44:02 +0200
Message-ID: [EMAIL PROTECTED]
From: Florian Weimer [EMAIL PROTECTED]
To: John David Anglin [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: ada/6495: no entities
I still haven't figured out why libstdc++ needs to be installed prior
to running the testsuite.
That's weird... nothing immediately comes to mind.
LD_RUN_PATH in the environment is the culprit.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research
On Fri, Aug 6, 2010 at 11:03 AM, Matthias Klose d...@debian.org wrote:
On 06.08.2010 00:58, brian m. carlson wrote:
On Thu, Aug 05, 2010 at 10:59:18PM +0200, Matthias Klose wrote:
On 08.07.2010 01:42, brian m. carlson wrote:
Package: gcc-4.4
Version: 4.4.4-6
Severity: wishlist
On Wed, Mar 26, 2008 at 10:20:35AM -0600, Grant Grundler wrote:
Another gcc problem report:
That past weekend I built the latest parisc-2.6-25-rc6 kernel from
Kyle's tree using gcc-4.1, gcc-4.2, and gcc-4.3. All three kernels
booted but the networking only worked for gcc-4.1 kernel.
Package: gnat-4.3
Version: 4.3.1-1
Severity: important
The gnat-4.3 package (4.3.1-1) is miscompiled. As a result, building
GCC 4.4.0 from current svn sources failes with a segmentation fault.
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37034 for more
details.
The problem can be corrected
Dave, now that 4.3.1-2 has been built on hppa, could you try to
reproduce the problem?
Yes. At the moment, the 4.4 tree is a mess with a number of issues
affecting hppa. Have to get EH exception support working again.
Given the build history that you showed, I'm somewhat skeptical that
,
What's your opinion on switching to GCC 4.5 for HPPA?
Do it! I have built glibc with it and all my recent kernel have
been with 4.5. I'm not aware of any new issues with 4.5 and a number
of things are fixed.
For kernel builds, the following patch must be included:
2010-12-18 John David Anglin
On 27-Oct-11, at 8:22 AM, Matthias Klose wrote:
fixed in the vcs. please could you check if that's all which needs
fixing? I
currently don't have access to a hppa machine anymore.
Fixed worked. I have built and installed 4.6.2-2 using default 4.6.2
source.
Thanks,
Dave
--
John David
Package: libcloog-ppl-dev
Version: 0.15-2
Severity: normal
In config.log for GCC 4.5, I see the following:
configure:5356: checking for correct version of CLooG
configure:5378: gcc -c -g -O2 conftest.c 5
In file included from conftest.c:12:
/usr/include/cloog/cloog.h:47:30: error:
On 08.11.2009 21:38, John David Anglin wrote:
test results for 4.4.2-1:
http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html
for 4.4.2-2:
http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html
there are some differences, which are not seen in Dave's build
On 08.11.2009 21:38, John David Anglin wrote:
test results for 4.4.2-1:
http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html
for 4.4.2-2:
http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html
there are some differences, which are not seen in Dave's build
On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno aurel...@aurel32.net wrote:
I confirm, it's what I see in the testsuite log:
| 77
| __signbitl
| version status: incompatible
| GLIBCXX_3.4
| type: function
| status: added
If __signbitl is the only failure in the abi_check,
The problem appears to have gone away with head. I don't see it with
hpux.
Note that latest version of gcc 4.4 in Debian is built with
--disable-libstdcxx-pch, but the segfault is this present :(
Personally, I don't believe the segfault is related to the FAILs
seen in the libstdc++
On Sun, Nov 22, 2009 at 2:51 PM, Carlos O'Donell
car...@systemhalted.org wrote:
This happens because the original locale object was created at address
0xbff01c20. However, when apt-get calls std::basic_ioschar,
std::char_traitschar ::init it passes in the address 0xbff01c18.
So we went
On Mon, 23 Nov 2009, Carlos O'Donell wrote:
I can successfully run apt-get with the new libstdc++6 that I just built.
The testsuite result is cleaner:
~~~
FAIL: 29_atomics/atomic_flag/clear/1.c execution test
FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test
no, it's not fakeroot, it's make segfaulting ...
[...]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 16911)]
0x4091fd20 in __canonicalize_funcptr_for_compare () from
/lib/libpthread.so.0
(gdb) bt
#0 0x4091fd20 in
On Sat, Jan 07, 2006 at 01:05:11AM -0800, Steve Langasek wrote:
Grant, thank you for your work to date on this bug. (BTW, it would be
helpful if you would follow up to bug #342545 on libgcc2, instead of bug
#341675 which is filed against just one of the many packages affected by
it).
There isn't a lot of info in #342545. However, I suspect from the
following comment
It would be nice if somebody fluent with hppa assembly can tell us if
fldw -10(,sp),fr23
that this is the same bug as reported here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754.
Changed
the preprocessed source for mpegaudiodec.c?
The problem might have been introduced by this change:
2006-01-10 John David Anglin [EMAIL PROTECTED]
PR target/20754
* pa.md: Create separate 32 and 64-bit move patterns for SI, DI, SF
and DF modes. Add alternatives to copy between general
While investigating gstreamer0.10-ffmpeg's build failure under hppa[1],
I received the following error from gcc:
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../libavutil -DHAVE_AV_CONFIG_H=1 -Wall
-Wno-switch -g -O2 -MT mpegaudiodec.lo -MD -MP -MF .deps/mpegaudiodec.Tpo
-c mpegaudiodec.c
On Sat, Apr 22, 2006 at 10:00:04AM +0200, Matthias Klose wrote:
$ ldd a.out
libstdc++.so.6 =3D /usr/lib/libstdc++.so.6 (0x40575000)
libm.so.6 =3D /lib/libm.so.6 (0x4046e000)
libgcc_s.so.2 =3D /lib/libgcc_s.so.2 (0x40068000)
libc.so.6 =3D /lib/libc.so.6
[EMAIL PROTECTED]:~/gmp-4.2.dfsg/tests/cxx$ g++ -Wall test-throw.cc
./a.out
/usr/bin/ld: warning: libgcc_s.so.4, needed by
/usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so, may conflict with
libgcc_s.so.2
I'm puzzled about this. It seems like libstdc++ for GCC 4.0.3 was
built using
Yes, we do, but
$ ls -l /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so
lrwxr-xr-x 1 root root 23 Apr 6 02:08
/usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so - ../../../libstdc++.so.6
Oh, I was thinking there were separate libraries for each GCC version.
I've had to live with this for some
Is this acutally decided? Is it likely to happen soon, or should I
build GMP with gcc 3.3 (which doesn't exhibit the problem) in the
short term?
For now, I suggest that you remove gcc-4.1 from your build system.
Then, GMP should build fine with 4.0. You might have to reinstall
4.0.
As far
Er, no; we're talking about official Debian packages here, and the
libstdc++.so.6 in Debian is now from gcc-4.1. The problem is precisely that
GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting
in the double libgcc_s problem.
Then, you must build *eveything* for
Ok, coming back to the question of the system compiler on hppa for
etch. Assuming that hppa does want to do that:
- is glibc buildable with gcc-4.1 on hppa?
As far as I know, there's no new problems using 4.1 instead of 4.0. See
Jean-Yves GUILLEVIC writes:
Hello All
does someone knows about libffi2 on Debian HPPA Linux ?
to get a gcj on this port ...
AFAIK nobody has started a port yet.
James Mc Parlane may be working on this. There was a question re calling
conventions back on May 17.
Dave
--
J. David
The following piece of code compiles with gcc-3.0 but not with
gcc-3.2... is this a gcc bug? or is the code broken?
I would say the later.
[EMAIL PROTECTED]:~$ gcc-3.2 -c t.c
t.c: In function `foo':
t.c:12: initializer element is not constant
(it's a simplified example of some code from
In reference to a message from Matthias Klose, dated Mar 01:
Matthias Klose writes:
AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
code due to the changed exception handling (now DWARF2 based). As
libstdc++ in 3.2 and 3.2 have the same soname, how to handle it?
Nice and is it also possible to produce a 64bits version of gcc?
Last time I tried (couple of weeks ago), it was possible to build
a 64-bit cross starting with 3.3. This still doesn't work with 3.2.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research
Randolph Chung writes:
In reference to a message from Matthias Klose, dated Mar 01:
Matthias Klose writes:
AFAIK the transition from 3.2 to 3.3 requires recompilation of C++
code due to the changed exception handling (now DWARF2 based). As
libstdc++ in 3.2 and 3.2 have the same
On Mer, 2003-05-21 at 01:08, Matthew Wilcox wrote:
I'm not sure it's my call to make; I can see arguments on both sides.
Thats at least one of the reasons. Reputation capital is a wonderous
thing. Accept reality, you are the Linus of parisc Linux like it or not
8)
I agree.
Dave
--
J.
On Mon, May 26, 2003 at 10:22:51PM -0700, Randolph Chung wrote:
[EMAIL PROTECTED]:~$ gcc -shared -fPIC -o blah.so blah.c
/tmp/ccC3fZeH.o(.text+0x1c): In function `call_foo':
: undefined reference to `foo'
This should fix it. Would someone mind applying it for me? I'm in
transit at the
On Mon, Jun 02, 2003 at 05:10:38PM -0400, John David Anglin wrote:
tmpdir/sh1p.o(.text+0x0): In function `shlib_mainvar':
/home/dave/binutils-2.14.90/src/ld/testsuite/ld-elfvsb/sh1.c:32: undefined
refer
ence to `mainvar'
...
FAIL: visibility (hidden)
Fixing this one probably
[CC to jda]
Please can you recheck with a current gcc snapshot (from the
gcc-snapshot package) and attach the preprocessed source?
This doesn't appear to be a gcc problem. The register %r3 is saved
on the stack in __stdio_init_file_nothreads. The stack location
is clobbered by the fstat
This doesn't appear to be a gcc problem. The register %r3 is saved
on the stack in __stdio_init_file_nothreads. The stack location
is clobbered by the fstat syscall.
+ {
+struct stat st;
+fstat(fd,st);
At the fstat call we have the following values:
Breakpoint 11,
For some reason, auto-detect isn't working.
Trying to enable multiarch support with --enable-multiarch also fails.
The variable withval is not defined in the configure hunk for --enable-
multiarch.
--
John David Anglin dave.ang...@bell.net
--
To UNSUBSCRIBE, email to debian-gcc
On 30-Mar-12, at 5:09 AM, Matthias Klose wrote:
On 30.03.2012 04:08, John David Anglin wrote:
For some reason, auto-detect isn't working.
Trying to enable multiarch support with --enable-multiarch also
fails.
The variable withval is not defined in the configure hunk for --
enable-multiarch
On 3/30/2012 10:02 AM, Matthias Klose wrote:
we can't ship the tm.texi files
I'm surprised. From what I see, copying of the GCC manual components is
covered by the GNU Free Documentation License,
Version 1.3. It's not very good if the manual can't be shipped.
--
John David Anglin
On 30-Mar-12, at 10:02 AM, Matthias Klose wrote:
I'm not sure what happens.
It didn't happen with a clean source. Testsuite running.
--
John David Anglin dave.ang...@bell.net
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
Seems to be fixed in 4.7.0-4.
--
John David Anglin dave.ang...@bell.net
--
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/blu0-smtp945bdb49911896134e848497
Although undocumented, adding --disable-libatomic to the
configure options in rules2 seems to avoid the error.
Dave
--
John David Anglindave.ang...@bell.net
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
On 27-Mar-13, at 9:29 AM, John David Anglin wrote:
Although undocumented, adding --disable-libatomic to the
configure options in rules2 seems to avoid the error.
I also had the following install issues:
dpkg: error processing gcc-4.8-hppa64_4.8.0-1_hppa.deb (--install):
trying to overwrite
there. Uploaded gcc-4.8 package
set last night.
Dave
--
John David Anglin dave.ang...@bell.net
--
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/blu0
and generation is disabled when PA 8000 scheduling is used (linux and
PA 2.0). Normally, one won't see this on linux.
Dave
--
John David Anglindave.ang...@bell.net
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
On 12-Jul-13, at 1:27 AM, Andrei POPESCU wrote:
Control: reassign -1 src:gcc-4.8 4.8.1-6
On Jo, 11 iul 13, 22:27:55, John David Anglin wrote:
Package: gcc-4.8-hppa64
Version: 4.8.1-6
Severity: important
Hmm, the PTS does show such a binary for gcc-4.8, but p.d.o doesn't.
Reassigning
: Regenerate.
* hooks.c (hook_constcharptr_void_null): New.
* hooks.h (hook_constcharptr_void_null): Declare.
It may be possible to disable this in config.gcc.
Dave
--
John David Anglin dave.ang...@bell.net
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
On 7/16/2013 5:27 AM, Matthias Klose wrote:
Am 15.07.2013 03:26, schrieb John David Anglin:
On 12-Jul-13, at 6:52 AM, Matthias Klose wrote:
I'm not aware of any change in -6 which could have caused that.
It appears the change that exposed the bug was the installation of eglibc
2.17-7
On 16-Jul-13, at 5:27 AM, Matthias Klose wrote:
Am 15.07.2013 03:26, schrieb John David Anglin:
On 12-Jul-13, at 6:52 AM, Matthias Klose wrote:
I'm not aware of any change in -6 which could have caused that.
It appears the change that exposed the bug was the installation of
eglibc 2.17-7
. At least for release
architectures the
alternative is to drop the port unless somebody wants to maintain
the toolchain
for this port. This is the current status, please correct me if I'm
wrong.
- alpha, no feedback, CCing Michael Cree.
- hppa, no feedback, CCing John David Anglin
- ia64
Package: gcj-4.8
Version: 4.8.2-15
Severity: normal
The /usr/bin/gij-4.8 incorrectly executes /usr/bin/gij-4.4.bin.
The script is also duplicated:
dave@mx3210:/usr/bin$ less gij-4.8
#! /bin/sh
prctl=
case $(prctl --unaligned=) in *signal)
echo 2 $(basename $0): ignore unaligned memory
Further, if one does a build outside buildd and then a +b1 inside
buildd, the
results is no longer installable as it depends on a non existent +b1
version
of gnat-4.6-base.
Cheers,
Dave
--
John David Anglin dave.ang...@bell.net
--
To UNSUBSCRIBE, email to debian-gcc-requ
-bit Linux
runtime would yield more benefit than tool chain integration.
Dave
--
John David Anglin dave.ang...@bell.net
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https
Package: gcc-snapshot
Version: 20140423-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
During install, the following error occurs:
for i in ar nm ranlib; do \
cp debian/gcc-$i.1
Package: gcc-4.8
Version: 4.8.3-3
Severity: normal
This problem is specific to GCC 4.8.3-4. The kernel boot failure does
not occur with 4.8.3-3 and earlier.
The boot failure occurs both with the latest Debian 64-bit unstable kernel
and user 64-bit kernel builds:
Hierarchical RCU
Package: gcc-4.9
Version: 4.9.2-5
Severity: normal
gcc-4.9 4.9.2-5 fails to build from source on hppa. See:
http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9arch=hppaver=4.9.2-5stamp=1417599336
r218208 introduced a number of problems including this PR:
Package: gcc-snapshot
Version: 20150211-1
Severity: normal
From build log:
checking for libvtv support... no
checking for hppa-linux-gnu-gcc...
/home/dave/debian/gcc-snapshot/gcc-snapshot-20150211/build/gcc/xg++
-B/home/dave/debian/gcc-snapshot/gcc-snapshot-20150211/build/gcc/
checking for C
With the attached change to debian/rules2, gcc-snapshot builds successfully on
hppa (native build).
DEBIAN_CROSS was not tested.
We now need both a c and c++ compiler to build hppa64. libbacktrace only
builds with c compiler.
Dave
--
John David Anglin dave.ang...@bell.net
gcc
On 2015-06-01 9:24 AM, Matthias Klose wrote:
On 05/30/2015 10:59 PM, John David Anglin wrote:
On 2015-05-29, at 5:18 PM, Matthias Klose wrote:
Anyway, please check if this is the real cause. attaching a hack which should
work around that.
The hack didn't fix build. Here is log:
http
with my own cross although
I didn't try with gcc-5.
Dave
--
John David Anglin dave.ang...@bell.net
--
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/blu436
»'
make: *** [stamps/05-build-hppa64-stamp] Error 2
debian/rules:60: recipe for target 'stamps/05-build-hppa64-stamp' failed
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
Dave
--
John David Anglin dave.ang...@bell.net
--
To UNSUBSCRIBE, email to debian-gcc
Source: gcc-5
Version: 5.1.1-6
Severity: normal
A since 5.1.1-6, gcc-5 no longer builds on hppa:
checking size of long... 0
checking for long long... no
checking for a 64-bit type... unsigned long
checking for intptr_t... no
checking for uintptr_t... no
checking for ssize_t... no
checking for
Package: gcc-5
Version: 5.2.1-17+b1
Severity: normal
Dear Maintainer,
The binutils-hppa64 package was renamed to binutils-hppa64-linux-gnu
but gcc-5 depends on the old name. Probably, it should depend on both
at least for now.
Regards,
Dave
-- System Information:
Debian Release: stretch/sid
Package: gcc-5
Version: 5.2.1-20
Severity: normal
Dear Maintainer,
5.2.1-20 fails to build. Here is relevant part of log:
dh_shlibdeps -pgnat-5
dpkg-shlibdeps: error: couldn't find library libgnat-5.so.1 needed by
debian/gnat-5/usr/bin/gnatfind-5 (ELF format: 'elf32-hppa-linux'; RPATH: '')
Fixed by rebuild of shadow.
Dave
--
John David Anglin dave.ang...@bell.net
Package: src:gcc-4.8
Version: 4.8.5-2
Severity: normal
Dear Maintainer,
The debian control file for gcc-4.8 needs an update. The binutils-hppa64
dependency needs to change to binutils-hppa64-linux-gnu.
Same for gnat-4.9.
Regards,
Dave Anglin
-- Information:
Debian Release: stretch/sid
APT
Package: gcc-5
Version: 5.2.1-24
Severity: normal
Dear Maintainer,
I tried to install libstdc++6-5-dbg:
mx3210:/home/dave# apt-get install libstdc++6-5-dbg libgcc4-dbg
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be
Package: gcc-snapshot
Version: 20170125-1
Severity: normal
Dear Maintainer,
Your package does not build on hppa:
gcc-snapshot build-depends on missing:
- binutils-hppa64:hppa
The dpendency should be on binutils-hppa64-linux-gnu:hppa.
Regards,
Dave Anglin
-- System Information:
Debian
bc.
https://sourceware.org/bugzilla/show_bug.cgi?id=21132
https://sourceware.org/bugzilla/show_bug.cgi?id=21000
https://sourceware.org/bugzilla/show_bug.cgi?id=21131
Until these issues are resolved, the hardening options aren't going to work on
hppa.
Dave
--
John David Anglin dave.ang...@bell.net
Package: gcj-6-jre-headless
Version: 6.2.0-4
Severity: normal
Dear Maintainer,
The /usr/bin/gij-6.bin file/link is not installed on hppa. This causes
vtk6 and libreoffice builds to fail. See for example:
https://buildd.debian.org/status/fetch.php?pkg=libreoffice=hppa=1%3A5.2.1-3=1474103136
r).bin \
$(d_jrehl)/$(PF)/bin/gij$(pkg_ver).bin
endif
Regards,
Dave Anglin
--
John David Anglin dave.ang...@bell.net
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-- no debconf information
2018-01-16 John David Anglin <dang...@gcc.gnu.org>
* config.gcc (hppa*-*-linux*): Change callee copies ABI to caller
copies.
Index: conf
installed now.
--
John David Anglin dave.ang...@bell.net
-- Running using static build
./altmain
OK
Dave
--
John David Anglin dave.ang...@bell.net
On 2018-09-14 7:55 PM, John David Anglin wrote:
With g++-8 8.2.0-6 and its fix for BTS #907586, I was able to build the
nordugrid-arc package in a schroot on the panama porterbox.
Great.
I have committed fix to trunk and gcc-8:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00801.html
Package: libgcc-9-dev
Version: 9.2.1-4
Severity: normal
Dear Maintainer,
The following error occurs running "test-z3 -a" while building the z3 package:
PASS
(test hashtable :time 0.00 :before-memory 2630.62 :after-memory 2630.62)
The futex facility returned an unexpected error code.
make[1]: ***
Source: gcc-9
Version: 9.2.1-15
Severity: normal
Dear Maintainer,
The build failed with the following error:
make[6]: Entering directory '/<>/build/hppa-linux-gnu/libgnatvsn'
/bin/mkdir -p '/<>/debian/tmp/usr/lib/ada/adalib/gnatvsn'
/usr/bin/install -c -m 444 .libs/*.ali
Source: gcc-11
Version: 11.2.0-9
Severity: normal
Dear Maintainer,
Build fails here:
Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/m2/gm2-compiler-boot/M2Version.o differs
Bootstrap comparison failure!
gcc/SYSTEM.o
On 2023-10-12 2:09 a.m., Matthias Klose wrote:
On 07.10.23 21:43, John David Anglin wrote:
This problem seems to have disappeared. Last build of gcc-13 and last couple of
builds of gcc-snapshot
have been successful.
yes, that because of a local patch:
https://salsa.debian.org/toolchain-team
This problem seems to have disappeared. Last build of gcc-13 and last couple
of builds of gcc-snapshot
have been successful.
Dave
--
John David Anglin dave.ang...@bell.net
This bug is not a gcc-12 bug. It is a kernel cache flush or mmap aliasing
issue causing corruption
of anonymous pages.
Bug is random and only seen on PA8800/PA8900 machines.
Latest gcc-12 package is now installed.
--
John David Anglin dave.ang...@bell.net
Hi,
There are two additional updates for libffi on hppa. See:
https://github.com/libffi/libffi/issues/755
https://github.com/libffi/libffi/issues/756
The current installed version (+b2) has the patches for the above issues.
Regards,
Dave Anglin
--
John David Anglin dave.ang...@bell.net
Source: libffi
Version: 3.2.1-9
Severity: normal
Tags: patch
Dear Maintainer,
The following tests fail on hppa:
=== libffi tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using
Source: gcc-snapshot
Version: 1:20230315-1
Severity: normal
Tags: ftbfs
Dear Maintainer,
Build fails with following error:
/<>/build-hppa64/./gcc/xgcc -B/<>/build-hppa64/./gcc/
-B/usr/lib/gcc-snapshot/hppa64-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/hppa64-linux-gnu/lib/ -isystem
for hppa64 installed at this time.
Something seems to have changed in the build mechanism between gcc-12 and
gcc-13.
I have a debian non-buildd build of gcc-13 going. Maybe it will help to find
issue.
--
John David Anglin dave.ang...@bell.net
On 2023-06-14 2:31 p.m., John David Anglin wrote:
On 2023-06-14 1:00 p.m., Matthias Klose wrote:
wondering if configuring with --disable-libgcc would help?
I don't need to do this when building the hppa64 gcc target by itself.
Linux may need libgcc.
I think configure must be finding
Source: gcc-snapshot
Version: 1:20231130-1
Severity: normal
Dear Maintainer,
This is with qemu. All tests fail. For example,
Executing on host: /build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/build/gcc/xg
cc -B/build/gcc-snapshot-qyFUuB/gcc-snapshot-20231130/build/gcc/ /build/gcc-sna
Source: gcc-12
Version: 12.3.0-15
Severity: normal
Dear Maintainer,
In test log, I see a number of tests with following error:
splitting /build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/testsuite/ada/acats1/test
s/a/a26007a.adt into:
a26007a.adb
BUILD a26007a.adb
90 matches
Mail list logo
