Bug#171689: libstdc++3 depends on gcc-3
On Wed, Dec 04, 2002 at 12:48:17PM +0100, Marco Bodrato wrote: > Package: libstdc++3 > Version: 1:3.0.4-13 > Severity: minor > > I do not know the usual behaving in Debian, but I do not understand why the > library should depend on the gcc-compiler. I'm not using gcc-3.0 any more, > but I can not uninstall it, because some pacages depend on libstdc++3 which > depends on gcc-3.0. > But the binaries should not depend on the compiler... libstdc++3 does not depend on the compiler, which is in gcc-3.0. It merely depends on gcc-3.0-base, which contains a few documentation files. -- Colin Watson [EMAIL PROTECTED]
Re: [Fwd: pb to access debian-gcc cvs as anonymous?]
On Sat, Apr 05, 2003 at 07:11:59PM +, Joel Soete wrote: > Original Message > Subject: pb to access debian-gcc cvs as anonymous? > Date: Sat, 22 Mar 2003 20:45:01 + > From: Joel Soete <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > > > Hi Debian-admin, > > Acoording to <http://cvs.debian.org/?cvsroot=debian-gcc> [1] I set my > CVSROOT=":pserver:[EMAIL PROTECTED]:/cvs/debian-gcc" and choose > gcc-3.3 as module to co but since severall weeks I always get the > following err messages at the login: > Fatal error, aborting. > anonymous: no such user > > I haven't such a pb with fai of > ":pserver:[EMAIL PROTECTED]:/cvs/debian-boot". > > Is it a simple configuration pb or a way to limit acces to developpers > only (in this last case could you update [1] to inform us?)? Somebody with access to debian-gcc CVS - not me - needs to add a 'passwd' file in CVSROOT mapping anonymous to some real user (debbugs has "anonymous:69S/nLyi1wYKc:debbugs", the password field is just a crypted empty string) and a 'readers' file containing just "anonymous". That is, if anonymous access is to be allowed, which I don't see why it shouldn't be. I don't think it needs debian-admin's intervention to set this up. -- Colin Watson [EMAIL PROTECTED]
Re: [Fwd: pb to access debian-gcc cvs as anonymous?]
On Tue, Apr 08, 2003 at 08:19:23AM +0200, Joel Soete wrote: > Hi Mathhias, > >Colin Watson writes: > >> Somebody with access to debian-gcc CVS - not me - needs to add a > >> 'passwd' file in CVSROOT mapping anonymous to some real user (debbugs > >> has "anonymous:69S/nLyi1wYKc:debbugs", the password field is just a > >> crypted empty string) and a 'readers' file containing just "anonymous". > >> That is, if anonymous access is to be allowed, which I don't see why it > >> shouldn't be. > > > >done. > > Thanks for followup but it doesn't yet grant me anonymous access; > I just retry now and always: "anonymous: no such user" The anonymous user probably ought not to map to 'debbugs' in this case. :-) -- 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#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
Bug#630006: closed by Matthias Klose (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#698344: libffi: missing autotools support and symbols file for arm64
aintainer-clean-vti
+Index: b/configure.ac
+===
+--- 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#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
Re: Attempt to build perl with gcc 2.95 on ARM
I've just managed to build perl with gcc-3.3 and -O1 on pp_ctl, pp_hot, and pp_sort, using the patch suggested by Brendan earlier in the bug report. I've uploaded this binary-only to unstable, although I know that's a hack. Thanks to Vince for letting me use astonishing amounts of CPU time on this. Unfortunately, the build depends on the new libgcc1 from gcc-3.4. debian-gcc, can I confirm that you intend to let the current version of gcc-3.4 into testing, once the m68k build arrives? Thanks, -- Colin Watson [EMAIL PROTECTED]
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#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#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#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]
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#206232: gcc-3.3: [ppc] segmentation fault on altivec code
On Tue, Aug 19, 2003 at 05:14:27PM +0200, Guido Guenther wrote: > Package: gcc-3.3 > Version: 1:3.3.2-0pre1 > Severity: normal > > Hi, > gcc -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64 -Wall -g -DHAVE_AV_CONFIG_H -I.. > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -maltivec > -mabi=altivec -c -o ppc/idct_altivec.o ppc/idct_altivec.c > ppc/idct_altivec.c:171: internal compiler error: Segmentation fault > Preprocessed source is at: > http://honk.physik.uni-konstanz.de/linux-mips/gcc/bugs/idct_altivec.i > Compiles fine with gcc-snapshot 20030815-1. Is fftw3's current build failure on powerpc the same bug? I've attached preprocessed source for this; looking at PR target/11949 it seems similar. $ gcc -O3 -fomit-frame-pointer -fno-schedule-insns -fstrict-aliasing -mcpu=powerpc -pthread -maltivec -mabi=altivec -fPIC n1fv_9.i n1fv_9.c: In function `n1fv_9': n1fv_9.c:43: error: unrecognizable insn: (insn 3105 1672 1673 2 (nil) (set (reg:V4SF 77 v0) (const_vector:V4SF [ (const_double:SF 9.3969261646270751953125e-1 [0x0.f08fb2p+0]) (const_double:SF 9.3969261646270751953125e-1 [0x0.f08fb2p+0]) (const_double:SF 9.3969261646270751953125e-1 [0x0.f08fb2p+0]) (const_double:SF 9.3969261646270751953125e-1 [0x0.f08fb2p+0]) ])) -1 (nil) (nil)) n1fv_9.c:43: internal compiler error: in extract_insn, at recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Thanks, -- Colin Watson [EMAIL PROTECTED] n1fv_9.i.gz Description: Binary data
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]
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#99523: gcj-3.0: Missing symlinks for some man pages
Package: gcj-3.0 Severity: normal Hi, An upcoming release of Debian policy, version 3.5.5.0, contains an amendment which clarifies the way man pages need to be installed. Until now, packages could install /usr/share/man/man1/foo.1.gz with 'foo, bar \- programs to do something' in the NAME section and have no corresponding symbolic link from bar.1.gz (policy suggested using a symbolic link, but wasn't clear that it's required), and our man program happened to magically figure it out for itself and display the right man page when you typed 'man bar'. However, guaranteeing that this would work even when you've recently installed some new packages has a serious performance impact on man, as it frequently has to go and look through the filesystem to update its database. Before woody's base system is frozen, I intend to remove this "feature" from man-db, so that its performance is consistent and acceptable for a reasonable number of people. It isn't a standard feature even among the various man page browsers in Debian, let alone in other Linux distributions, so there should be no compatibility problems. However, your package seems to rely on it, so this bug is being filed to let you know that the way some of your man pages are installed needs to be improved in order to work properly in woody. All you need to do, if you already have, say, foo(1) and expect bar(1) to work as well, is install a symbolic link to foo.1.gz as bar.1.gz (.so links and hard links are also OK, though symlinks are recommended). Here's a list of man pages and the names that don't appear anywhere in the filesystem: usr/share/man/man1/gcj-3.0.1.gz: gij If the list looks odd, please check man(7) to see if the man page is formatted properly. This output was generated by way of mandb, so if it's confused then users will be too; if it turns out that it's done the wrong thing, please reassign this bug to man-db so that I can fix it. I might not have caught symlinks that are created in the postinst (say, using alternatives); if that's the case, please close this bug. Please see bug #94995 and policy 3.5.5 section 13.1 for more information, and feel free to contact me if you need help. Thanks, -- Colin Watson, via a script
Bug#105695: gcc-defaults: please remove suggestions of task packages
Package: gcc-defaults Version: 0.11 Severity: normal Hi, gcc, gobjc, and g++ all suggest task-* packages, which no longer exist in testing/unstable. Perhaps they could be replaced by suggestions of some useful individual packages instead. 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#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]
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: 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]
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]
