Sedat Dilek wrote:
> ANYWAY, these workarounds should not be necessary, it should work OOTB.
> Not sure, what's wrong.
Well, some files have moved, and GCC does not know about their new
locations yet. There are two ways to cope with that:
A. Patch GCC to learn the new state of the world. The
On Wed, Aug 10, 2011 at 4:47 PM, Jonathan Nieder wrote:
> Sedat Dilek wrote:
>
>> When building mesa wizh new gcc-4.7:
>>
>> configure:3094: error: C compiler cannot create executables
>
> But of course. You'll need to pass 'CC="gcc -B/usr/lib/...
> -I/usr/include/..."' to mesa's configure script
Sedat Dilek wrote:
> When building mesa wizh new gcc-4.7:
>
> configure:3094: error: C compiler cannot create executables
But of course. You'll need to pass 'CC="gcc -B/usr/lib/...
-I/usr/include/..."' to mesa's configure script.
You can experience the same thing by building a "hello world" pr
On Wed, Aug 10, 2011 at 3:09 PM, Sedat Dilek wrote:
> On Wed, Aug 10, 2011 at 5:15 AM, Jonathan Nieder wrote:
>> Hi,
>>
>> Sedat Dilek wrote:
[...]
> ### Playing with FLAGS_FOR_TARGET:
>
> $ make FLAGS_FOR_TARGET="${FLAGS_FOR_TARGET}
> -B/usr/lib/${HOST_SYSTEM_MULTIARCH_TYPE}
> -I/usr/include/${H
On Wed, Aug 10, 2011 at 5:15 AM, Jonathan Nieder wrote:
> Hi,
>
> Sedat Dilek wrote:
>
>> Do I need additional patches to gcc trunk (I am using the weekly
>> gcc-4.7 snapshot tarballs)?
>
> No need for patches. My build of gcc trunk finally finished:
>
> $ ./configure --prefix=$HOME/opt/gc
Hi,
Sedat Dilek wrote:
> Do I need additional patches to gcc trunk (I am using the weekly
> gcc-4.7 snapshot tarballs)?
No need for patches. My build of gcc trunk finally finished:
$ ./configure --prefix=$HOME/opt/gcc \
CFLAGS_FOR_TARGET="-g -O2 -B/usr/lib/x86_64-linux-
Sedat Dilek wrote:
> Can you explain why you use CFLAGS_FOR_TARGET as configure-option only
> and BOOT_CFLAGS as make-option?
From gcc/doc/install.texi:
If you wish to use non-default GCC flags when compiling the stage2
and stage3 compilers, set @code{BOOT_CFLAGS} on the command
On Tue, Aug 9, 2011 at 9:32 PM, Jonathan Nieder wrote:
> Aurelien Jarno wrote:
>
>> Without any change? gcc-4.6 from Debian is supposed to be patched, and
>> should find gnu/stubs-32.h into /usr/include/i386-linux-gnu/ . It looks
>> like a bug in the gcc-4.6 package. On the other hand I am not abl
On Tue, Aug 9, 2011 at 9:48 PM, Jonathan Nieder wrote:
> Sedat Dilek wrote:
>
[...]
> I've just started a new gcc build with
>
> $ git reset --hard origin/master
> $ git clean -fdx
> $ ./configure --prefix=$HOME/opt/gcc \
> CFLAGS_FOR_TARGET="-g -O2 -B/usr/lib/x
Sedat Dilek wrote:
> What means "libtool bug (already fixed)" and where is/was it fixed -
> upstream? In Debian package?
Last time, I ran into trouble with the copy of libtool in the gcc tree
(it would gobble up -B flags), and using the system libtool helped.
But now I can't reproduce that proble
On Tue, Aug 9, 2011 at 9:22 PM, Aurelien Jarno wrote:
> On Tue, Aug 09, 2011 at 07:33:57PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 9, 2011 at 7:23 PM, Aurelien Jarno wrote:
>> > merge 629819 637218
>> > thanks
>> >
>> > On Tue, Aug 09, 2011 at 05:30:33PM +0200, Sedat Dilek wrote:
>> >> Package:
Aurelien Jarno wrote:
> Without any change? gcc-4.6 from Debian is supposed to be patched, and
> should find gnu/stubs-32.h into /usr/include/i386-linux-gnu/ . It looks
> like a bug in the gcc-4.6 package. On the other hand I am not able to
> reproduce the bug with glibc 2.13-16 and gcc-4.6 4.6.1-
On Tue, Aug 09, 2011 at 07:33:57PM +0200, Sedat Dilek wrote:
> On Tue, Aug 9, 2011 at 7:23 PM, Aurelien Jarno wrote:
> > merge 629819 637218
> > thanks
> >
> > On Tue, Aug 09, 2011 at 05:30:33PM +0200, Sedat Dilek wrote:
> >> Package: libc6-dev-amd64
> >> Version: 2.13-16
> >> Severity: normal
> >
On Tue, Aug 9, 2011 at 7:23 PM, Aurelien Jarno wrote:
> merge 629819 637218
> thanks
>
> On Tue, Aug 09, 2011 at 05:30:33PM +0200, Sedat Dilek wrote:
>> Package: libc6-dev-amd64
>> Version: 2.13-16
>> Severity: normal
>>
>> Hi,
>>
>> I thought this stuff is fixed?
>> When building gcc-4.7 snapshot
merge 629819 637218
thanks
On Tue, Aug 09, 2011 at 05:30:33PM +0200, Sedat Dilek wrote:
> Package: libc6-dev-amd64
> Version: 2.13-16
> Severity: normal
>
> Hi,
>
> I thought this stuff is fixed?
> When building gcc-4.7 snapshot, I get again this "gnu/stubs-32.h" error.
>
> My build breaks like
On Tue, Aug 9, 2011 at 6:23 PM, Jonathan Nieder wrote:
> retitle 637218 [i386] cannot use gnu/stubs.h with multiarch-unaware toolchain
> (fatal error: gnu/stubs-32.h: No such file or directory)
> quit
>
> Jonathan Nieder wrote:
>
>> retitle 637218 libc6-dev: moving headers to /usr/include/ breaks
retitle 637218 [i386] cannot use gnu/stubs.h with multiarch-unaware toolchain
(fatal error: gnu/stubs-32.h: No such file or directory)
quit
Jonathan Nieder wrote:
> retitle 637218 libc6-dev: moving headers to /usr/include/ breaks
> external multiarch unaware applications
[...]
>> This lets the
retitle 637218 libc6-dev: moving headers to /usr/include/ breaks
external multiarch unaware applications
quit
Hi Sedat,
Sedat Dilek wrote:
> When building gcc-4.7 snapshot, I get again this "gnu/stubs-32.h" error.
[...]
> $ l /usr/include/i386-linux-gnu/gnu/stubs*
> -rw-r--r-- 1 root root 624
Package: libc6-dev-amd64
Version: 2.13-16
Severity: normal
Hi,
I thought this stuff is fixed?
When building gcc-4.7 snapshot, I get again this "gnu/stubs-32.h" error.
My build breaks like this:
...
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such
file or directory
compilation
19 matches
Mail list logo
