On Wed, Feb 12, 2014 at 11:57 AM, Jakub Jelinek wrote:
> On Wed, Feb 12, 2014 at 11:52:47AM +0100, Richard Biener wrote:
>> On Tue, Feb 11, 2014 at 5:17 PM, Jakub Jelinek wrote:
>> > On Fri, Jan 31, 2014 at 03:49:40PM +0100, Richard Biener wrote:
>> >> On Fri, Jan 31, 2014 at 3:45 PM, FX wrote:
On Wed, Feb 12, 2014 at 11:52:47AM +0100, Richard Biener wrote:
> On Tue, Feb 11, 2014 at 5:17 PM, Jakub Jelinek wrote:
> > On Fri, Jan 31, 2014 at 03:49:40PM +0100, Richard Biener wrote:
> >> On Fri, Jan 31, 2014 at 3:45 PM, FX wrote:
> >> >> I've just seen that an explicit --enable-multilib is
On Tue, Feb 11, 2014 at 5:17 PM, Jakub Jelinek wrote:
> On Fri, Jan 31, 2014 at 03:49:40PM +0100, Richard Biener wrote:
>> On Fri, Jan 31, 2014 at 3:45 PM, FX wrote:
>> >> I've just seen that an explicit --enable-multilib is a way to do that.
>> >
>> > Yes, I was writing that as a reply when I re
On Fri, Jan 31, 2014 at 03:49:40PM +0100, Richard Biener wrote:
> On Fri, Jan 31, 2014 at 3:45 PM, FX wrote:
> >> I've just seen that an explicit --enable-multilib is a way to do that.
> >
> > Yes, I was writing that as a reply when I received your email. (Also, it's
> > written in the configure
On Fri, 31 Jan 2014, Richard Biener wrote:
> Still I think this is odd behavior - as you are matching x86_64-*linux
> you can as well check for /usr/include/gnu/stub{,-64}.h. I don't know
On Ubuntu those are in /usr/include/x86_64-linux-gnu/gnu/ (and I suppose
the 32-bit one is /usr/include/i38
> As I said, you can't "properly" check it at the point you are checking.
> Which is why I complain - you're not checking this properly!
This is understood. There is a choice to be made, between an early check (which
will benefit our casual users) catching this particular special case, and a
lat
On Fri, Jan 31, 2014 at 3:45 PM, FX wrote:
>> I've just seen that an explicit --enable-multilib is a way to do that.
>
> Yes, I was writing that as a reply when I received your email. (Also, it's
> written in the configure error message.)
Yeah - you know, that message is quite long and somehow I
> I've just seen that an explicit --enable-multilib is a way to do that.
Yes, I was writing that as a reply when I received your email. (Also, it’s
written in the configure error message.)
> Btw, doing the configure check exactly after all-stage1-gcc should be
> an early enough and a serializat
On Fri, Jan 31, 2014 at 3:40 PM, Richard Biener
wrote:
> On Fri, Jan 31, 2014 at 3:33 PM, Richard Biener
> wrote:
>> On Fri, Dec 13, 2013 at 10:47 PM, FX wrote:
The patch is okay, but if other architecture maintainers could add
similar checks for their ports (SPARC and PPC, I guess), i
On Fri, Jan 31, 2014 at 3:33 PM, Richard Biener
wrote:
> On Fri, Dec 13, 2013 at 10:47 PM, FX wrote:
>>> The patch is okay, but if other architecture maintainers could add
>>> similar checks for their ports (SPARC and PPC, I guess), it would be nice.
>>
>> Thanks, committed as rev. 205975
>>
>> A
On Fri, Dec 13, 2013 at 10:47 PM, FX wrote:
>> The patch is okay, but if other architecture maintainers could add
>> similar checks for their ports (SPARC and PPC, I guess), it would be nice.
>
> Thanks, committed as rev. 205975
>
> Adding other systems to the list of checks will be easy, once the
> The patch is okay, but if other architecture maintainers could add
> similar checks for their ports (SPARC and PPC, I guess), it would be nice.
Thanks, committed as rev. 205975
Adding other systems to the list of checks will be easy, once the maintainers
confirm that they want to opt in into i
Il 09/12/2013 12:08, Gerald Pfeifer ha scritto:
> On Mon, 9 Dec 2013, FX wrote:
>> > Look at this as a diagnostics bug: our current diagnostics for this
>> > pretty common situation sucks. It comes late in the compilation, and
>> > the message itself isn’t helpful.
> Totally seconded.
>
> Paolo,
On 12/09/2013 02:46 AM, Gerald Pfeifer wrote:
> Hmm, it looks like this has not been approved/applied, but I also
> have not seen any NACK.
>
> This does address an annoying (and hard for novices to understand)
> roadblock for someone installing GCC manually. Can this go in?
The patch looks ok t
On Mon, 9 Dec 2013, FX wrote:
> Look at this as a diagnostics bug: our current diagnostics for this
> pretty common situation sucks. It comes late in the compilation, and
> the message itself isn’t helpful.
Totally seconded.
Paolo, I have been running into this myself and was confused at
first.
> I'm not sure why this should be different for x86_64 compared to all
> other bi-arch toolchains?
It’s not, but it’s a particularly common one and has been reported multiple
times here and on gcc-help. If we can help these users early, we spare
ourselves the time to reply to such reports. (Also
Il 09/12/2013 11:46, Gerald Pfeifer ha scritto:
> Hmm, it looks like this has not been approved/applied, but I also
> have not seen any NACK.
>
> This does address an annoying (and hard for novices to understand)
> roadblock for someone installing GCC manually. Can this go in?
I'm not sure why t
Hmm, it looks like this has not been approved/applied, but I also
have not seen any NACK.
This does address an annoying (and hard for novices to understand)
roadblock for someone installing GCC manually. Can this go in?
Gerald
On Sat, 24 Aug 2013, FX wrote:
> ping
>
>
>> Given that I did not
ping
> Given that I did not receive any feedback on my earlier email on this topic,
> I would like to send this patch for RFC. I'm not expert at this
> configury-stuff, so please try to comment on both the test proposed and my
> actual implementation :)
>
> The idea is to find a patch which b
Given that I did not receive any feedback on my earlier email on this topic, I
would like to send this patch for RFC. I'm not expert at this configury-stuff,
so please try to comment on both the test proposed and my actual implementation
:)
The idea is to find a patch which both catches probabl
20 matches
Mail list logo
