On Sun, Mar 21, 2010 at 7:41 PM, Doug Semler wrote:
> On Sun, 21 Mar 2010 19:22:48 NightStrike wrote:
>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer wrote:
>> > For some reason yet unknown to me, the gcc-provided headers
>> > have priority over the system provided headers and float.h is
>> > esp
On 3/22/2010 07:24, Doug Semler wrote:
On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler wrote:
Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The
target DLLs for things like libstdc++, etc are installed into the
completely wron
On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler wrote:
> On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
>> On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler wrote:
>> > Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The
>> > target DLLs for things like libstdc++, etc are installed
On Sun, 21 Mar 2010 19:22:48 NightStrike wrote:
> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer wrote:
> > For some reason yet unknown to me, the gcc-provided headers
> > have priority over the system provided headers and float.h is
> > especially problematic: Not installing or deleting it is the s
On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
> On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler wrote:
> > Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The
> > target DLLs for things like libstdc++, etc are installed into the
> > completely wrong spot due to a -bindir param
On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer wrote:
> For some reason yet unknown to me, the gcc-provided headers
> have priority over the system provided headers and float.h is
> especially problematic: Not installing or deleting it is the solution,
> at least for now.
If gcc headers didn't take
On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler wrote:
> Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The
> target DLLs for things like libstdc++, etc are installed into the completely
> wrong spot due to a -bindir parameter in the libtool portion of the DLL
> makefiles. They
On Sun, Mar 21, 2010 at 10:42 PM, Dave Camarillo
wrote:
> Hello, I'm having a little trouble with the include paths used by mingw-w64
> and was hoping for some insight... I have this chunk of code compiling
> correctly under the normal mingw system, but have some problems with include
> search pat
Hello, I'm having a little trouble with the include paths used by mingw-w64
and was hoping for some insight... I have this chunk of code compiling
correctly under the normal mingw system, but have some problems with include
search paths with the w64 version... As far as I can tell, it's just pullin
2010/3/21 Doug Semler :
> On Sun, 21 Mar 2010 13:55:36 Kai Tietz wrote:
>> 2010/3/21 Ozkan Sezer :
>> > On Sun, Mar 21, 2010 at 7:21 PM, NightStrike
> wrote:
>> >> Well, this is a problem, yes. It only affects the multilib builds,
>> >> though, which don't really work anyway without a lot of effo
On Sun, 21 Mar 2010 13:55:36 Kai Tietz wrote:
> 2010/3/21 Ozkan Sezer :
> > On Sun, Mar 21, 2010 at 7:21 PM, NightStrike
wrote:
> >> Well, this is a problem, yes. It only affects the multilib builds,
> >> though, which don't really work anyway without a lot of effort. And
> >> this will all be
On Sun, 21 Mar 2010 13:21:12 NightStrike wrote:
> Well, this is a problem, yes. It only affects the multilib builds,
> though, which don't really work anyway without a lot of effort. And
> this will all be fixed for 4.6, o we won't need to worry about it.
>
> If users really want it, though, I c
On Sun, Mar 21, 2010 at 7:55 PM, Kai Tietz wrote:
> 2010/3/21 Ozkan Sezer :
>> On Sun, Mar 21, 2010 at 7:21 PM, NightStrike wrote:
>>> Well, this is a problem, yes. It only affects the multilib builds,
>>> though, which don't really work anyway without a lot of effort. And
>>> this will all be
2010/3/21 Ozkan Sezer :
> On Sun, Mar 21, 2010 at 7:21 PM, NightStrike wrote:
>> Well, this is a problem, yes. It only affects the multilib builds,
>> though, which don't really work anyway without a lot of effort. And
>> this will all be fixed for 4.6, o we won't need to worry about it.
>>
>> I
On Sun, Mar 21, 2010 at 7:21 PM, NightStrike wrote:
> Well, this is a problem, yes. It only affects the multilib builds,
> though, which don't really work anyway without a lot of effort. And
> this will all be fixed for 4.6, o we won't need to worry about it.
>
> If users really want it, though,
Well, this is a problem, yes. It only affects the multilib builds,
though, which don't really work anyway without a lot of effort. And
this will all be fixed for 4.6, o we won't need to worry about it.
If users really want it, though, I can rework things to exclude 32-bit
entirely. It's just a
Quick question:
Are you sure you want to disable the leading underscore on the 32bit side with
the --disable-leading-underscore and multilib? Looking at it (without testing
it, that is), it doesn't seem to me that it is appropriate...
---
17 matches
Mail list logo
