Package: gcc-4.2
Version: 4.2-20070707-1
Severity: important
Attempting to build even the most basic amd64 binaries generate a
spurious warning on i386:
| [EMAIL PROTECTED]:/tmp$ cat foo.c
| int main(void)
| {
| return 0;
| }
| [EMAIL PROTECTED]:/tmp$ gcc-4.1 -m64 foo.c -o foo
| [EMAIL PR
reassign 427185 gcc-4.1
thanks
On Sun, Jun 03, 2007 at 03:39:25PM +0200, Matthias Klose wrote:
> unreproducible; works for me in a current unstable environment.
I've just updated again to current unstable (only portmap and findutils
changed) and can still reproduce the problem:
| [EMAIL PROTECT
reassign 427185 gcc-4.1
found 427185 4.1.2-11
notfound 427185 1:1.2.3-15
retitle 427185 Warning output when linking 64 bit objects on i386
thanks
The enclosed FTBFS in the 64 bit zlib on i386 appears to be a toolchain
issue, though I may have assigned it to the wrong package.
The issue is that li
On Fri, May 11, 2007 at 09:35:36PM +0100, Mark Brown wrote:
> On Sat, May 05, 2007 at 12:42:30AM +0200, Robert Millan wrote:
> > Argh, sorry. As Aurelien just pointed out, gcc-multilib has the missing
> > files.
> Just to confirm, is this supposed to be added to the build
On Sat, May 05, 2007 at 12:42:30AM +0200, Robert Millan wrote:
> Argh, sorry. As Aurelien just pointed out, gcc-multilib has the missing
> files.
Just to confirm, is this supposed to be added to the build dependencies
of packages needing cross build support? I'd been assuming that this
was a t
On Wed, Oct 19, 2005 at 08:26:22AM -0700, Matt Kraai wrote:
> I'm afraid I don't understand how 334013 is related to this problem.
> It's reported against zlib whereas the package I had trouble building
> was ncurses.
In the middle of the report there's a report of a problem I had building
hello,
reassign 318292 gcc-4.0
thanks
GCC 4.0 is causing ICEs trying to build zlib on m68k with -O3. I filed
this report with the idea that I would investigate it before filing on
GCC 4.0 but I'm not 100% sure what I was going to investigate. From the
build log:
| gcc -O3 -g -D_REENTRANT -fPIC -DUSE_M
On Sat, Jul 09, 2005 at 12:33:04AM +0100, Mark Brown wrote:
> get a biarch build of a simple hello world program to build with the
> compilers I found to try:
> gcc-4.0 -m64 hello.c
> also complains about not being able to find libgcc.
Forgot to mention: I also see equiva
reassign 317473 gcc-4.0
thanks
On Fri, Jul 08, 2005 at 03:17:52PM -0700, Steve Langasek wrote:
> These problems began following packaging changes intended to support
> biarch on amd64; perhaps something went wrong with that change? It
> could also be caused by recent toolchain updates, though; i
Package: gcc-3.4
Version: 3.4.1-5
Severity: minor
When installed on a system with no other C compilers installed the
gcc-3.4 package will not create an alternative for /usr/bin/cc, meaning
that things that rely on that being there won't work even though there
is in fact a C compiler installed.
--
On Mon, Sep 01, 2003 at 12:01:43PM +0200, Francesco P. Lovergine wrote:
> klecker:~$ readelf --syms /lib/libc.so.5|grep getnetent
>309: 00019208 322 FUNCGLOBAL DEFAULT8 getnetent
> klecker:~$ readelf --relocs /lib/libc.so.5|grep getnetent
>0008864c 00013507 R_386_JUMP_SLOT 000
On Sat, Aug 30, 2003 at 08:16:19PM +0200, Francesco Paolo Lovergine wrote:
> So needed symbols are defined. The same for libc.so.
> This seems a problem of altgcc...
Are you sure about that? readelf on libc.so.5 tells a slightly
different story:
Relocation section '.rel.plt' at offset 0xf498 co
On Wed, Nov 20, 2002 at 05:11:42PM -0800, Jan Finjord wrote:
> I have a queer problem with the compilation of a 'simple' Fortran
> program, which makes me wonder if it could ever be due to a compiler
> error?
For at least ran3 it's an error in the code. It's assuming that
variables (specifically
On Tue, Oct 15, 2002 at 02:12:48PM -0400, Phil Edwards wrote:
> On Tue, Oct 15, 2002 at 06:36:50PM +0100, Mark Brown wrote:
> > Grovelling around on the GCC website it appears that the issue is that
> > libstdc++ needs _GNU_SOURCE although I can't quite be sure abo
Package: g++-3.2
Version: 1:3.2.1-0pre3
Severity: normal
Tags: upstream
GCC 3.2 appears to define _GNU_SOURCE unconditionally. This is somewhat
unhelpful if one wishes to use the feature selection macros provided by
glibc to choose which APIs are provided by the library.
This appears to be a lon
15 matches
Mail list logo
