Package: lib32gcc1
Version: 1:4.4.0-7
Severity: serious
Hi,
lib32gcc1 contains /usr/lib32/libgcc_s.so.1.
In libc6-i386 prior to 2.9-14 /usr/lib32 is a link to
/emul/ia32-linux/usr/lib. lib32gcc1 having a file in /usr/lib32 makes
it impossible to upgrade to any libc6-i386 version prior to 2.9-14.
Package: gcc-4.4
Version: 4.4.0-1~exp2
Severity: normal
Hi,
thanks for adding more multiarch support to gcc. But the support
doesn't seem to be quite correct yet. I've looked at the library path
and canonicalized the entries for better readability:
# Broken path. Missing a '/'?
* Duplicate entry
Package: g++-4.1
Version: 4.1.1-21
Severity: normal
Hi,
I work without execptions and want to ensure that error codes that
might be returned by functions will not be ignored. So I added the
attribute warn_unused_result to the function prototype. But with
functions returning an union the attribute
Package: apertium
Severity: minor
Hi,
when I build apertium on m68k I get this:
m68k-linux-gnu-g++ -Wall -ansi -O3 -o apertium-rehtml apertium-rehtml.o
/usr/bin/xsltproc deformat.xsl rtf-format.xml |/usr/bin/flex -Cfer -t
>apertium-desrtf.C
if m68k-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I. -I.
Package: gcc-3.3
Version: 1:3.3.5-12
Severity: important
Justification: fails to build from source
Hi,
I'm trying to rebuild gcc-3.3 in sarge to track another bug and I got
a FTBFS on my normal system. I tried again in my buildd chroot and
there it works.
Comparing the build logs I found:
| DEB
Package: libgcj4-dev
Version: 1:3.3.5-7
Severity: important
File: /usr/lib/libgcj.la
Justification: Causes related packages to miscompile
Hi,
libgcj.la contains
libdir='/usr/lib64'
instead of
libdir='/usr/lib'
resulting in libtool using rpath and dpkg-shlibdeps to not find
required libs (and
Package: libffi3-dev
Version: 1:3.4.1-7
Severity: grave
Justification: renders package unusable
Hi,
libffi.la has the following libdir:
libdir='/usr/lib/../lib'
That cuases libtool to add the rpath option when linking against the
library which in turn prevents shlibs to work (since no package
c
t=us-ascii
> Content-Transfer-Encoding: 7bit
> Message-ID: <[EMAIL PROTECTED]>
> Date: Sat, 5 Jan 2002 03:10:20 +0100
> To: Goswin Brederlow <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> CC: Roman Zippel <[EMAIL PROTECTED]>
> Subject: Re: Bug#127783:
Package: gcc-3.0
Version: 1:3.0.3-1
Severity: normal
This should be easy to fix:
E: libgcj2-dev: package-has-a-duplicate-relation libgcj2, libgcj2 (>= 1:3.0.3-1)
MfG
Goswin
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux dual 2.4.16 #2 SMP Sun Dec 2 15:35:42 C
Matthias Klose <[EMAIL PROTECTED]> writes:
> Goswin Brederlow writes:
> > Package: gcc-3.0
> > Version: 1:3.0.3-1
> > Severity: normal
> >
> > The package doesn't pass its selftests and _should_fail_ to build.
> > It should fail when the first m
Package: gcc-3.0
Version: 1:3.0.3-1
Severity: normal
from a m68k build:
choose-temp.o(.text+0xf6): the use of `mktemp' is dangerous, better use
`mkstemp'
and there are at leas one more.
MfG
Goswin
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux dual 2.4.16
Package: gcc-3.0
Version: 1:3.0.3-1
Severity: normal
The package doesn't pass its selftests and _should_fail_ to build.
It should fail when the first make fails and not continue with other
selftest, otherwise errors get overlocked.
The timeout might be the reason why it fails to build on m68k,
so
12 matches
Mail list logo