Bug#711727: cloog-ppl: please update config.guess/config.sub for arm64
Package: cloog-ppl Version: 0.16.1-1 Severity: normal Tags: patch User: debian-...@lists.debian.org Usertags: arm64 cloog-ppl fails to build on arm64 due to an out-of-date config.guess/config.sub. It actually build-depends on autotools-dev but doesn't seem to use it. Adding the relevant dh_autotools-dev_* commands is enough to fix this. * Use dh_autotools-dev_* to update config.guess/config.sub for arm64. diff -Nru cloog-ppl-0.16.1/debian/rules cloog-ppl-0.16.1/debian/rules --- cloog-ppl-0.16.1/debian/rules 2013-01-28 02:05:00.0 + +++ cloog-ppl-0.16.1/debian/rules 2013-06-09 01:39:07.0 +0100 @@ -18,6 +18,7 @@ configure: configure-stamp configure-stamp: dh_testdir + dh_autotools-dev_updateconfig chmod +x configure # ./configure $(CROSS) \ # --prefix=/usr \ @@ -48,6 +49,7 @@ rm -f *-stamp [ ! -f Makefile ] || $(MAKE) distclean rm -f doc/*.info + dh_autotools-dev_restoreconfig dh_clean install: build Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- 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/20130609010301.gg11...@riva.ucam.org
Bug#698344: libffi: missing autotools support and symbols file for arm64
+===
+--- a/configure.ac
b/configure.ac
+@@ -53,6 +53,10 @@
+
+ TARGETDIR=unknown
+ case $host in
++ aarch64*-*-*)
++ TARGET=AARCH64; TARGETDIR=aarch64
++ ;;
++
+ alpha*-*-*)
+ TARGET=ALPHA; TARGETDIR=alpha;
+ # Support 128-bit long double, changeable via command-line switch.
+@@ -228,6 +232,7 @@
+ AM_CONDITIONAL(POWERPC_AIX, test x$TARGET = xPOWERPC_AIX)
+ AM_CONDITIONAL(POWERPC_DARWIN, test x$TARGET = xPOWERPC_DARWIN)
+ AM_CONDITIONAL(POWERPC_FREEBSD, test x$TARGET = xPOWERPC_FREEBSD)
++AM_CONDITIONAL(AARCH64, test x$TARGET = xAARCH64)
+ AM_CONDITIONAL(ARM, test x$TARGET = xARM)
+ AM_CONDITIONAL(AVR32, test x$TARGET = xAVR32)
+ AM_CONDITIONAL(LIBFFI_CRIS, test x$TARGET = xLIBFFI_CRIS)
+Index: b/configure
+===
+--- a/configure
b/configure
+@@ -649,6 +649,8 @@
+ AVR32_TRUE
+ ARM_FALSE
+ ARM_TRUE
++AARCH64_FALSE
++AARCH64_TRUE
+ POWERPC_FREEBSD_FALSE
+ POWERPC_FREEBSD_TRUE
+ POWERPC_DARWIN_FALSE
+@@ -13128,6 +13130,10 @@
+
+ TARGETDIR=unknown
+ case $host in
++ aarch64*-*-*)
++ TARGET=AARCH64; TARGETDIR=aarch64
++ ;;
++
+ alpha*-*-*)
+ TARGET=ALPHA; TARGETDIR=alpha;
+ # Support 128-bit long double, changeable via command-line switch.
+@@ -13415,6 +13421,14 @@
+ POWERPC_FREEBSD_FALSE=
+ fi
+
++ if test x$TARGET = xAARCH64; then
++ AARCH64_TRUE=
++ AARCH64_FALSE='#'
++else
++ AARCH64_TRUE='#'
++ AARCH64_FALSE=
++fi
++
+ if test x$TARGET = xARM; then
+ ARM_TRUE=
+ ARM_FALSE='#'
+@@ -14799,6 +14813,10 @@
+ as_fn_error $? conditional \POWERPC_FREEBSD\ was never defined.
+ Usually this means the macro was only invoked conditionally. $LINENO 5
+ fi
++if test -z ${AARCH64_TRUE} test -z ${AARCH64_FALSE}; then
++ as_fn_error $? conditional \AARCH64\ was never defined.
++Usually this means the macro was only invoked conditionally. $LINENO 5
++fi
+ if test -z ${ARM_TRUE} test -z ${ARM_FALSE}; then
+ as_fn_error $? conditional \ARM\ was never defined.
+ Usually this means the macro was only invoked conditionally. $LINENO 5
diff -Nru libffi-3.0.11/debian/patches/series
libffi-3.0.11/debian/patches/series
--- libffi-3.0.11/debian/patches/series 2012-10-10 13:12:46.0 +0100
+++ libffi-3.0.11/debian/patches/series 2013-01-17 10:18:13.0 +
@@ -3,3 +3,4 @@
aarch64-libffi.diff
aarch64-libffi-testsuite.diff
aarch64-config.diff
+aarch64-build.diff
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
--
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/20130117104424.gh18...@riva.dynamic.greenend.org.uk
Bug#630006: closed by Matthias Klose d...@debian.org (Bug#630006: fixed in libffi 3.0.9-5)
found 630006 3.0.9-5 found 630006 3.0.10~rc8-3 thanks I'm very sorry, but I missed a bit which caused the new libglib2.0-udeb not to depend on libffi6-udeb even when built against it. Could you apply this as well to fix the shlibs file? diff -u libffi-3.0.10~rc8/debian/rules libffi-3.0.10~rc8/debian/rules --- libffi-3.0.10~rc8/debian/rules +++ libffi-3.0.10~rc8/debian/rules @@ -275,7 +275,8 @@ dh_strip -s --dbg-package=libffi$(major)-dbg dh_compress -s dh_fixperms -s - dh_makeshlibs -s + dh_makeshlibs -plibffi$(major) --add-udeb=libffi$(major)-udeb + dh_makeshlibs -s -Nlibffi$(major) dh_installdeb -s dh_shlibdeps -s dh_gencontrol -s -- Colin Watson [cjwat...@ubuntu.com] -- 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/20110611183920.ga26...@riva.ucam.org
Bug#630006: libffi: please add a udeb
Package: libffi
Version: 3.0.10~rc8-2
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch oneiric
As of GLib 2.29.4, libgobject-2.0.so.0 has a hard dependency on libffi.
Since libgobject is in graphical d-i builds and thus has a udeb, libffi
now needs to have a udeb too. The following patch should be sufficient.
(Noticed because this is currently breaking Ubuntu d-i builds.)
* Add libffi6-udeb, since libgobject-2.0 requires libffi6 as of GLib
2.29.4.
--- libffi-3.0.10~rc8.orig/debian/control
+++ libffi-3.0.10~rc8/debian/control
@@ -110,0 +111,10 @@
+
+Package: libffi6-udeb
+Section: debian-installer
+XC-Package-Type: udeb
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Foreign Function Interface library runtime
+ 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.
--- libffi-3.0.10~rc8.orig/debian/libffi6-udeb.install
+++ libffi-3.0.10~rc8/debian/libffi6-udeb.install
@@ -0,0 +1 @@
+usr/lib/lib*.so.*
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
--
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/20110610090904.gn31...@riva.ucam.org
Re: Instead of the amd64 GR: rudimentary amd64 support for sarge, need sponsor.
On Tue, Aug 03, 2004 at 12:21:14PM -0400, Daniel Jacobowitz wrote: I don't know how we would want to build it; given the freeze it is probably too late to build it from the GCC source package, unless we want to build it from the gcc-3.4 source package (which presumably is not part of base and thus not frozen). Matthias, how do you feel about that? libgcc1 is produced from the gcc-3.4 source package on many architectures, so it is frozen. It'll have to go through t-p-u. -- Colin Watson [EMAIL PROTECTED]
Bug#250185: Bug#253149: ssh client segfaulting on strongARM -- OpenSSH_3.8p1 Debian (forwarded from Colin Watson)
On Sun, Jun 13, 2004 at 08:35:08PM +0100, Philip Blundell wrote: On Sun, 2004-06-13 at 20:11, Matthias Klose wrote: Philip Blundell writes: Apparently this problem is triggered by -O3, which ssh has just started using. I don't know any more than that at the moment, unfortunately. So a workaround is to build using -O2 on arm (which should be the default according to Debian policy anyway). It seems so, yes. I don't know why openssh started using -O3. It doesn't; openssh uses -O2. Are you sure you don't mean openssl? -- Colin Watson [EMAIL PROTECTED]
Re: Bug#253149: ssh client segfaulting on strongARM -- OpenSSH_3.8p1 Debian
reassign 253149 gcc-3.3 severity 253149 important merge 250185 253149 thanks On Mon, Jun 07, 2004 at 10:04:31AM -0400, Viney, Ulf wrote: Package: ssh Version: 3.8p1-3 (OpenSSH_3.8p1 Debian 1:3.8p1-3, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004) Error: tiger:~/.ssh# ssh -vvv [EMAIL PROTECTED] OpenSSH_3.8p1 Debian 1:3.8p1-3, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. Segmentation fault [...] Please note that the CPU is a strongARM. The system is a Netwinder (www.netwinder.org) Details: sshd is working correctly. I can ssh to the box from an x86 sarge or woody host. I can not ssh from the strongARM box to any other sshd host. This is bug #250185, which appears to be a toolchain bug. I don't know of any resolution yet. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: mail loops -- [Bug preprocessor/9071] Warning for blocks not closed in same file as opened in (forwarded from dberlin at gcc dot gnu dot org)
On Mon, Jan 19, 2004 at 11:32:29PM +0100, Matthias Klose wrote: Maybe this was changed with the move of the Debian BTS to the new host? Could the same change be made on spohr? No, my memory is that the mail loops appeared to have stopped ages ago so I removed the workaround. Certainly the workaround was in a place that was rsynced over to spohr verbatim and wasn't host-specific. Aha: see my closing message to http://bugs.debian.org/174503. I've put in a slightly saner workaround than the previous one, which suppresses acks to any mail with the X-Bugzilla-Reason: header. Let me know if that doesn't work. Ages ago I suggested a fix to the gcc bug tracking system that would work for everyone and avoid this stupid situation where everybody's bug tracking system has to include individual workarounds for every other bug tracking system: simply make your Bugzilla ignore mails it receives with the Precedence: header set to bulk, junk, or list, and set Precedence: bulk on any automatically originated mails. debbugs has done this since shortly after this discussion last came up. Please can somebody implement this in Bugzilla? [Please remove [EMAIL PROTECTED] from replies; there's no system-level configuration involved here so it doesn't need to involve them.] Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Latest GCC didn't autobuild on arm
On Sat, Sep 20, 2003 at 10:06:29PM -0400, Nathanael Nerode wrote: It somehow seems not to have installed doxygen, for unknown reasons. Hopefully this can be resolved ASAP? ... This was a bug in dpkg-buildpackage: it forgot the -B flag to dpkg-checkbuilddeps, which promptly objected to the lack of Build-Depends-Indep:. Upgrading dpkg-dev in the autobuilder's chroot should fix that. -- Colin Watson [EMAIL PROTECTED]
Bug#212248: gcc-3.3: build fail for libobj not including boehm-gc include files
On Mon, Sep 22, 2003 at 10:57:41PM +0100, Matt Keenan wrote: Package: gcc-3.3 Version: 1:3.3.2-0pre4 Severity: serious Tags: sid patch Justification: no longer builds from source the patch file debian/patches/libobjc.dpatch has an assumption that you have the the gc header files installed. the code snippet below shows how it should be (i.e. using the headers from the source package). hope this helps :) gcc-3.3 build-depends on libgc-dev, containing said headers. I don't see how this is more than a wishlist bug myself, particularly as it seems to be building fine on the autobuilders. Could you justify the serious severity? Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#210848: Forwarded?
Should this bug be marked as forwarded to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12278 (or perhaps better http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12223)? -- Colin Watson [EMAIL PROTECTED]
Bug#175353: Many are architecture independent
On Wed, May 14, 2003 at 07:21:57PM -0400, Anthony DeRobertis wrote: reopen 175353 thanks Many (if not most) libraries have the same ABI on every architecture. Examples: Why is this filed as a serious bug? It causes harm (at least in theory, if there are people who really share /usr/share with Debian) to have a file incorrectly in /usr/share; it causes no harm to have a file unnecessarily in /usr/lib. Is the severity anything more than pure standards-lawyering? To put it another way, we ought to have a pretty good non-theoretical reason for every bug above important. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#189183: libstdc++5-3.3-dev: Why is this tagged sid?
On Sat, Apr 19, 2003 at 05:11:33PM -0400, Morgon Kanter wrote: Why on earth is this bug tagged sid? It is present and certainly noticable in sarge as well. Because when you merge bugs all the tags get merged, and the reporter of #189431 thought it was a good idea to set the sid tag on his initial report. (Generally speaking it is *not* a good idea to set woody/sarge/sid/etc. tags on initial reports unless you know exactly what you're doing.) -- Colin Watson [EMAIL PROTECTED]
Bug#137973: fastjar: static link to insecure zlib
Package: fastjar Version: 1:3.0.4-2 Severity: grave Justification: user security hole Tags: security fastjar and grepjar both appear to link statically to zlib, so need to be rebuilt against a zlib1g-dev not vulnerable to the recently announced security hole. (Actually, when I configured gcc-3.0 on auric it seemed to end up with 'ZLIBS = $(top_builddir)/../zlib/libz.a -L$(here)/../zlib/', despite the use of --with-system-zlib. Perhaps src/zlib should be patched to be on the safe side; diffing zlib_1.1.3-19.diff.gz and zlib_1.1.3-19.1.diff.gz produces the patch.) Thanks, -- Colin Watson [EMAIL PROTECTED]
Bug#118477: gcc272 should be removed from unstable/testing
On Tue, 06 Nov 2001 at 14:09:58 +0100, Adrian Bunk wrote: Since unstable/testing does no longer include kernel 2.0.x (and these kernels won't work with the modutils in unstable/testing) it's in my opinion time to remove gcc272 from unstable. It's worth noting that there are still 12 packages build-depending on gcc272 in unstable: hwtools kernel-headers-2.2.19-m68k kernel-image-2.2.19-amiga kernel-image-2.2.19-atari kernel-image-2.2.19-bvme6000 kernel-image-2.2.19-i386 kernel-image-2.2.19-mac kernel-image-2.2.19-mvme147 kernel-image-2.2.19-mvme16x kernel-image-2.2.19-reiserfs-i386 kernel-image-2.2.19-udma100-ext3-i386 kernel-image-2.2.20-i386 hwtools doesn't build from source at all (#101687), so I don't know whether it counts. Thanks, -- Colin Watson [EMAIL PROTECTED]
Bug#43170: Rechecked with g++-3.0 3.0-0pre010403
[EMAIL PROTECTED] ~]$ g++-3.0 -c test.cc
test.cc: In function `string do_foo(const string)':
test.cc:6: warning: the named return value extension is deprecated, please see
the documentation for details
test.cc: In member function `string foo::do_foo2(const string)':
test.cc:21: warning: the named return value extension is deprecated, please see
the documentation for details
[EMAIL PROTECTED] ~]$ g++-3.0 -DBUG -c test.cc
test.cc: In function `string do_foo(const string)':
test.cc:6: warning: the named return value extension is deprecated, please see
the documentation for details
test.cc: At global scope:
test.cc:15: function body for constructor missing
test.cc:15: parse error before `{' token
test.cc: In member function `string foo::do_foo(const string)':
test.cc:15: warning: the named return value extension is deprecated, please see
the documentation for details
test.cc: At global scope:
test.cc:19: parse error before `}' token
test.cc: In member function `string foo::do_foo2(const string)':
test.cc:21: warning: the named return value extension is deprecated, please see
the documentation for details
I'm no C++ expert, but, if this is going to be deprecated, can this bug
be closed in the long run?
--
Colin Watson [EMAIL PROTECTED]
Bug#92526: glibc missing vital component
James Blackwell [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Package: libstdc++2.9-glibc2.1 Version: 2.91.66-4 Date; 1 April 2001 When attempting to cheat on my algebra homework, I attempted to square some numbers via the sqrt (see man 3 sqrt) function. Howevever, the following c program fails to compile: Add -lm (link with maths library) to your gcc line. Cheers, -- Colin Watson [EMAIL PROTECTED]
