Hi,
On 13.10.23 18:55, Simon Richter wrote:
There are a few dependency rules in the file that seem to do the same
thing, but use the wrong target name, so they are ignored, and this
doesn't seem to be a complete set anyway. I'm trying with the same
addition of an order-only depen
Hi,
On 10/13/23 03:03, Simon Richter wrote:
makes the problem reproducible even when building with -j2, and
regardless of whether building _all packages in the same build or not.
I'll check tomorrow about gcc 13 and if that also happens upstream.
gcc 13 is okay, because of 0bfc50
Hi,
On 10/12/23 19:14, Simon Richter wrote:
I cannot reproduce this, and I would rather not investigate time into
that. Please check if you see this with gcc-13 as well.
I suspect it's a missing dependency, so the failure is more dependent on
"number of threads", and that it
Hi,
On 10/12/23 15:17, Matthias Klose wrote:
I cannot reproduce this, and I would rather not investigate time into
that. Please check if you see this with gcc-13 as well.
I suspect it's a missing dependency, so the failure is more dependent on
"number of threads", and that it succeeds for -b
Hi,
this bug is known upstream, and a patch already exists. Would it be
possible to apply this so ghdl can be compiled on arm64?
Simon
Package: gcc-12
Version: 12.3.0-9
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: s...@debian.org
Hi,
I just built arch:all and arch:amd64 packages separately in pbuilder,
and got a reproducible build failure while building amd64 with
--binary-arch. Normal severity because building both arch-dependent
Package: gcc-12
Version: 12.3.0-9
Severity: normal
Tags: upstream
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111704
X-Debbugs-Cc: s...@debian.org
Control: affects -1 = ghdl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
GHDL steps on an ICE while compiling GHDL 3.0.0 on arm64:
Package: g++-10
Version: 10.2.1-6
Severity: minor
Tags: upstream
X-Debbugs-Cc: s...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I have a lot of
/usr/include/wx-3.2/wx/window.h: In member function ‘virtual wxSize
wxWindowBase::GetMinSize() const’:
/usr/include/wx-3.2/wx/windo
Package: gnat-6-powerpc64-linux-gnu
Version: 6.3.0-12cross1
Severity: normal
Hi,
while cross-compiling the Ada portion of libspe2:
powerpc64-linux-gnu-gnatmake -g testsingle.adb
powerpc64-linux-gnu-gnatbind-6 -x testsingle.ali
powerpc64-linux-gnu-gnatlink-6 testsingle.ali -g
powerpc64-linux-gnu-
Package: gcc-6-source
Version: 6.2.0-13
Severity: minor
Hi,
The gdc source archive has a .xz suffix, but is actually gzip
compressed.
$ file /usr/src/gcc-6/gdc-20160822.tar.xz
/usr/src/gcc-6/gdc-20160822.tar.xz: gzip compressed data, last modified: Mon
Aug 22 12:11:49 2016, from Unix
Simon
Package: g++-4.7
Version: 4.7.2-5
Severity: normal
Hi,
the test program
#include
int main(int, char **) { std::locale loc(""); }
gives an error when run under valgrind:
==1792== Invalid read of size 8
==1792==at 0x56E5388: wcscmp (wcscmp.S:464)
==1792==by 0x4EA9554: std::moneypunct::~
Hi,
actually attaching the file helps.
Simon
#include
class interface
{
public:
virtual ~interface(void) throw() { }
};
class implementation :
public interface
{
std::string somedata;
};
Package: libstdc++6-4.5-dev
Version: 4.5-20100227-1
Severity: minor
Hi,
the attached code fails to compile with
test.cpp:11: error: looser throw specifier for ‘virtual
implementation::~implementation()’
test.cpp:6: error: overriding ‘virtual interface::~interface() throw ()’
The reason for t
Hi,
On Sat, Jun 27, 2009 at 09:23:29AM +0300, Modestas Vainius wrote:
> While it is a good idea worth consideration but I think demangled symbol
> names are somewhat too ambiguous to be used in general. See below:
[Examples]
Not a problem IMO -- we need a new package name anyway if gcc's ABI
ch
Hi,
> >, since
> > they have entirely different objectives
> Not entirely different - the objective for the packaging tools is
> actually the same, to have packages install cleanly without changes on
> systems with a different architecture triplet.
I'm not sure this can be achieved at all, as we
Hi,
On Thu, Mar 12, 2009 at 07:54:49PM +0100, Hector Oron wrote:
> > install anything but libraries and headers into /usr/ -- so I
> > don't think there is a pressing need to replicate a filesystem hierarchy
> > standard below a triplet directory.
> That is what GNU people expect when building c
Hi,
On Wed, Mar 11, 2009 at 12:40:39PM +0100, Hector Oron wrote:
> /{include,bin,lib,lib64}
> Mainstream code expects a different layout more LHS compliant,
> /{usr/include,bin,lib,lib64}
"usr/include" looks horribly wrong to me, since it cannot be achieved in a
cross build by changing the -
Package: gcc-4.2
Version: 4.2.1-0
Followup-For: Bug #433172
Hi,
while the patch indeed hides the problem, the real issue seems to be
deeper. Being listed in ssp_no_archs has an effect on the build process
of the bootstrap(!) compiler; my guess is that ARM is listed there
because building a cross
Package: gcj-3.2
Version: 1:3.2.2-0pre5
Severity: wishlist
Hi,
it would be cool if the gcj package somehow made sure that a "jar"
command was available, either by depending on the "fastjar" package or
with a small shell script that calls the Java implementation.
Usually, fastjar is part of the g
On Wed, 18 Apr 2001, Richard Hirst wrote:
> > The idea is to see whether m68k can live without gcc 2.7.2, since we seem
> > to be the last platform depending on it and the maintainer wants to drop
> > the package.
> Oh, sorry - I missed that point. Certainly I've built and run 2.3.x and
> 2.4.x
20 matches
Mail list logo
