Bug#451707: D should send foo[] as a foo* when used in a variadic argument in extern(C) context
forwarded 451707 http://d.puremagic.com/issues/show_bug.cgi?id=1679 thanks Got the same issue with dmd, reported upstream. Arthur. signature.asc Description: Digital signature
Bug#456596: Please upload gcc-defaults 1.62
reassign 456596 gcc-defaults 1.61
thanks
Matthias,
Here is the diff against current SVN I already sent you.
Cheers,
Arthur.
From 3c86dc3d32b0570aa29e8b8e7dfd9bd69f186b02 Mon Sep 17 00:00:00 2001
From: Arthur Loiret <[EMAIL PROTECTED]>
Date: Sun, 16 Dec 2007 23:40:33 +0100
Subject: [PATCH] Add gdc to gcc-defaults.
---
gcc-defaults/debian/README.Debian|6 +++-
gcc-defaults/debian/README.Debian.m4 |6 +++-
gcc-defaults/debian/changelog|3 ++
gcc-defaults/debian/control | 10
gcc-defaults/debian/rules| 39 +-
5 files changed, 59 insertions(+), 5 deletions(-)
diff --git a/gcc-defaults/debian/README.Debian b/gcc-defaults/debian/README.Debian
index 712ba92..de418c4 100644
--- a/gcc-defaults/debian/README.Debian
+++ b/gcc-defaults/debian/README.Debian
@@ -67,6 +67,7 @@ The default compiler versions for Debian GNU/Linux on i386 are
gobjc++ : gobjc++-4.2
gnat : gnat-4.2
gpc : gpc-4.1
+ gdc : gdc-4.1
Most of the documentation for GCC including the manual pages is
licensed under the GFDL and therefore not included in the main section.
@@ -155,8 +156,8 @@ Maintainers of these packages
Matthias Klose <[EMAIL PROTECTED]>
Ray Dassen <[EMAIL PROTECTED]>
Philip Blundell <[EMAIL PROTECTED]> (arm-linux)
-Jeff Bailey <[EMAIL PROTECTED]> (hurd-i386)
-Joel Baker <[EMAIL PROTECTED]> (netbsd-i386)
+Jeff Bailey <[EMAIL PROTECTED]> (hurd-i386)
+Joel Baker <[EMAIL PROTECTED]> (netbsd-i386)
Ben Collins <[EMAIL PROTECTED]> (sparc-linux)
Falk Hueffner <[EMAIL PROTECTED]> (alpha-linux)
Randolph Chung <[EMAIL PROTECTED]> (ia64-linux, hppa-linux)
@@ -165,6 +166,7 @@ Dan Jacobowitz <[EMAIL PROTECTED]> (powerpc-linux)
Gerhard Tonn <[EMAIL PROTECTED]> (s390-linux)
Roman Zippel <[EMAIL PROTECTED]> (m68k-linux)
Ludovic Brenta <[EMAIL PROTECTED]> (gnat)
+Arthur Loiret <[EMAIL PROTECTED]> (gdc)
===
diff --git a/gcc-defaults/debian/README.Debian.m4 b/gcc-defaults/debian/README.Debian.m4
index 4eb5178..05c0b8d 100644
--- a/gcc-defaults/debian/README.Debian.m4
+++ b/gcc-defaults/debian/README.Debian.m4
@@ -72,6 +72,7 @@ ifenabled(`gobjc',` gobjc : gobjc-PV_GOBJC')
ifenabled(`gobjc++',` gobjc++ : gobjc++-PV_GOBJCXX')
ifenabled(`gnat',` gnat : gnat-PV_GCC')
ifenabled(`gpc',` gpc : gpc-PV_GPC')
+ifenabled(`gdc',` gdc : gdc-PV_GDC')
ifenabled(`chill',` chill : chill-PV_CHILL')
ifdef(`GFDL',`dnl
@@ -172,8 +173,8 @@ Maintainers of these packages
Matthias Klose <[EMAIL PROTECTED]>
Ray Dassen <[EMAIL PROTECTED]>
Philip Blundell <[EMAIL PROTECTED]> (arm-linux)
-Jeff Bailey <[EMAIL PROTECTED]> (hurd-i386)
-Joel Baker <[EMAIL PROTECTED]> (netbsd-i386)
+Jeff Bailey <[EMAIL PROTECTED]> (hurd-i386)
+Joel Baker <[EMAIL PROTECTED]> (netbsd-i386)
Ben Collins <[EMAIL PROTECTED]> (sparc-linux)
Falk Hueffner <[EMAIL PROTECTED]> (alpha-linux)
Randolph Chung <[EMAIL PROTECTED]> (ia64-linux, hppa-linux)
@@ -182,6 +183,7 @@ Dan Jacobowitz <[EMAIL PROTECTED]> (powerpc-linux)
Gerhard Tonn <[EMAIL PROTECTED]> (s390-linux)
Roman Zippel <[EMAIL PROTECTED]> (m68k-linux)
Ludovic Brenta <[EMAIL PROTECTED]> (gnat)
+Arthur Loiret <[EMAIL PROTECTED]> (gdc)
===
diff --git a/gcc-defaults/debian/changelog b/gcc-defaults/debian/changelog
index 4428b10..59e22b4 100644
--- a/gcc-defaults/debian/changelog
+++ b/gcc-defaults/debian/changelog
@@ -8,6 +8,9 @@ gcc-defaults (1.62) unstable; urgency=low
[Ludovic Brenta]
* Make gnat-4.2 the default (instead of gnat-4.1).
+ [Arthur Loiret]
+ * Add gdc, make gdc-4.1 the default.
+
-- Matthias Klose <[EMAIL PROTECTED]> Fri, 19 Oct 2007 12:39:43 +0200
gcc-defaults (1.61) unstable; urgency=medium
diff --git a/gcc-defaults/debian/control b/gcc-defaults/debian/control
index f78c351..fc84a56 100644
--- a/gcc-defaults/debian/control
+++ b/gcc-defaults/debian/control
@@ -238,3 +238,13 @@ Description: The GNU Ada compiler
This is a dependency package providing the default GNU Ada compiler.
Per policy, all packages that contain Ada sources must use this package
in their Build-Depends line.
+
+Package: gdc
+Priority: optional
+Architecture: any
+Depends: gdc-${pv:gdc} ${reqv:gdc}
+Replaces: gdc-4.1 (<< 0.25-4.1.2-18)
+Description: The D compiler
+ This is a dependency package providing the default D compiler.
+ Per policy, all packages that contain D sources must use this package
+ in their Build-Depends line.
diff --git a/gcc-defaults/debian/rules b/gcc-defaults/debian/rules
index a49bb4a..9e99c79 100755
--- a/gcc-defaults/debian/
Bug#456596: Non-maintainer upload.
diff -Nru /tmp/z2bNG5yT2j/gcc-defaults-1.61/debian/changelog
/tmp/eh3mQ9ni2v/gcc-defaults-1.61.1/debian/changelog
--- /tmp/z2bNG5yT2j/gcc-defaults-1.61/debian/changelog 2007-09-04
02:41:56.0 +0200
+++ /tmp/eh3mQ9ni2v/gcc-defaults-1.61.1/debian/changelog2007-12-19
10:17:55.0 +0100
@@ -1,3 +1,10 @@
+gcc-defaults (1.61.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add gdc, make gdc-4.1 the default. Closes: #456596
+
+ -- Arthur Loiret <[EMAIL PROTECTED]> Wed, 19 Dec 2007 10:17:51 +0100
+
gcc-defaults (1.61) unstable; urgency=medium
* libgcj-common: Update classmap db's for gcj-4.3 as well.
diff -Nru /tmp/z2bNG5yT2j/gcc-defaults-1.61/debian/control
/tmp/eh3mQ9ni2v/gcc-defaults-1.61.1/debian/control
--- /tmp/z2bNG5yT2j/gcc-defaults-1.61/debian/control2007-09-03
00:12:53.0 +0200
+++ /tmp/eh3mQ9ni2v/gcc-defaults-1.61.1/debian/control 2007-12-19
10:00:31.0 +0100
@@ -238,3 +238,13 @@
This is a dependency package providing the default GNU Ada compiler.
Per policy, all packages that contain Ada sources must use this package
in their Build-Depends line.
+
+Package: gdc
+Priority: optional
+Architecture: any
+Depends: gdc-${pv:gdc} ${reqv:gdc}
+Replaces: gdc-4.1 (<< 0.25-4.1.2-18)
+Description: The D compiler
+ This is a dependency package providing the default D compiler.
+ Per policy, all packages that contain D sources must use this package
+ in their Build-Depends line.
diff -Nru /tmp/z2bNG5yT2j/gcc-defaults-1.61/debian/README.Debian
/tmp/eh3mQ9ni2v/gcc-defaults-1.61.1/debian/README.Debian
--- /tmp/z2bNG5yT2j/gcc-defaults-1.61/debian/README.Debian 2007-09-01
12:05:15.0 +0200
+++ /tmp/eh3mQ9ni2v/gcc-defaults-1.61.1/debian/README.Debian2007-12-19
10:08:47.0 +0100
@@ -67,6 +67,7 @@
gobjc++ : gobjc++-4.2
gnat: gnat-4.2
gpc : gpc-2.1-3.4
+ gdc : gdc-4.1
Most of the documentation for GCC including the manual pages is
licensed under the GFDL and therefore not included in the main section.
@@ -155,8 +156,8 @@
Matthias Klose <[EMAIL PROTECTED]>
Ray Dassen <[EMAIL PROTECTED]>
Philip Blundell <[EMAIL PROTECTED]>(arm-linux)
-Jeff Bailey <[EMAIL PROTECTED]>(hurd-i386)
-Joel Baker <[EMAIL PROTECTED]> (netbsd-i386)
+Jeff Bailey <[EMAIL PROTECTED]>(hurd-i386)
+Joel Baker <[EMAIL PROTECTED]> (netbsd-i386)
Ben Collins <[EMAIL PROTECTED]>(sparc-linux)
Falk Hueffner <[EMAIL PROTECTED]> (alpha-linux)
Randolph Chung <[EMAIL PROTECTED]> (ia64-linux, hppa-linux)
@@ -165,6 +166,7 @@
Gerhard Tonn <[EMAIL PROTECTED]> (s390-linux)
Roman Zippel <[EMAIL PROTECTED]> (m68k-linux)
Ludovic Brenta <[EMAIL PROTECTED]> (gnat)
+Arthur Loiret <[EMAIL PROTECTED]> (gdc)
===
diff -Nru /tmp/z2bNG5yT2j/gcc-defaults-1.61/debian/README.Debian.m4
/tmp/eh3mQ9ni2v/gcc-defaults-1.61.1/debian/README.Debian.m4
--- /tmp/z2bNG5yT2j/gcc-defaults-1.61/debian/README.Debian.m4 2006-08-14
00:05:29.0 +0200
+++ /tmp/eh3mQ9ni2v/gcc-defaults-1.61.1/debian/README.Debian.m4 2007-12-19
09:59:30.0 +0100
@@ -72,6 +72,7 @@
ifenabled(`gobjc++',` gobjc++ : gobjc++-PV_GOBJCXX')
ifenabled(`gnat',` gnat: gnat-PV_GCC')
ifenabled(`gpc',` gpc : gpc-PV_GPC')
+ifenabled(`gdc',` gdc : gdc-PV_GDC')
ifenabled(`chill',`chill : chill-PV_CHILL')
ifdef(`GFDL',`dnl
@@ -172,8 +173,8 @@
Matthias Klose <[EMAIL PROTECTED]>
Ray Dassen <[EMAIL PROTECTED]>
Philip Blundell <[EMAIL PROTECTED]>(arm-linux)
-Jeff Bailey <[EMAIL PROTECTED]>(hurd-i386)
-Joel Baker <[EMAIL PROTECTED]> (netbsd-i386)
+Jeff Bailey <[EMAIL PROTECTED]>(hurd-i386)
+Joel Baker <[EMAIL PROTECTED]> (netbsd-i386)
Ben Collins <[EMAIL PROTECTED]>(sparc-linux)
Falk Hueffner <[EMAIL PROTECTED]> (alpha-linux)
Randolph Chung <[EMAIL PROTECTED]> (ia64-linux, hppa-linux)
@@ -182,6 +183,7 @@
Gerhard Tonn <[EMAIL PROTECTED]> (s390-linux)
Roman Zippel <[EMAIL PROTECTED]> (m68k-linux)
Ludovic Brenta <[EMAIL PROTECTED]> (gnat)
+Arthur Loiret <[EMAIL PROTECTED]> (gdc)
===
diff -Nru /tmp/z2bNG5yT2j/gcc-defaults-1.61/debian/rules
/tmp/eh3mQ9ni2v/gcc-defaults-1.61.1/debian/r
Bug#473167: string concatenation segfaults
reassign 473167 gdc-4.1 thanks Yes, this is a ppc-specific issue, thanks for reporting. Arthur. signature.asc Description: Digital signature
Bug#474049: Please support MIPS triarch.
Package: libffi
Version: 3.0.4-2
Severity: wishlist
Tags: patch
This patch adds biarchn32 support, and adds mips/mipsel to biarch64 and
biarchn32 archs. Also Updates gcc-multilib Build-Depends for mips/mipsel.
Thanks,
Arthur.
From acbaf5d46eebb9cf5c172294e783660301a4fc2b Mon Sep 17 00:00:00 2001
From: Arthur Loiret <[EMAIL PROTECTED]>
Date: Thu, 3 Apr 2008 01:19:13 +0200
Subject: [PATCH] Support MIPS triarch.
---
debian/control | 27 +--
debian/rules | 62 ---
2 files changed, 78 insertions(+), 11 deletions(-)
diff --git a/debian/control b/debian/control
index 39ea093..2b49cb0 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: libffi
Priority: extra
Maintainer: Debian GCC Maintainers
Uploaders: Matthias Klose <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 5), gcc-multilib [amd64 i386 powerpc ppc64 s390 sparc kfreebsd-amd64], dejagnu, lsb-release, texinfo
+Build-Depends: debhelper (>= 5), gcc-multilib [amd64 i386 mips mipsel powerpc ppc64 s390 sparc kfreebsd-amd64], dejagnu, lsb-release, texinfo
Standards-Version: 3.7.3
Section: libs
@@ -32,7 +32,7 @@ Description: Foreign Function Interface library (development files, 32bit)
Package: lib64ffi-dev
Section: libdevel
-Architecture: i386 powerpc sparc s390
+Architecture: i386 mips mipsel powerpc sparc s390
Depends: libffi-dev (= ${binary:Version}), lib64ffi5 (= ${binary:Version})
Description: Foreign Function Interface library (development files, 64bit)
This package contains the headers and static library files necessary for
@@ -42,6 +42,18 @@ Description: Foreign Function Interface library (development files, 64bit)
allows code written in one language to call code written in another
language.
+Package: libn32ffi-dev
+Section: libdevel
+Architecture: mips mipsel
+Depends: libffi-dev (= ${binary:Version}), libn32ffi5 (= ${binary:Version})
+Description: Foreign Function Interface library (development files, n32)
+ This package contains the headers and static library files necessary for
+ building programs which use libffi.
+ .
+ A foreign function interface is the popular name for the interface that
+ allows code written in one language to call code written in another
+ language.
+
Package: libffi5
Section: libs
Architecture: any
@@ -62,13 +74,22 @@ Description: Foreign Function Interface library runtime (32bit)
Package: lib64ffi5
Section: libs
-Architecture: i386 powerpc sparc s390
+Architecture: i386 mips mipsel powerpc sparc s390
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Foreign Function Interface library runtime (64bit)
A foreign function interface is the popular name for the interface that
allows code written in one language to call code written in another
language.
+Package: libn32ffi5
+Section: libs
+Architecture: mips mipsel
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Foreign Function Interface library runtime (n32)
+ A foreign function interface is the popular name for the interface that
+ allows code written in one language to call code written in another
+ language.
+
Package: libffi5-dbg
Section: libdevel
Architecture: any
diff --git a/debian/rules b/debian/rules
index 0aa443e..a60abe6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,16 +15,24 @@ ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
with_check = yes
endif
-ifneq (,$(filter $(DEB_HOST_ARCH), i386 powerpc s390 sparc))
+ifneq (,$(filter $(DEB_HOST_ARCH), i386 mips mipsel powerpc s390 sparc))
multiarch += biarch64
+ m64 = -m64
endif
ifneq (,$(filter $(DEB_HOST_ARCH), amd64 kfreebsd-amd64 ppc64))
multiarch += biarch32
+ m32 = -m32
+endif
+
+ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
+ multiarch += biarchn32
+ m64 = -mabi=64
+ mn32 = -mabi=n32
endif
biarch_map := i486=x86_64 powerpc=powerpc64 sparc=sparc64 s390=s390x \
-x86_64=i486 powerpc64=powerpc
+x86_64=i486 powerpc64=powerpc mips=mips64 mipsel=mips64el
biarch_cpu := $(patsubst $(DEB_HOST_GNU_CPU)=%,%, \
$(filter $(DEB_HOST_GNU_CPU)=%,$(biarch_map)))
biarch_gnu_type := $(subst $(DEB_HOST_GNU_CPU),$(biarch_cpu),$(DEB_HOST_GNU_TYPE))
@@ -57,7 +65,7 @@ stamp-configure-biarch32:
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
- CC="gcc -m32" CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs $(LDFLAGS)"
+ CC="gcc $(m32)" CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs $(LDFLAGS)"
touch $@
stamp-configure-biarch64:
@@ -70,7 +78,20 @@ stamp-configure-biarch64:
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
- CC="gcc -m64" CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs $(LDFLAGS)"
+ CC="gcc $(m64)" CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs $(LDFLAGS)"
+ touch $@
+
Bug#474049: Please support MIPS triarch.
Oups, forgot to add .install files. It just needs a symbol files update now.
From 54bde15a1efb9cde5933ffaeb1e2fb9b74f9fb2e Mon Sep 17 00:00:00 2001
From: Arthur Loiret <[EMAIL PROTECTED]>
Date: Thu, 3 Apr 2008 01:19:13 +0200
Subject: [PATCH] Support MIPS triarch.
---
debian/control | 27 --
debian/libn32ffi-dev.install |3 ++
debian/libn32ffi5.install|1 +
debian/rules | 62 -
4 files changed, 82 insertions(+), 11 deletions(-)
create mode 100644 debian/libn32ffi-dev.install
create mode 100644 debian/libn32ffi5.install
diff --git a/debian/control b/debian/control
index 39ea093..2b49cb0 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: libffi
Priority: extra
Maintainer: Debian GCC Maintainers
Uploaders: Matthias Klose <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 5), gcc-multilib [amd64 i386 powerpc ppc64 s390 sparc kfreebsd-amd64], dejagnu, lsb-release, texinfo
+Build-Depends: debhelper (>= 5), gcc-multilib [amd64 i386 mips mipsel powerpc ppc64 s390 sparc kfreebsd-amd64], dejagnu, lsb-release, texinfo
Standards-Version: 3.7.3
Section: libs
@@ -32,7 +32,7 @@ Description: Foreign Function Interface library (development files, 32bit)
Package: lib64ffi-dev
Section: libdevel
-Architecture: i386 powerpc sparc s390
+Architecture: i386 mips mipsel powerpc sparc s390
Depends: libffi-dev (= ${binary:Version}), lib64ffi5 (= ${binary:Version})
Description: Foreign Function Interface library (development files, 64bit)
This package contains the headers and static library files necessary for
@@ -42,6 +42,18 @@ Description: Foreign Function Interface library (development files, 64bit)
allows code written in one language to call code written in another
language.
+Package: libn32ffi-dev
+Section: libdevel
+Architecture: mips mipsel
+Depends: libffi-dev (= ${binary:Version}), libn32ffi5 (= ${binary:Version})
+Description: Foreign Function Interface library (development files, n32)
+ This package contains the headers and static library files necessary for
+ building programs which use libffi.
+ .
+ A foreign function interface is the popular name for the interface that
+ allows code written in one language to call code written in another
+ language.
+
Package: libffi5
Section: libs
Architecture: any
@@ -62,13 +74,22 @@ Description: Foreign Function Interface library runtime (32bit)
Package: lib64ffi5
Section: libs
-Architecture: i386 powerpc sparc s390
+Architecture: i386 mips mipsel powerpc sparc s390
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Foreign Function Interface library runtime (64bit)
A foreign function interface is the popular name for the interface that
allows code written in one language to call code written in another
language.
+Package: libn32ffi5
+Section: libs
+Architecture: mips mipsel
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Foreign Function Interface library runtime (n32)
+ A foreign function interface is the popular name for the interface that
+ allows code written in one language to call code written in another
+ language.
+
Package: libffi5-dbg
Section: libdevel
Architecture: any
diff --git a/debian/libn32ffi-dev.install b/debian/libn32ffi-dev.install
new file mode 100644
index 000..490918d
--- /dev/null
+++ b/debian/libn32ffi-dev.install
@@ -0,0 +1,3 @@
+usr/lib32/lib*.a
+usr/lib32/lib*.so
+usr/lib32/pkgconfig/*
diff --git a/debian/libn32ffi5.install b/debian/libn32ffi5.install
new file mode 100644
index 000..d962822
--- /dev/null
+++ b/debian/libn32ffi5.install
@@ -0,0 +1 @@
+usr/lib32/lib*.so.*
diff --git a/debian/rules b/debian/rules
index 0aa443e..a60abe6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,16 +15,24 @@ ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
with_check = yes
endif
-ifneq (,$(filter $(DEB_HOST_ARCH), i386 powerpc s390 sparc))
+ifneq (,$(filter $(DEB_HOST_ARCH), i386 mips mipsel powerpc s390 sparc))
multiarch += biarch64
+ m64 = -m64
endif
ifneq (,$(filter $(DEB_HOST_ARCH), amd64 kfreebsd-amd64 ppc64))
multiarch += biarch32
+ m32 = -m32
+endif
+
+ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
+ multiarch += biarchn32
+ m64 = -mabi=64
+ mn32 = -mabi=n32
endif
biarch_map := i486=x86_64 powerpc=powerpc64 sparc=sparc64 s390=s390x \
-x86_64=i486 powerpc64=powerpc
+x86_64=i486 powerpc64=powerpc mips=mips64 mipsel=mips64el
biarch_cpu := $(patsubst $(DEB_HOST_GNU_CPU)=%,%, \
$(filter $(DEB_HOST_GNU_CPU)=%,$(biarch_map)))
biarch_gnu_type := $(subst $(DEB_HOST_GNU_CPU),$(biarch_cpu),$(DEB_HOST_GNU_TYPE))
@@ -57,7 +65,7 @@ stamp-configure-biarch32:
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
- CC="gcc -m32" CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs $(LDFLAGS)"
+ CC="gcc $(m32)" C
Bug#476088: gcc-4.3-spu: spu-gcc fails to create executable due to missing crt1.o
severity normal
thanks
Install newlib-spu or add -nostdlib if you want to link without spu libc. I'll
add newlib-spu to gcc-4.3-spu's Recommends.
On Mon, Apr 14, 2008 at 02:32:36PM +0200, Adrian Knoth wrote:
> Package: gcc-4.3-spu
> Version: 4.3.0-3
> Severity: grave
> Justification: renders package unusable
>
>
> spu-gcc cannot produce executables. It also misses the system include
> dir:
>
> [EMAIL PROTECTED]:~$ cat spu_hello.c
> #include
>
> int main( unsigned long spuid )
> {
> printf("Hello, World! (From SPU:%d)\n",spuid);
> return (0);
> }
>
> [EMAIL PROTECTED]:~$ spu-gcc spu_hello.c -o spu_hello
> spu_hello.c:1:19: error: stdio.h: No such file or directory
> spu_hello.c: In function 'main':
> spu_hello.c:5: warning: incompatible implicit declaration of built-in
> function 'printf'
>
> [EMAIL PROTECTED]:~$ spu-gcc -I/usr/include spu_hello.c -o spu_hello
> /usr/bin/spu-ld: crt1.o: No such file: No such file or directory
> collect2: ld returned 1 exit status
>
> [EMAIL PROTECTED]:~$ dpkg -L gcc-4.3-spu | grep crt1
> [EMAIL PROTECTED]:~$ echo $?
> 1
>
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: FTBFSes with gdc and Sparc
reopen 461101 reassign 461101 gcc-defaults found 461101 1.69 retitle 461101 gdc should not be built on sparc severity 461101 normal merge 461101 475857 475863 475864 475865 475866 475867 475869 thanks gdc is not broken on sparc, there is just no D runtime lib on sparc yet. gdc-4.1 and gdc-4.2 will still be built on sparc, but gdc won't be built anymore in gcc-defaults on it. On Tue, Apr 15, 2008 at 11:45:55PM +0200, Gonéri Le Bouder wrote: > severity 475857 normal > severity 475863 normal > severity 475864 normal > severity 475865 normal > severity 475866 normal > severity 475867 normal > severity 475869 normal > thanks > > Hi, > > libphobos-XXX-dev contains the standard header files used by gdc. This package > doesn't exist yet on Sparc and so gdc can't build D program (#461101). > > Instead of keeping a broken gdc package in Debian, wouldn't be more > simple and logic to remove sparc from its supported arch list? > > Cheers, > > Gonéri signature.asc Description: Digital signature
Re: FTBFSes with gdc and Sparc
On Wed, Apr 16, 2008 at 12:30:28AM +0200, Gonéri Le Bouder wrote: > > gdc is not broken on sparc, there is just no D runtime lib on sparc yet. > gdc on sparc has a different behaviour and doesn't react as expect for > most of the users. Having a build dependency on it is a problem. For the > moment, I think, the best is to remove sparc from the supported Arch for > all these packages. I would have preferred to see gdc renamed to > emphasize the difference between sparc gdc and the others. > > > gdc-4.1 and gdc-4.2 will still be built on sparc, but gdc won't be built > > anymore in gcc-defaults on it. > Sorry, I don't this the point with the sparc problem. `gdc' is a "default" and almost empty package provided by gcc-defaults, which Depends on the default gdc version, gdc-4.1 for now. Then if you Build-Depends on `gdc' it will install `gdc-4.1' and its deps, with /usr/bin/gdc pointing to /usr/bin/gdc-4.1 (same for gdmd). If `gdc' from gcc-defaults is not built anymore on sparc, packages Build-Depending on it will FTBFS on sparc because they won't be able to install `gdc'. But people will still be able to install `gdc-4.1' and use /usr/bin/gdc-4.1 for D devel on sparc (for tango for example). signature.asc Description: Digital signature
Bug#476645: gcc-4.2: -m32 switch broken?
On Fri, Apr 18, 2008 at 09:28:56AM +0200, Friedrich wrote: > gcc-4.2 -m32 hello.c > /usr/bin/ld: skipping incompatible > /usr/lib/gcc/x86_64-linux-gnu/4.2.3/libgcc_s.so when searching for -lgcc_s > /usr/bin/ld: skipping incompatible > /usr/lib/gcc/x86_64-linux-gnu/4.2.3/libgcc_s.so when searching for -lgcc_s > /usr/bin/ld: cannot find -lgcc_s > collect2: ld gab 1 als Ende-Status zurück Is gcc-4.2-multilib installed? signature.asc Description: Digital signature
Bug#476645: multilib is installed also
It works here in an up-to-date sid chroot: % gcc-4.2 -m32 hello.c && file a.out a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped Please give me the result of: % dpkg -l gcc gcc-4.2 gcc-multilib gcc-4.2-multilib % ls -l /usr/lib/gcc/x86_64-linux-gnu/4.2.3/32/ signature.asc Description: Digital signature
Bug#476812: gcc-defaults: FTBFS (ppc64): Please add 'ppc64' to the architecture lines of the gnat/libgnat* packages.
On Sat, Apr 19, 2008 at 03:55:49PM +0200, Ludovic Brenta wrote: > Index: debian/changelog > === > --- debian/changelog(révision 3018) > +++ debian/changelog(copie de travail) > @@ -1,3 +1,11 @@ > +gcc-defaults (1.71) unstable; urgency=low > + > + [Ludovic Brenta] > + * Do not build gnat on ppc64 until such time as gnat-4.3 is available > +on this architecture. Closes: #476812. > + > + -- Ludovic Brenta <[EMAIL PROTECTED]> Sat, 19 Apr 2008 15:47:50 +0200 > + > gcc-defaults (1.70) unstable; urgency=low > >[Matthias Klose] > Index: debian/rules > === > --- debian/rules(révision 3018) > +++ debian/rules(copie de travail) > @@ -256,6 +256,10 @@ > no_packages += gcc-spu g++-spu gfortran-spu > endif > > +ifeq (,$(filter $(DEB_HOST_ARCH),ppc64)) > +no_packages += gnat > +endif > + > ifeq ($(DEB_HOST_ARCH),s390) > endif > Why not libgnatvsn-dev and libgnatprj-dev as well? signature.asc Description: Digital signature
Bug#476812: gcc-defaults: FTBFS (ppc64): Please add 'ppc64' to the architecture lines of the gnat/libgnat* packages.
On Sat, Apr 19, 2008 at 04:49:35PM +0200, Arthur Loiret wrote: > Why not libgnatvsn-dev and libgnatprj-dev as well? > Oups, didn't see that: ifneq (,$(findstring gnat, $(no_packages))) no_packages += libgnatvsn-dev libgnatprj-dev gnat-doc endif Sorry. signature.asc Description: Digital signature
Bug#476812: gcc-defaults: FTBFS (ppc64): Please add 'ppc64' to the architecture lines of the gnat/libgnat* packages.
On Sat, Apr 19, 2008 at 03:55:49PM +0200, Ludovic Brenta wrote: > Index: debian/rules > === > --- debian/rules(révision 3018) > +++ debian/rules(copie de travail) > @@ -256,6 +256,10 @@ > no_packages += gcc-spu g++-spu gfortran-spu > endif > > +ifeq (,$(filter $(DEB_HOST_ARCH),ppc64)) > +no_packages += gnat > +endif > + > ifeq ($(DEB_HOST_ARCH),s390) > endif > Hope I'm not wrong again... ifeq (,$(filter $(DEB_HOST_ARCH),ppc64)) no_packages += gnat endif You disabled gnat on all archs but ppc64. This should be ifneq. signature.asc Description: Digital signature
Bug#472867: gcc-4.3: gcc regression in optimization (4.2 -> 4.3)
severity 472867 normal thanks On Wed, Mar 26, 2008 at 11:38:53PM +0100, Cyprien LAPLACE wrote: > Severity: grave > Justification: renders package unusable Not that much. > gcc-4.3 forgets some checks in -O2 and -O3, tested on x86_64 and arm > (cross-compiler) targets. Can you please report this upstream ? See http://gcc.gnu.org/bugzilla/ > the following is an exemple code with disassembled generated code by > gcc for 4.2 and 4.3 versions: It is easier to run gcc with -S (compile but don't assemble) than compile and then disassemble the binary. signature.asc Description: Digital signature
Bug#472867: gcc-4.3: gcc regression in optimization (4.2 -> 4.3)
On Sat, May 03, 2008 at 12:05:32PM +0200, Cyprien LAPLACE wrote: >> Can you please report this upstream ? See http://gcc.gnu.org/bugzilla/ >> > I'll need to test it on bare and fresh gnu compiler, which I don't have > right now. I'll compile one. The gcc-4.3 from sid is up-to-date to the gcc-4_3-branch 20080501. So you can report it if you think this is a 4.3 regression. If you want to try from a trunk gcc, just wait for next gcc-snapshot upload which should be 20080502. signature.asc Description: Digital signature
Bug#480203: gcc doesn't compile anything on arm
On Thu, May 08, 2008 at 09:59:18PM +0400, Jan Trofimov wrote: > Package: gcc > Version: 4.3.0-4 > > Im running Debian unstable on FS Pocket Loox 720. And gcc nor 4.3 nor 4.2 > version doesn't compile anything: > > kotoko720:~# uname -a > Linux kotoko720 2.6.21-hh14-128M #44 PREEMPT Sat Sep 22 20:04:17 CEST 2007 > armv5tel GNU/Linux This is not a Debian kernel. Does this also happen with other gcc versions and other distros? I rather suspect a kernel or hardware problem. signature.asc Description: Digital signature
Bug#481403: closed: please reopen!
On Fri, May 16, 2008 at 12:10:28AM +0200, Alexis Huxley wrote:
> Fine, you are right, the package name might be wrong, but the bug exists.
> If I try to install 'gcc' (that should recreate the symlink, right?) then
> I get:
>
> The following extra packages will be installed:
> gcc-4.2
>
> I don't want or need gcc-4.2 therefore the bug exists!
gcc package from gcc-default depends on the default compiler version for a
given arch. gcc-4.2 is the default on i386 so installing gcc will always
install gcc-4.2. gcc Depends on gcc-4.2, and provides /usr/bin/gcc -> gcc-4.2
symlink.
> Could you possibly, if it is not too much trouble, reopen the bug and
> assign it to the package gcc rather than gcc-4.1, then? I presume you
> can do tha? Or would that be too much trouble? Thank you.
gcc-4.2 is the default on i386, you have to switch back the default compiler
to gcc-4.1 by hand updating /usr/bin/{cpp,gcc,g++} symlinks, etc. But you
don't have to uninstall gcc-4.2.
You perhaps rather want to add a comment on bug #463295 [0] about the compiler
used for kernel build.
[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463295
> PS Such a blase attitude towards bug reports does neither (a) you, nor
>(b) Debian any favours.
I have no time to loose acting like a teletubby on bug reports if the bug
report is wrong, sorry...
signature.asc
Description: Digital signature
Bug#481628: FTBFS on mips/mipsel
Package: libffi
Version: 3.0.5-2
Severity: serious
Tags: patch
Both mips64 (biarch64) and mipsn32 (biarchn32) builds are configure with
--host=mips64-linux-gnu so headers from
debian/libffi-dev/usr/include/$(biarch_gnu_type)
are trying to be moved two times, in debian/lib64ffi-dev/usr/include and
debian/libn32ffi-dev/usr/include/ which fails.
There is also a small typo (s/32n/n32/), this patch fixes the problems.
From 1468a32948c2a04d016b7f4cd0f9c9b9998a7fc9 Mon Sep 17 00:00:00 2001
From: Arthur Loiret <[EMAIL PROTECTED]>
Date: Sat, 17 May 2008 13:37:19 +
Subject: [PATCH] Fix build failure on mips{,el}/triarch due to new multiarch directories.
---
debian/changelog |7 +++
debian/rules |7 ++-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 174fdac..c578def 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libffi (3.0.5-3) unstable; urgency=low
+
+ [ Arthur Loiret ]
+ * Fix build failure on mips{,el}/triarch due to new multiarch directories.
+
+ -- Matthias Klose <[EMAIL PROTECTED]> Sat, 17 May 2008 13:35:12 +
+
libffi (3.0.5-2) unstable; urgency=low
* Install header files in multiarch directories. Closes: #480208.
diff --git a/debian/rules b/debian/rules
index 3f78b6c..3ea18da 100755
--- a/debian/rules
+++ b/debian/rules
@@ -203,10 +203,15 @@ ifneq (,$(filter biarch64, $(multiarch)))
debian/lib64ffi-dev/usr/include/
endif
ifneq (,$(filter biarchn32, $(multiarch)))
- mkdir -p debian/lib32nffi-dev/usr/include/$(biarch_gnu_type)
+ mkdir -p debian/libn32ffi-dev/usr/include/$(biarch_gnu_type)
+ifneq (,$(filter biarch64, $(multiarch)))
+ cp -r debian/lib64ffi-dev/usr/include/$(biarch_gnu_type) \
+ debian/libn32ffi-dev/usr/include/
+else
mv debian/libffi-dev/usr/include/$(biarch_gnu_type) \
debian/libn32ffi-dev/usr/include/
endif
+endif
ifneq (,$(filter biarch32, $(multiarch)))
ifeq ($(DEB_HOST_ARCH),amd64)
--
1.5.5.1
signature.asc
Description: Digital signature
Bug#481628: Acknowledgement (FTBFS on mips/mipsel)
With this patch /usr/include/mips64-linux-gnu/ is installed in both libn32ffi-dev and lib64ffi-dev, please wait for my next patch. signature.asc Description: Digital signature
Bug#481628: Acknowledgement (FTBFS on mips/mipsel)
Hi Thiemo, On Sat, May 17, 2008 at 04:13:20PM +0200, Arthur Loiret wrote: > With this patch /usr/include/mips64-linux-gnu/ is installed in both > libn32ffi-dev and lib64ffi-dev, please wait for my next patch. Here is the diff between header from mips and mips64 builds (it is the same for mips64 and mipsn32). Do you have a comment to make on that? Since the last fully build (3.0.5-1) this is the mips64 version installed in /usr/include/ffi.h, and no other version installed. --- build/include/ffi.h 2008-05-17 14:31:24.0 + +++ build64/include/ffi.h 2008-05-17 14:32:06.0 + @@ -158,9 +158,9 @@ extern ffi_type ffi_type_float; extern ffi_type ffi_type_double; extern ffi_type ffi_type_pointer; -#if 0 +#if 1 extern ffi_type ffi_type_longdouble; #else #define ffi_type_longdouble ffi_type_double #endif @@ -366,9 +366,9 @@ #define FFI_TYPE_VOID 0 #define FFI_TYPE_INT1 #define FFI_TYPE_FLOAT 2 #define FFI_TYPE_DOUBLE 3 -#if 0 +#if 1 #define FFI_TYPE_LONGDOUBLE 4 #else #define FFI_TYPE_LONGDOUBLE FFI_TYPE_DOUBLE #endif signature.asc Description: Digital signature
Bug#481628: libffi-bug
On Tue, May 20, 2008 at 11:26:40PM +0200, Andreas Barth wrote:
> how do we continue here? Is the issue "just" that the headers are being
> moved twice? This bug blocks testing migration of python2.5 and epiphany
> which is a precondition for getting gcc-4.3 and gcc-defaults moved.
The fix in the easy way is very simple, here is a patch. But Thiemo is perhaps
working on a better fix to have unified headers on all mips ABIs. They were
some ABI changes in gcc and "long double" is no longer an alias to "double".
From c3292fa59f608d6162f528c6dc72e300332f0e06 Mon Sep 17 00:00:00 2001
From: Arthur Loiret <[EMAIL PROTECTED]>
Date: Wed, 21 May 2008 09:45:36 +
Subject: [PATCH] * Fix multiarch headers installation on mips{,el}:
- Install ABI O32 headers in /usr/include/mips{,el}-linux-gnu
- Install ABI 64 headers in /usr/include/mips64{,el}-linux-gnuabi64
- Install ABI N32 headers in /usr/include/mips64{,el}-linux-gnuabin32
- This workaround FTBFS. Closes: #481628
* Fix a typo in debian/rules: This is libn32 and not lib32n.
---
debian/changelog | 12
debian/rules | 27 +++
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 174fdac..cef1ab4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+libffi (3.0.5-3) unstable; urgency=low
+
+ [ Arthur Loiret ]
+ * Fix multiarch headers installation on mips{,el}:
+- Install ABI O32 headers in /usr/include/mips{,el}-linux-gnu
+- Install ABI 64 headers in /usr/include/mips64{,el}-linux-gnuabi64
+- Install ABI N32 headers in /usr/include/mips64{,el}-linux-gnuabin32
+- This workaround FTBFS. Closes: #481628
+ * Fix a typo in debian/rules: This is libn32 and not lib32n.
+
+ -- Matthias Klose <[EMAIL PROTECTED]> Wed, 21 May 2008 09:12:51 +
+
libffi (3.0.5-2) unstable; urgency=low
* Install header files in multiarch directories. Closes: #480208.
diff --git a/debian/rules b/debian/rules
index 3f78b6c..bc07f81 100755
--- a/debian/rules
+++ b/debian/rules
@@ -197,15 +197,34 @@ ifneq (,$(filter biarch32, $(multiarch)))
mv debian/libffi-dev/usr/include/$(biarch_gnu_type) \
debian/lib32ffi-dev/usr/include/
endif
-ifneq (,$(filter biarch64, $(multiarch)))
+ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
+ ifneq (,$(filter biarch64, $(multiarch)))
+ mkdir -p debian/lib64ffi-dev/usr/include/
+ mv debian/libffi-dev/usr/include/$(biarch_gnu_type) \
+ debian/lib64ffi-dev/usr/include/$(biarch_cpu)-linux-gnuabi64
+ifneq (,$(filter biarchn32, $(multiarch)))
+ mkdir -p debian/libn32ffi-dev/usr/include/
+ cp -r debian/lib64ffi-dev/usr/include/$(biarch_cpu)-linux-gnuabi64 \
+ debian/libn32ffi-dev/usr/include/$(biarch_cpu)-linux-gnuabin32
+endif
+ else
+ifneq (,$(filter biarchn32, $(multiarch)))
+ mkdir -p debian/libn32ffi-dev/usr/include/
+ mv debian/libffi-dev/usr/include/$(biarch_gnu_type) \
+ debian/libn32ffi-dev/usr/include/$(biarch_cpu)-linux-gnuabin32
+endif
+ endif
+else
+ ifneq (,$(filter biarch64, $(multiarch)))
mkdir -p debian/lib64ffi-dev/usr/include/$(biarch_gnu_type)
mv debian/libffi-dev/usr/include/$(biarch_gnu_type) \
debian/lib64ffi-dev/usr/include/
-endif
-ifneq (,$(filter biarchn32, $(multiarch)))
- mkdir -p debian/lib32nffi-dev/usr/include/$(biarch_gnu_type)
+ endif
+ ifneq (,$(filter biarchn32, $(multiarch)))
+ mkdir -p debian/libn32ffi-dev/usr/include/$(biarch_gnu_type)
mv debian/libffi-dev/usr/include/$(biarch_gnu_type) \
debian/libn32ffi-dev/usr/include/
+ endif
endif
ifneq (,$(filter biarch32, $(multiarch)))
--
1.5.5.1
signature.asc
Description: Digital signature
Bug#482691: gcc-snapshot_20080523-1(unstable/sparc/lebrun): Fails to apply patches
On Sat, May 24, 2008 at 03:53:25PM +0200, Marc 'HE' Brockschmidt wrote: > Package: gcc-snapshot > Version: 20080523-1 > Severity: serious > > Heya, > > Building the snapshot package failed on my buildd when preparing the > sources: > This is because the sparc-biarch patch conflicts with the recent sparc config changes. It will be fixed on next upload. signature.asc Description: Digital signature
Bug#483906: Adding amd64 -> i486 cross compiler
On Mon, Jun 02, 2008 at 07:19:41PM +0100, Hector Oron wrote: > Hello, > > This patch also fixes amd64->i486, plus it includes the above patch for > powerpc. > > Cheers Why do we need cross-compilers between biarched archs ? ``gcc -m32'' on amd64 and ``gcc -m64'' on i386 are fine. Also, please rebase your patch on current SVN. signature.asc Description: Digital signature
Bug#489138: Wrong version info.
Package: gdc-4.1 Version: 0.25-20080616-4.1.2-23 $ gdc-4.1 --version gdc-4.1 (GCC) 4.1.3 20080623 (prerelease gdc 0.25 20080419, using dmd 1.024) (Debian 0.25-20080616-4.1.2-23) This should be 20080616 with dmd 1.30. signature.asc Description: Digital signature
Re: gcc-4.3_4.3.1-9 (as currently found in gcccvs)
On Wed, Aug 06, 2008 at 10:30:56AM +0200, Matthias Klose wrote: > Applying the two fixes for PR middle-end/36691 and PR middle-end/37026 > shows a lot regressions on powerpc (none on i386), which I don't see > when just updating to the current branch. Could somebody try to > reproduce these? Any depending fixes known? > > --- - 2008-08-06 08:23:40.753267000 + > +++ test-summary 2008-08-05 23:30:45.0 + [snip] > +pr36691: > + Fix PR middle-end/36691, wrong code with -fwrapv. > + Why don't you just update the svn-updates patch from the gcc-4_3-branch ? This is bug and regression fixes only, and it sounds better than adding separates patches for fixes already applied to the branch. Do you get the same results with an up-to-date svn-updates patch and others patches from the branch removed ? Arthur signature.asc Description: Digital signature
Bug#493650: gcc-4.3: internal compiler error during "make ARCH=um" of Debian Linux 2.6.25
On Sun, Aug 10, 2008 at 11:19:25PM +1200, Brendon Green wrote: > Attempting to resend the info. in smaller chunks. I will try to send > the sched.i.gz file as a series of attachments (hopefully this is > supported by the bugs.debian.org mailer) It does, please send it. signature.asc Description: Digital signature
Re: New Parma Polyhedra Library packages
Hi Roberto, On Tue, Sep 23, 2008 at 09:42:16PM +0200, Roberto Bagnara wrote: > Matthias Klose wrote: > >Hi, we did need the packages as a build dependency for gcc-snapshot > >(trunk). the testsuite is run, but we don't abort the build on > >errors. see the build logs at http://buildd.debian.org/build.php?pkg=ppl, > > Hi Matthias, > > I have checked the build logs, but `make check' does not seem > to be run. In contrast, `make world' is run into the `doc' > subdirectory: this generates tons of developer references > that I doubt are of any interest to the ordinary user. > If you can let us know which kind of documentation you > want to include in the package, we can advise. > > Concerning tests, I think it is very important that `make check' > is run on each architecture to make sure there are no problems: > perhaps not on every build (since it is a very heavy procedure), > but at least before any release. The testsuite will be run on next upload (0.10~pre27-4) on all architectures. And the generated documentation is in a separated libppl-doc package, so it should be ok. > >current bug reports at http://bugs.debian.org/src:ppl. > > I had a look at them: I have fixed one in CVS (the next PPL 0.10 > snapshot will come in a few days). For the other bug, I have offered help. > > In general, at least for the PPL, reporting the bugs upstream is > the quickest way to have them fixed. Thanks for this! I will try to report Debian bugs upstream from now. > >I hope that Arthur Loiret can provide access to an alpha machine. Note > >that Debian conigures gcc on alpha to include -mieee by default. for > >testing you'll find other gcc versions installed on this machine > >(gcc-4.x). > > Notice that -mieee is not enough: according to the GCC documentation > you need -mieee-with-inexact, and even that is not enough > to obtain full IEEE 754 compliance (see > http://gcc.gnu.org/ml/gcc/2008-09/msg00400.html). > We are testing right now a new configuration procedure that > should be able to detect and work around such bogus implementations of > floats. > > Concerning the access to machines, thanks to FSF Europe we have > access to an Alpha. What we miss, is access to the following: > ia64, hppa, arm, s390, mips, mipsel, sparc (but we have sparc64), > armel, and m68k. The sparc hardware (gcc30) is running a sparc64 kernel with a 32-bit userspace, so you can either run gcc (or gcc -m32) to generate 32-bit code, or gcc -m64 to generate 64-bit code. Both can run on the system, but keep in mind 32-bit is the default. Arthur. signature.asc Description: Digital signature
Bug#499931: gdc-4.2: diff for NMU version 0.25-4.2.4-3.1
On Thu, Oct 02, 2008 at 08:14:31PM +0200, Thomas Viehmann wrote: > tags 499931 + patch pending > thanks > > Dear maintainer, > > I've prepared an NMU for gdc-4.2 (versioned as 0.25-4.2.4-3.1) will > upload provided that it builds correctly. Note that the maintainer > should look into pruning unneeded information from debian/copyright. Please upload. Thanks for your work, Arthur. signature.asc Description: Digital signature
Bug#499746: ppl ftbfs on arm
reopen 499746 found 499746 0.10~pre34-1 thanks Still fails to build. On Wed, Sep 24, 2008 at 08:57:22PM +0200, Roberto Bagnara wrote: > > A new PPL 0.10 snapshot that should fix this problem > is available at > > ftp://ftp.cs.unipr.it/pub/ppl/snapshots/ > signature.asc Description: Digital signature
Results for 4.4.0 20081128 (experimental) (Debian 4.4-20081128-1) testsuite on mips-unknown-linux-gnu
LAST_UPDATED: Obtained from SVN: trunk revision 142264 Target: mips-linux-gnu gcc version 4.4.0 20081128 (experimental) (Debian 4.4-20081128-1) Native configuration is mips-unknown-linux-gnu === g++ tests === Running target unix FAIL: g++.dg/ipa/iinline-1.C scan-ipa-dump inline "String::funcOne[^\\n]*inline copy in int main" === g++ Summary === # of expected passes18643 # of unexpected failures1 # of expected failures 135 # of unsupported tests 151 /home/arthur/gcc-4.4/gcc-4.4-4.4-20081128/build/gcc/testsuite/g++/../../g++ version 4.4.0 20081128 (experimental) (Debian 4.4-20081128-1) === gcc tests === Running target unix WARNING: program timed out. FAIL: gcc.dg/20020425-1.c (test for excess errors) FAIL: gcc.dg/ia64-sync-1.c execution test FAIL: gcc.dg/ia64-sync-2.c execution test FAIL: gcc.dg/pr35729.c scan-rtl-dump-times loop2_invariant "Decided to move invariant" 0 FAIL: gcc.dg/pr37106-1.c (internal compiler error) FAIL: gcc.dg/pr37106-1.c (test for excess errors) FAIL: gcc.dg/pr37908.c execution test FAIL: gcc.dg/sync-2.c execution test FAIL: gcc.dg/sync-3.c execution test FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 35) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 36) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 37) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 38) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 39) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 40) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 41) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 42) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 43) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 44) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 45) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 46) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 47) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 48) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 49) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 50) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 52) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 53) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 54) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 55) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 56) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 57) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 58) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 59) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 60) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 61) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 62) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 63) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 64) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 65) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 66) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 67) FAIL: gcc.dg/fixed-point/composite-type.c (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -O0 -g -I. (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -O0 -g assembly comparison FAIL: gcc.dg/pch/valid-1b.c -O0 -I. (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -O0 assembly comparison FAIL: gcc.dg/pch/valid-1b.c -O1 -I. (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -O1 assembly comparison FAIL: gcc.dg/pch/valid-1b.c -O2 -I. (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -O2 assembly comparison FAIL: gcc.dg/pch/valid-1b.c -O3 -fomit-frame-pointer -I. (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -O3 -fomit-frame-pointer assembly comparison FAIL: gcc.dg/pch/valid-1b.c -O3 -g -I. (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -O3 -g assembly comparison FAIL: gcc.dg/pch/valid-1b.c -Os -I. (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -Os assembly comparison FAIL: gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized "conststaticvariable" 1 FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp1 "[xy][^ ]* !=" 0 FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times dom1 "x[^ ]* & y" 1 FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp1 "x[^ ]* [|] y" 1 FAIL: gcc.target/mips/atomic-memory-1.c (test for excess errors) FAIL: gcc.target/mips/cache-1.c scan-assembler \\tcache\\t0x14,0(\$4) FAIL: gcc.target/mips/cache-1.c scan-assembler \\tcache\\t0x18,20(\$4) FAIL: gcc.target/mips/cache-1.c scan-assembler \\tcache\\t0x0,0(\$.) F
Results for 4.4.0 20081121 (experimental) (Debian 4.4-20081121-1) testsuite on mips-unknown-linux-gnu
LAST_UPDATED: Obtained from SVN: trunk revision 142103 Target: mips-linux-gnu gcc version 4.4.0 20081121 (experimental) (Debian 4.4-20081121-1) Native configuration is mips-unknown-linux-gnu === g++ tests === Running target unix FAIL: g++.dg/ipa/iinline-1.C scan-ipa-dump inline "String::funcOne[^\\n]*inline copy in int main" === g++ Summary === # of expected passes18637 # of unexpected failures1 # of expected failures 135 # of unsupported tests 151 /home/arthur/gcc-4.4/gcc-4.4-4.4-20081121/build/gcc/testsuite/g++/../../g++ version 4.4.0 20081121 (experimental) (Debian 4.4-20081121-1) === gcc tests === Running target unix WARNING: program timed out. FAIL: gcc.dg/20020425-1.c (test for excess errors) FAIL: gcc.dg/ia64-sync-1.c execution test FAIL: gcc.dg/ia64-sync-2.c execution test FAIL: gcc.dg/pr35729.c scan-rtl-dump-times loop2_invariant "Decided to move invariant" 0 FAIL: gcc.dg/pr37106-1.c (internal compiler error) FAIL: gcc.dg/pr37106-1.c (test for excess errors) FAIL: gcc.dg/pr37908.c execution test FAIL: gcc.dg/sync-2.c execution test FAIL: gcc.dg/sync-3.c execution test FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 35) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 36) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 37) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 38) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 39) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 40) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 41) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 42) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 43) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 44) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 45) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 46) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 47) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 48) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 49) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 50) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 52) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 53) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 54) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 55) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 56) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 57) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 58) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 59) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 60) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 61) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 62) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 63) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 64) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 65) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 66) FAIL: gcc.dg/fixed-point/composite-type.c (test for errors, line 67) FAIL: gcc.dg/fixed-point/composite-type.c (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -O0 -g -I. (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -O0 -g assembly comparison FAIL: gcc.dg/pch/valid-1b.c -O0 -I. (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -O0 assembly comparison FAIL: gcc.dg/pch/valid-1b.c -O1 -I. (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -O1 assembly comparison FAIL: gcc.dg/pch/valid-1b.c -O2 -I. (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -O2 assembly comparison FAIL: gcc.dg/pch/valid-1b.c -O3 -fomit-frame-pointer -I. (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -O3 -fomit-frame-pointer assembly comparison FAIL: gcc.dg/pch/valid-1b.c -O3 -g -I. (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -O3 -g assembly comparison FAIL: gcc.dg/pch/valid-1b.c -Os -I. (test for excess errors) FAIL: gcc.dg/pch/valid-1b.c -Os assembly comparison FAIL: gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized "conststaticvariable" 1 FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp1 "[xy][^ ]* !=" 0 FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times dom1 "x[^ ]* & y" 1 FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp1 "x[^ ]* [|] y" 1 FAIL: gcc.target/mips/atomic-memory-1.c (test for excess errors) FAIL: gcc.target/mips/cache-1.c scan-assembler \\tcache\\t0x14,0(\$4) FAIL: gcc.target/mips/cache-1.c scan-assembler \\tcache\\t0x18,20(\$4) FAIL: gcc.target/mips/cache-1.c scan-assembler \\tcache\\t0x0,0(\$.) F
Bug#504684: Fixed in GCC 4.4
retitle 504684 [Fixed in 4.4] gcc-4.3: __attribute__((const)) breaks __attribute__((warn_unused_result)) thanks The bug is fixed in GCC 4.4 from trunk. signature.asc Description: Digital signature
Bug#504684: Forwarded upstream
forwarded 504684 http://gcc.gnu.org/PR38560 thanks signature.asc Description: Digital signature
Bug#504684: Oups, wrong bug...
notforwarded 504684 forwarded 502283 http://gcc.gnu.org/PR38560 thanks signature.asc Description: Digital signature
Bug#510616: gcc-4.3: gcc 4.3 is *very* slow on some files
tags 510616 + unreproductible thanks On Sat, Jan 03, 2009 at 08:32:20PM +0100, Hramrach wrote: > Compiling the attached file takes ~10s with gcc 4.2 and ~ 6min with gcc > 4.3 > > Most people would think the compiler has lockued up already. > > gcc-4.3 -O2 -g -Wall -Wno-parentheses -o parse.o -c parse_.c Unable to reproduce on i386, amd64 and alpha with this gcc version. Can you send the gcc-4.3 --version output and the following md5 checksums ? $ md5sum /usr/bin/gcc-4.3 /usr/lib/gcc/*-linux-gnu/4.3*/cc1 Thanks. signature.asc Description: Digital signature
Making GCC 4.3 the default on alpha
Hi! Since Debian version 4.3.3-2, gcc-4.3 has a fix for PR middle-end/38969 [0], which, added to some more fixes committed to the gcc-4_3-branch or backported from trunk, made it suitable enough to build glibc on alpha. We are now planning to make it the default version on alpha, do you have any objection about this? [0] http://gcc.gnu.org/PR38969 Thanks, Arthur. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522597: gcc-4.4: [cross] s390|armel|*) FTBFS cross compiler (posible all arches can affected)
Probably my fault, I'll have a look. Thanks for reporting. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523655: gcc-4.3: error: unrecognizable insn on alpha using -O3 and -std=c99
Hi, 2009/4/11, Kurt Roeckx : > I've attached a reduced test case that gives a simular error message: Awesome! Thanks, I'll forward it upstream. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523655: gcc-4.3: error: unrecognizable insn on alpha using -O3 and -std=c99
2009/4/11, Kurt Roeckx : >> Awesome! Thanks, I'll forward it upstream. > > I've already done that. Then please send the forwarded command to the BTS. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523869: libffi-dev: gcc doesn't find ffi.h
Hi, 2009/4/13, Nick Lewycky : > It seems that libffi-dev puts ffi.h in a target-specific directory on each > platform. For example, on my system it's in /usr/include/i486-linux-gnu/ > which > is a directory that is used by absolutely no other package in Debian. > > Notably, gcc doesn't look there. As such, the program "#include " > doesn't compile. I'm an author for an upstream program that uses libffi, and > I can't write a autoconf script to detect ffi.h if it's not in some sort of > standard place. GCC from Debian *does* look there, which GCC version are you using? Arthur. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523869: libffi-dev: gcc doesn't find ffi.h
Right. This is a recent regression, from 4.3.3-7 upload. The multiarch patch has been changed and seems to be off. I'll have a look, thanks for reporting! Arthur. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#527537: Broken library search paths
Thanks for your report. I'm trying to have this fixed asap. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#527537: Broken library search paths
The missing dir separator has been added, the fix is in our svn. Now a few comments about your bug report: 2009/5/8, Goswin Brederlow : > # Broken path. Missing a '/'? Yes, fixed. > * Duplicate entry after canonicalize Not an issue. > ! Path for the wrong target Not an issue as long as the 32-bit paths are before the other paths. > "/lib/x86_64-linux-gnu" is missing. > "/lib/i486-linux-gnu" is missing. No they're not. We have never wanted them. > "/lib64", "/usr/lib64" could also > be considered missing, they would be needed when running Debian gcc on > SuSe/RH for example. I'm all for binary compatibility (where reasonable) across distros, But using a non-native (ie. from an other distro) toolchain as the main toolchain is a very bad idea. > And for a horrendiously broken example: > > --[ gcc-4.4 -uclibc --print-search-dirs ]- > /usr/lib/gcc/x86_64-linux-gnu/4.4.0/ > /usr/lib/gcc/x86_64-linux-gnu/4.4.0/ > /usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/4.4.0/ > /usr/x86_64-linux-gnu/lib/ > /usr/lib/x86_64-linux-gnu/4.4.0/ > /usr/lib/ > /lib/x86_64-linux-gnu/4.4.0/ > /lib/ > /usr/lib/x86_64-linux-gnu/4.4.0/ > /usr/lib/ > /usr/lib/x86_64-linux-gnux86_64-linux-gnu/4.4.0/ > /usr/lib/x86_64-linux-gnu../lib/ > /usr/x86_64-linux-gnu/lib/ > /usr/lib/ > /lib/ > /usr/lib/ > /usr/lib/x86_64-linux-gnu > > This is all wrong. I think the -uclibc option should be completly > disabled in the default specs file. It even links against the wrong C > library: > > % gcc-4.4 -uclibc -o foo foo.c > % ldd foo > libc.so.6 => /lib/libc.so.6 (0x2b2710aaa000) > /lib64/ld-linux-x86-64.so.2 (0x2b271088c000) > > Seems 100% broken. Nothing related to the multiarch support. We don't support uclibc. If you want to send a feature request, please send a separated bug report, and make a patch. > PS: I haven't checked the include paths. I hope you didn't break them > with the new multiarch patch. They are fine. If you think they're not, please send a patch. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#542794: Test case
Hi!
Thanks for your test case. Could you please try again with
gcc-4.5/libgomp1 from experimental?
Thanks!
Arthur.
2009/8/21, Ole Laursen :
> Hi!
>
> Forgot to attach a test case. It's really simple. Install
> python-vipscc and run the following (and also attached) Python script:
>
> from vipsCC import *
>
> im = VImage.VImage("thisdoesnotexist.png")
> print im.Xsize()
>
> When you open and use a non-existing image file, it segfaults. The
> expected result is a Python exception (this used to work). I'm on
> Debian testing i386. The backtrace goes like this:
>
> #0 0xb6bc54fd in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6
> #1 0xb79e50f6 in vips::verror () from /usr/lib/libvipsCC.so.15
> #2 0xb79cc4cc in vips::VImage::VImage () from /usr/lib/libvipsCC.so.15
> #3 0xb7a1b7e2 in ?? ()
>from /usr/lib/python2.5/site-packages/vipsCC/vimagemodule.so
> #4 0x0805d447 in PyObject_Call ()
>
>
> Ole
>
--
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/aanlktinkxnt1p2ado+s1uwg8bgjvacbuw0btu0hti...@mail.gmail.com
Bug#551188: "libgomp: Thread creation failed" after stack size limit increase
tag 551188 + unreproducible thanks Hi! I can't reproduce your bug. Does it still occur, and if yes, have you tried on an other machine? Thanks! Arthur. 2009/10/16, Delian Krustev : > Package: libgomp1 > Version: 4.4.1-4 > Severity: normal > > $ ulimit -a > pre > $ convert -geometry 90x68 -quality 100 city.jpg city_thumb.jpg > $ echo $? > 0 > $ ulimit -s 195312 > $ convert -geometry 90x68 -quality 100 city.jpg city_thumb.jpg > > libgomp: Thread creation failed: Resource temporarily unavailable > $ echo $? > 1 > $ ulimit -a > after > $ diff -u pre after > --- pre 2009-10-16 15:02:46.0 +0300 > +++ after 2009-10-16 15:02:39.0 +0300 > @@ -9,8 +9,8 @@ > pipe size(512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > -stack size (kbytes, -s) 8192 > +stack size (kbytes, -s) 195312 > cpu time (seconds, -t) unlimited > max user processes (-u) unlimited > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > > It appears that libgomp fails with higher stack size limitations. > > The bug might also be in how convert uses the library, but it seems more > likely to be in libgomp. > > Package: imagemagick > Version: 7:6.5.5.3-1 > > -- System Information: > Debian Release: squeeze/sid > APT prefers testing > APT policy: (900, 'testing'), (900, 'stable'), (800, 'unstable') > Architecture: i386 (i686) > > Kernel: Linux 2.6.30-1-686-bigmem (SMP w/4 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > > Versions of packages libgomp1 depends on: > ii gcc-4.4-base 4.4.1-4The GNU Compiler Collection > (base > ii libc6 2.9-25 GNU C Library: Shared libraries > > libgomp1 recommends no packages. > > libgomp1 suggests no packages. > > -- no debconf information > > > > -- > To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > > -- 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/aanlktimpdbz3s=wsyqgou77emzwsut_4bwp=6no-b...@mail.gmail.com
Re: freeze exception for gcc-4.5 (i386, amd64 only)
Hello, 2010/8/20, Neil McGovern : > I don't think that stable is the place for doing active development. Are you saying that we are developing an operating system which is not suitable for active development, or that it shouldn't be made suitable for active development? If it's the former, I think you should consider we have software developers among our users, which are *not* Debian developers. Hence, following the fourth point of our social contract (Our priorities are our users and free software), we should improve our operating system to please those users. If it's the latter, then, please try to avoid making your personal opinion fail to compile with our social contract. Also, although I really don't know how common this is, I know people who use stable for active development, by obligation. Now, to be clear, what nice things would gcc-4.5 bring to our users? There is a complete list here [0], but those ones are, in my opinion, very nice: - The new link time optimiser. - Improved C++0x support. - Plugins support. Especially the plugins support. It obviously allows to do lots of nice things with the toolchain, which our users should be allowed to do. [0] http://gcc.gnu.org/gcc-4.5/changes.html >> >You mentioned: >> >>- the upload will build several runtime libraries from the 4.5 >> >> sources. Regression tests did pass for the runtime libs built >> >> from the 4.5 sources and for 4.4 using the runtime libs from >> >> 4.5. >> >> This didn't answer my question. "Is there anything more you would expect?" >> > > I was asking for details as to what these actually did. Are they just > "will the binary run?" Of course not, allowing gcc-4.5 on i386 and amd64 asks much more tests. Here are a few which have been done, but Matthias can probably expend the list: - General testsuite regressions: it means the binaries run fine. - More important: testsuite regressions in the runtime libraries. - Still about the runtime libraries: using them for real, by using for example OpenOffice.org. All those tests went fine, and more details about them, or explanations about what needed to be tested and why, can be sent if required. This is only a personal opinion, but I think we have compelling reasons to have gcc-4.5 in Squeeze (improvements for our users), and that it has been conscientiously tested (see above). What else makes you feel it shouldn't be allowed? If you have more questions, please just ask them. Finally, thanks a lot for the time you spent on this issue. I hope this mail doesn't seem rude to you, this of course isn't intentional at all. Arthur. -- 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/aanlktikoye9+_mdcpaxpnllmmdiwab-sosksfepwd...@mail.gmail.com
Re: freeze exception for gcc-4.5 (i386, amd64 only)
2010/8/20, Ludovic Brenta : > Arthur Loiret writes: >> Are you saying that we are developing an operating system which is not >> suitable for active development, or that it shouldn't be made suitable >> for active development? > > I think he meant that stable is not the place for active development of > the operating system and I agree with that. > > Like I said earlier, the presence of gcc-4.5 in Squeeze does not bother > me. What bothers me is replacing some core libraries like libgcc1 and > libstdc++ with versions from gcc-4.5. There is no regression in the runtime libraries tests, and they run very fine with our current testing distribution. You can try by yourself if you don't believe so. >> Also, although I really don't know how common this is, I know people >> who use stable for active development, by obligation. > > OK, then they use the stable compiler, by obligation :) > > gcc-4.5 is not stable: it is in experimental and has not even reached > unstable yet. > > gcc-4.4 is stable. Upstream GCC version 4.5.0 has been released in mid april, and GCC 4.5.1 has less serious regression than GCC 4.4.4. Please explain why do you think gcc-4.5 isn't stable. >> Now, to be clear, what nice things would gcc-4.5 bring to our users? > > Right: gcc-4.5 is "nice to have", maybe even "very, very nice to have", > but it does not fix any RC bugs and _might_ introduce some due to > replacing important libraries from gcc-4.4. So, I support the release > manager's decision not to include gcc-4.5 in Squeeze. Same thing again: it has been tested and works well. I understand your bad feeling about this, but it has no reason to be. Arthur. -- 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/aanlkti=xohjlyjj6tk=kvagpwuhcftpzw1mscxs-e...@mail.gmail.com
Re: freeze exception for gcc-4.5 (i386, amd64 only)
2010/8/23, Pierre Habouzit : > It's just that LTO isn't that a compelling reason, it's not 100% > production ready. The plugin infrastructure is though. But you're citing > dragonegg, and last time I checked, you had to patch gcc to export one > more symbol. If you haven't applied that patch (if it's still required) > your argument is moot. But I agree the plugin infrastructure *is* a > compelling reason. dragonegg doesn't need to patch GCC anymore. Plus there is a "2.7" release. Arthur. -- 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/aanlktimeko3vrkon_1e=xq-9lv4umrw=fqqwtbips...@mail.gmail.com
Bug#556790: Reduced testcase from libssh2
Hi,
Here is a reduced testcase based on libssh2. I get the ICE with gcc-4.3 -O2
only.
typedef long unsigned int size_t;
typedef struct _LIBSSH2_SESSION LIBSSH2_SESSION;
typedef struct _LIBSSH2_CHANNEL LIBSSH2_CHANNEL;
typedef struct _LIBSSH2_SFTP LIBSSH2_SFTP;
typedef struct _LIBSSH2_SFTP_ATTRIBUTES LIBSSH2_SFTP_ATTRIBUTES;
struct _LIBSSH2_SFTP_ATTRIBUTES { unsigned long flags; };
struct _LIBSSH2_CHANNEL { LIBSSH2_SESSION *session; };
struct _LIBSSH2_SFTP { LIBSSH2_CHANNEL *channel; unsigned char *stat_packet; };
struct _LIBSSH2_SESSION { void *abstract; void *(*alloc)(size_t count, void
**abstract); };
static int sftp_attrsize(const LIBSSH2_SFTP_ATTRIBUTES * attrs) { int attrsize
= 4; if (!attrs) { return attrsize; } if (attrs->flags & 0x0001) if
(attrs->flags & 0x0002) attrsize += 8; if (attrs->flags & 0x0004)
attrsize += 4; if (attrs->flags & 0x0008) attrsize += 8; return attrsize; }
static int sftp_stat(LIBSSH2_SFTP *sftp, const char *path, unsigned int
path_len, int stat_type, LIBSSH2_SFTP_ATTRIBUTES * attrs) { LIBSSH2_CHANNEL
*channel = sftp->channel; LIBSSH2_SESSION *session = channel->session;
sftp->stat_packet = session->alloc((sftp_attrsize(attrs)),
&(session)->abstract); }
libssh2_sftp_stat_ex(LIBSSH2_SFTP *sftp, const char *path, unsigned int
path_len, int stat_type, LIBSSH2_SFTP_ATTRIBUTES *attrs) { int rc;
BLOCK_ADJUST(rc, sftp->channel->session, sftp_stat(sftp, path, path_len,
stat_type, attrs)); }
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#551088: gfortran-4.4: Segmentation fault of various fortran programs with OpenMP
Hi, Thanks for your bug report. Can you provide a minimal testcase, ie the simplest fie possible for which the bug is triggered? Thanks! Arthur. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546443: sh4: please add "/usr/include/sh4-linux-gnu" to include search path.
The mapping is missing in gcc/multiarch.h (see debian/patches/gcc-multiarch.inc). What is the corresponding GNU triplet to m4-nofpu (it seems to be sh4-linux-gnu for m4)? Arthur. 2010/1/5, Nobuhiro Iwamatsu : > reopen 546443 > thanks > > Hi, > > This bug is not yet revised. > sh4 becomes the build error only by having applied a patch of multi-arch. > > http://buildd.debian-ports.org/fetch.php?pkg=gcc-4.4&arch=sh4&ver=4.4.2-8&stamp=1262100902&file=log&as=raw > > sh4 sets multilib which supported m4 and m4-nofpu for a kernel compile. > Could you check this bug? > > Best regards, > Nobuhiro > > -- > Nobuhiro Iwamatsu > > > > -- > To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546443: sh4: please add "/usr/include/sh4-linux-gnu" to include search path.
> Triplet of m4-nofpu is sh4_nofpu-linux-gnu.
> What should I set in src/gcc/multiarch.h?
Something like:
# if defined(__sh4-linux-gnu__)
{ "m4", "sh4-linux-gnu" },
{ "m4-nofpu", "sh4_nofpu-linux-gnu" },
# endif
And then, if it builds, can you paste the include paths and library
paths for both m4/m4-nofpu obtained from gcc -v?
Thanks,
Arthur.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#575322: gcc-snapshot: FTBFS on kfreebsd-i386: s=`cat status`; rm -f status; test $s -eq 0
Hi, The real error is from gnatlib's s-taprop.adb: /build/buildd-gcc-snapshot_20100310-1-kfreebsd-i386-c6zRmm/gcc-snapshot-20100310/build/./gcc/xgcc -B/build/buildd-gcc-snapshot_20100310-1-kfreebsd-i386-c6zRmm/gcc-snapshot-20100310/build/./gcc/ -B/usr/lib/gcc-snapshot/i486-kfreebsd-gnu/bin/ -B/usr/lib/gcc-snapshot/i486-kfreebsd-gnu/lib/ -isystem /usr/lib/gcc-snapshot/i486-kfreebsd-gnu/include -isystem /usr/lib/gcc-snapshot/i486-kfreebsd-gnu/sys-include-c -g -O2 -fPIC -W -Wall -gnatpg s-taprop.adb -o s-taprop.o libtool: compile: /build/buildd-gcc-snapshot_20100310-1-kfreebsd-i386-c6zRmm/gcc-snapshot-20100310/build/./gcc/xgcc -B/build/buildd-gcc-snapshot_20100310-1-kfreebsd-i386-c6zRmm/gcc-snapshot-20100310/build/./gcc/ -B/usr/lib/gcc-snapshot/i486-kfreebsd-gnu/bin/ -B/usr/lib/gcc-snapshot/i486-kfreebsd-gnu/lib/ -isystem /usr/lib/gcc-snapshot/i486-kfreebsd-gnu/include -isystem /usr/lib/gcc-snapshot/i486-kfreebsd-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libgfortran -iquote../../../src/libgfortran/io -I../../../src/libgfortran/../gcc -I../../../src/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT minval_r10.lo -MD -MP -MF .deps/minval_r10.Tpo -c ../../../src/libgfortran/generated/minval_r10.c -o minval_r10.o >/dev/null 2>&1 s-taprop.adb:716:32: "lwp_self" is undefined make[9]: *** [s-taprop.o] Error 1 Found using "grep Error ...". 2010/3/24, Cyril Brulebois : > Source: gcc-snapshot > Version: 20100310-1 > Severity: important > User: debian-...@lists.debian.org > Usertags: kfreebsd > > Hi, > > your package FTBFS on kfreebsd-i386, apparently right after the > libgfortran part: > | libtool: link: ranlib .libs/libgfortran.a > | libtool: link: ( cd ".libs" && rm -f "libgfortran.la" && ln -s > "../libgfortran.la" "libgfortran.la" ) > | make[5]: Leaving directory > `/build/buildd-gcc-snapshot_20100310-1-kfreebsd-i386-c6zRmm/gcc-snapshot-20100310/build/i486-kfreebsd-gnu/libgfortran' > | make[4]: Leaving directory > `/build/buildd-gcc-snapshot_20100310-1-kfreebsd-i386-c6zRmm/gcc-snapshot-20100310/build/i486-kfreebsd-gnu/libgfortran' > | make[3]: Leaving directory > `/build/buildd-gcc-snapshot_20100310-1-kfreebsd-i386-c6zRmm/gcc-snapshot-20100310/build' > | make[2]: *** [bootstrap-lean] Error 2 > | make[2]: Leaving directory > `/build/buildd-gcc-snapshot_20100310-1-kfreebsd-i386-c6zRmm/gcc-snapshot-20100310/build' > | s=`cat status`; rm -f status; test $s -eq 0 > | make[1]: *** [stamps/05-build-stamp] Error 1 > | make[1]: Leaving directory > `/build/buildd-gcc-snapshot_20100310-1-kfreebsd-i386-c6zRmm/gcc-snapshot-20100310' > | make: *** [stamps/05-build-stamp] Error 2 > > Full build logs: > https://buildd.debian.org/status/package.php?p=gcc-snapshot > > Mraw, > KiBi. > > > > -- > 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/20100324213457.3412.47946.report...@bowmore > > -- 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/dacf4781003250130u55835bcdhe249d349ee7a9...@mail.gmail.com
Bug#430395: gcc-4.2 FTBFS when cross compiling because of wrong config path in binary-libstdcxx-cross.mk
Package: gcc-4.2 Version: 4.2-20070609 Hello, The file libstdc++-v3/config/linker-map.gnu has moved in gcc-4.2 to libstdc++-v3/config/abi/pre/gnu.ver, then I suggest to correct the path in binary-libstdcxx-cross.mk. A simple patch is joined, and I have successfully built gcc-4.2 for several targets with it. Thanks. signature.asc Description: OpenPGP digital signature
Bug#430395: (pas de sujet)
Here is the error I got: cp -p /usr/src/gcc-4.2/gcc-4.2-4.2-20070609/src/libstdc++-v3/config/linker-map.gnu \ debian/libstdc++6-4.2-pic-sparc-cross/usr/lib/gcc/sparc-linux-gnu/4.2.1/libstdc++_pic.map cp: cannot stat `/usr/src/gcc-4.2/gcc-4.2-4.2-20070609/src/libstdc++-v3/config/linker-map.gnu': No such file or directory make[1]: *** [stamps/08-binary-stamp-libstdcxx-dev] Error 1 make[1]: Leaving directory `/usr/src/gcc-4.2/gcc-4.2-4.2-20070609' make: *** [binary] Erreur 2 And here is the patch (I can add a simple test -f if necessary): --- debian/rules.d/binary-libstdcxx-cross.mk2007-06-24 08:27:41.0 + +++ debian/rules.d/binary-libstdcxx-cross.mk2007-06-24 08:12:39.0 + @@ -304,7 +304,7 @@ debian/dh_doclink -p$(p_dev) $(p_lib) debian/dh_doclink -p$(p_pic) $(p_lib) debian/dh_doclink -p$(p_dbg) $(p_lib) - cp -p $(srcdir)/libstdc++-v3/config/linker-map.gnu \ + cp -p $(srcdir)/libstdc++-v3/config/abi/pre/gnu.ver \ $(d_pic)/$(gcc_lib_dir)/libstdc++_pic.map ifeq ($(with_cxxdev),yes) Thanks. --- debian/rules.d/binary-libstdcxx-cross.mk 2007-06-24 08:27:41.0 + +++ debian/rules.d/binary-libstdcxx-cross.mk 2007-06-24 08:12:39.0 + @@ -304,7 +304,7 @@ debian/dh_doclink -p$(p_dev) $(p_lib) debian/dh_doclink -p$(p_pic) $(p_lib) debian/dh_doclink -p$(p_dbg) $(p_lib) - cp -p $(srcdir)/libstdc++-v3/config/linker-map.gnu \ + cp -p $(srcdir)/libstdc++-v3/config/abi/pre/gnu.ver \ $(d_pic)/$(gcc_lib_dir)/libstdc++_pic.map ifeq ($(with_cxxdev),yes) signature.asc Description: OpenPGP digital signature
Bug#433172: error in debian/rules.defs: ssp_no_archs when DEB_CROSS defined can't be used because ssp_no_archs variable is redefined right after
Package: gcc-4.2 Version: 4.2-20070712 Hello, In debian/rules.defs I read ifdef DEB_CROSS ssp_no_archs = arm armel alpha hppa ia64 m68k mips mipsel hurd-i386 endif ssp_no_archs = alpha hppa ia64 m68k mips mipsel hurd-i386 which mean that ssp_no_archs is always the same as it is redefined after. It could be replaced by: ssp_no_archs = alpha hppa ia64 m68k mips mipsel hurd-i386 ifdef DEB_CROSS ssp_no_archs += arm armel endif A patch is joined to this mail. Have a nice day, Arthur. --- rules.defs 2007-07-15 06:04:23.0 + +++ ../debian/rules.defs 2007-07-15 06:14:50.0 + @@ -399,10 +399,10 @@ # libssp --- with_ssp := yes +ssp_no_archs = alpha hppa ia64 m68k mips mipsel hurd-i386 ifdef DEB_CROSS - ssp_no_archs = arm armel alpha hppa ia64 m68k mips mipsel hurd-i386 + ssp_no_archs += arm armel endif -ssp_no_archs = alpha hppa ia64 m68k mips mipsel hurd-i386 ifneq (, $(filter $(DEB_TARGET_ARCH),$(ssp_no_archs))) with_ssp := not available on $(DEB_TARGET_ARCH) endif
Bug#433172: error in debian/rules.defs: ssp_no_archs when DEB_CROSS defined can't be used because ssp_no_archs variable is redefined right after
Hello I wonder, if arm doesn't support ssp at all, as doko said, why should it be disabled only when cross compiling? Is there a specific reason or something ? Thank you for your time, have a nice day. Arthur. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439573: gdc-4.1 - FTBFS: make[3]: *** [all] Error 2
severity 439573 important thanks > No buildd is able to build it. amd64 and i386 was not uploaded from a > buildd, the others failed. You'll find the full amd64 build log here [0], excelsior has been able to build it, and amd64 package has been uploaded from it. [0] http://buildd.debian.org/fetch.cgi?&pkg=gdc-4.1&ver=0.23-4.1.2-15&arch=amd64&stamp=1187917738&file=log -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439573: gdc-4.1 - FTBFS: make[3]: *** [all] Error 2
> 4 errors with exactly the same unusable error message.
you should try to rebuild with DEB_BUILD_OPTIONS=parallel=1 to have
readable logs.
The powerpc build should be fixed on next upload, otherwise upstream
configure script stop build if arch isn't i386, amd64, powerpc or
ppc64.
In src/libphobos/configure.in:
AC_MSG_CHECKING([for fpclassify and signbit])
AC_TRY_COMPILE([
#ifndef fpclassify
static void fpclassify(int x, int y) { }
#endif
#ifndef signbit
static void signbit(int x, int y) { }
#endif
#include ],
[int x = fpclassify(4.2);
int y = signbit(1.1);
int z = FP_NAN + FP_INFINITE + FP_ZERO + FP_SUBNORMAL + FP_NORMAL;],
[AC_MSG_RESULT([yes])
d_have_fpsb=1],
[AC_MSG_RESULT([no])])
case "$d_target_os" in
# use fpmath on Linux
linux*) d_have_fpsb=''
;;
esac
if test -n "$d_have_fpsb"; then
AC_DEFINE(HAVE_FP_CLASSIFY_SIGNBIT,1,[Define to 1 fpclassify and
signbit are available])
D_EXTRA_OBJS="$D_EXTRA_OBJS gcc/cbridge_math.o"
else
case "$target_cpu" in
i*86 ) ;;
powerpc* ) ;;
ppc* ) ;;
x86_64 ) ;;
*) AC_MSG_ERROR([Missing fpclassify and signbit]) ;;
esac
D_EXTRA_OBJS="$D_EXTRA_OBJS internal/fpmath.o"
fi
Then we got this error:
> checking for fpclassify and signbit... yes
> configure: error: Missing fpclassify and signbit
You can remove this test (about line 5702 in src/libphobos/configure)
and see if you are able to link executables from some D sources.
Here is a the classic "hello world" in D so you can investigate on
s390 (or others archs unsupported by upstream):
import std.stdio;
void main() {
writefln("Hello, world!");
return 0;
}
(just test it links fine, there are some issues with fpclassify and
signbit in libphobos and libm, at least on sparc, even if they are not
called in sources here)
Have a nice day,
Arthur.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439836:
tags 439836 + confirmed upstream thanks Thanks for your bug report, reported upstream here: http://sourceforge.net/tracker/index.php?func=detail&aid=1783085&group_id=154306&atid=791252 Have a nice day, Arthur. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443148:
severity 443148 wishlist merge 439573 443148 thanks Hello, gdc is only ported upstream on i386, amd64, powerpc, and on kfreebsd-gnu (will be on next upload), setting severity to wishlist since a port is needed then. main gdc ports bug is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439573 Arthur. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why must libstdc++-dev depend on gcc?
Hello, you might have forgotten to build with DEB_CROSS_INDEPENDENT to also build a cross gcc-4.1-base, see in rules.defs: # when DEB_CROSS_INDEPENDENT is set we build and depend on a # separate -base package for the cross compiler. ifeq ($(DEB_CROSS_INDEPENDENT),yes) with_gccxbase := yes endif Try to build for example with: % DEB_CROSS_INDEPENDENT=yes DEB_CROSS_NO_BIARCH GCC_TARGET=arm fakeroot debian/rules binary DEB_CROSS_INDEPENDENT is not required with gcc-4.2, it has been merged with DEB_CROSS. Arthur. 2007/9/20, Phil Endecott <[EMAIL PROTECTED]>: > Dear Experts, > > It seems that the libstdc++-dev packages depend on a particular version > of gcc/g++, e.g. > > $ dpkg -s libstdc++6-4.1-dev > Package: libstdc++6-4.1-dev > [snip] > Depends: gcc-4.1-base (= 4.1.1-14), g++-4.1 (= 4.1.1-14), libstdc++6 > (>= 4.1.1-14), libc6-dev (>= 2.3.6-7) > > I can understand why g++ would depend on a particular version of > libstdc++, but I'm confused by this dependency in the opposite > direction. Why is it needed? > > In my case, I have a small ARM system (an NSLU2) which runs Debian; I > cross-compile for it from a Debian PC. The ARM system's root > filesystem is visible using NFS from the PC, and the cross-compiler > looks there for include files and libraries. In order to compile C++ > programs I need the include files provided by the libstdc++-dev > package, but I can't install these without also installing the native > compiler, which I don't want. > > Can anyone suggest a work-around? Are these dependencies really necessary? > > > Many thanks for any suggestions. > > Regards, Phil. > > > (P.S. if you Cc: me, I'll see your reply sooner.) > > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why must libstdc++-dev depend on gcc?
> I haven't built anything. I've just tried to "apt-get install
> libstdc++6-4.1-dev" on my NSLU2, and it tells me that I must also
> install g++.
Are you telling me you are going to try to use libstdc++-dev without g++? :-)
Package: libstdc++CXX_SO`'PV-dev`'LS
Depends: BASEDEP, g++`'PV`'TS (= ${gcc:Version}), libstdc++CXX_SO`'LS
(>= ${gcc:Version}), ${dep:libcdev}
libstdc++-dev just depends on g++, you perhaps wanted to install
libstdc++ instead.
Arthur.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why must libstdc++-dev depend on gcc?
2007/9/20, Phil Endecott <[EMAIL PROTECTED]>: > Yes. g++ (cross compiler) is installed on my PC. The PC mounts the > NSLU2's filesystem using NFS. I want to install libstdc++ on the NSLU2 > so that the cross compiler on the PC can use it. I do not plan to use > the native g++ on the NSLU2. This is not the right way to do this, you must get the binary .deb for arm on your PC first (you can use apt-file or go get it on packages.d.o). Then, use dpkg-cross: dpkg-cross -a arm -b libstdc++*-dev-*_arm.deb You'll get an arch indep package, just install it on your PC and you'll get libstdc++ headers in /usr/arm-linux-gnu, your cross-compiler should be able to find them. Arthur. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why must libstdc++-dev depend on gcc?
> Hi Arthur, > > I have used dpkg-cross extensively in the past. I am now trying this > alternative approach, which seems to work well except for libstdc++. > For a typical package X I can simply install X and X-dev on the ARM > system and the cross-compiler will see the includes files. But it does > not work for libstdc++. So, is there a reason why libstdc++-dev must > depend on g++? You're right, libstdc++-dev should perhaps just Recommends g++ since recommended packages will be automatically installed from October 1st. Arthur. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gdc: statically built in libphobos library makes dynamic binaries big
Hello Maddi, 2007/9/21, Matthias 'Maddi' Kopfermann <[EMAIL PROTECTED]>: > Hi, gcc maintainers, > > thanks a lot for doing a debian package for gdc [ d compiler ]. > today i found out that the main libgphobos library is built into > every compiled program which makes even the smallest "hello > world" printing program ~150kb big at my i386 computer because libphobos is > statically built into the compiled program. Right, this is a problem and I've already contacted upstream about make libgphobos a shared lib. > d is very beautiful [ IMO ] but it's a pity to always have > big dynamically compiled programs that way. > > i found this link how to dynamically have a libgphobos > library: > http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=43626 > > Perhaps this could be adapted for the debian gdc package or > as an option for a specific debian package for gdc? I'm going to try this and see, thanks. Arthur. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443744:
tags 443744 + upstream confirmed thanks Reported upstream: http://sourceforge.net/tracker/index.php?func=detail&aid=1800931&group_id=154306&atid=791252 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
