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
17 matches
Mail list logo
