Re: [Mingw-w64-public] [Mingw-users] Fwd: building gcc

2011-07-06 Thread JonY 
On 7/6/2011 16:57, Bj Raz wrote:
>>> I'm not building with glibc, I'm using msvc in my build. So I can
>> compiler
>>> Windows '.exe's' on linux.
>>> Which regardless of the ranlib error the c compiler works fine when I use
>>> it. though I'd prefer not having the ranlib error.
>>>
>>> Cause when I start to try and build c++ it doesn't work.
>>>
>>
>> So, you're trying to build GCC that targets windows, and runs on
>> Windows, but you're on Linux? Please explain clearly your goals.
>>
> To get a version of Linux that will run on my hardware, not in a VM, which
> works fine.
> 

You complain that modern distros are "too new" hardware, yet you run one
in a VM. I do not see how this is mingw-w64 related.

>>
>> If you want your cross GCC to run on Linux, you should never be using
>> cross binutils to build cross GCC in the first place.
>>
> I am running GCC on the SuSE 11 in the VM. Using MSVC as my C library.
> 

MSVCRT is a WINDOWS C runtime, it doesn't have anything to do with
Linux, in any case, you will already need a working cross compiler for
Windows to use it. To use the cross compiler under Linux, it has to be
built for Linux, not Windows.

> I can't build Linux on my "hardware", I want to build it on the "hardware"
> in the case, in Windows, since I can't get Linux on my hardware. So if I
> want to make linux for my hardware, I need a full version of Linux to build
> another full version of Linux. Not just some half built version like msys,
> cygwin, or intrerix, that all are half baked gnu environments, that aren't
> made to be used like a full distro that you can build in/on.
> 

Exactly, so remind me how mingw-w64 is involved again? mingw-w64 doesn't
provide any gnu environment at all, you already have a Linux VM, use it
for your "fully baked" gnu environment.

> I'd not trust them for enough utilities or 64bit capabilities to compile a
> new distro of Linux that will run on my hardware.

Why not? Either it works, or it does not.


0xED74C077.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2___
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingw-users] Fwd: building gcc

2011-07-06 Thread Bj Raz 
On Tue, Jul 5, 2011 at 1:37 PM, JonY  wrote:

> On 7/6/2011 01:25, Bj Raz wrote:
> > No, I'm on linux, building an environment that will make a another
> > envronment that I will use on Windows.
> >
>
> In that case, try strace to see why it isn't starting. I thought you
> don't have Linux running because its "too new".
>
> >>
> >>
> >> One would assume you already have a working cross compiler, or some
> >> GCC
> >> installed on Windows, when you said:
> >>
> >> """
> >>
> >>> Cause I'm not building for linux, I'm building so i can have better
> >> Windows
> >>> utilities, cause I can't get a Linux distro that will run on my
> >> hardware.
> >>> Its too new! So I'm making one...
> >>
> >> """
> >>
> >> I mentioned Cygwin and Interix because mingw-w64 doesn't have any
> Unix
> >> translation layer to handle filename sensitivity that you will need
> >> later on. mingw-w64 on mingw-w64 hosted GCC is at most a dead end
> for
> >> you if you want to cross from Windows to Linux.
> >>
> >> Please describe clearly what you are planning to achieve, what
> system
> >> you are running, and how it is related to mingw-w64 clearly.
> >>
> > I figured I'd start to worry about that once I finally have a working
> > compiler built on Windows to cross back to Linux.
> >
> >>
> >> In this case, you can't do it the LFS way, afaik, GLIBC requires you to
> >> build it on a case sensitive FS, that leaves out mingw hosted
> >> toolchains, unless you're going to copy debian/ubuntu glibc tarballs for
> >> the glibc components.
> >>
> > I'm not building with glibc, I'm using msvc in my build. So I can
> compiler
> > Windows '.exe's' on linux.
> > Which regardless of the ranlib error the c compiler works fine when I use
> > it. though I'd prefer not having the ranlib error.
> >
> > Cause when I start to try and build c++ it doesn't work.
> >
>
> So, you're trying to build GCC that targets windows, and runs on
> Windows, but you're on Linux? Please explain clearly your goals.
>
To get a version of Linux that will run on my hardware, not in a VM, which
works fine.

>
> If you want your cross GCC to run on Linux, you should never be using
> cross binutils to build cross GCC in the first place.
>
I am running GCC on the SuSE 11 in the VM. Using MSVC as my C library.

>
> If you are really building cross gcc to target win64 hosted on Linux,
> please refer to
> <
> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-doc/howto-build/
> >
> for help on building. Its a bit old but should get you the basics, just
> forget about LFS, since most of it won't apply to mingw-w64 anyway.
>
I can't build Linux on my "hardware", I want to build it on the "hardware"
in the case, in Windows, since I can't get Linux on my hardware. So if I
want to make linux for my hardware, I need a full version of Linux to build
another full version of Linux. Not just some half built version like msys,
cygwin, or intrerix, that all are half baked gnu environments, that aren't
made to be used like a full distro that you can build in/on.

I'd not trust them for enough utilities or 64bit capabilities to compile a
new distro of Linux that will run on my hardware.

>
> >>> Does anyone think I should install the crt earlier in the process? Like
> >> when
> >>> I build the api I also build the crt.
> >>>
> >>
> >> What API? The CRT should be built after you get a bootstrap GCC. Please
> >> just use the documented process, you don't need to make things so hard.
> >>
> > the api is: mingw64api
> >
>
> There isn't such a thing, maybe you mixed it up with mingw.org's w32api?
>
>
>
> --
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> ___
> Mingw-w64-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2___
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingw-users] Fwd: building gcc

2011-07-05 Thread JonY 
On 7/6/2011 01:25, Bj Raz wrote:
> No, I'm on linux, building an environment that will make a another
> envronment that I will use on Windows.
> 

In that case, try strace to see why it isn't starting. I thought you
don't have Linux running because its "too new".

>>
>>
>> One would assume you already have a working cross compiler, or some
>> GCC
>> installed on Windows, when you said:
>>
>> """
>>
>>> Cause I'm not building for linux, I'm building so i can have better
>> Windows
>>> utilities, cause I can't get a Linux distro that will run on my
>> hardware.
>>> Its too new! So I'm making one...
>>
>> """
>>
>> I mentioned Cygwin and Interix because mingw-w64 doesn't have any Unix
>> translation layer to handle filename sensitivity that you will need
>> later on. mingw-w64 on mingw-w64 hosted GCC is at most a dead end for
>> you if you want to cross from Windows to Linux.
>>
>> Please describe clearly what you are planning to achieve, what system
>> you are running, and how it is related to mingw-w64 clearly.
>>
> I figured I'd start to worry about that once I finally have a working
> compiler built on Windows to cross back to Linux.
>
>>
>> In this case, you can't do it the LFS way, afaik, GLIBC requires you to
>> build it on a case sensitive FS, that leaves out mingw hosted
>> toolchains, unless you're going to copy debian/ubuntu glibc tarballs for
>> the glibc components.
>>
> I'm not building with glibc, I'm using msvc in my build. So I can compiler
> Windows '.exe's' on linux.
> Which regardless of the ranlib error the c compiler works fine when I use
> it. though I'd prefer not having the ranlib error.
> 
> Cause when I start to try and build c++ it doesn't work.
> 

So, you're trying to build GCC that targets windows, and runs on
Windows, but you're on Linux? Please explain clearly your goals.

If you want your cross GCC to run on Linux, you should never be using
cross binutils to build cross GCC in the first place.

If you are really building cross gcc to target win64 hosted on Linux,
please refer to

for help on building. Its a bit old but should get you the basics, just
forget about LFS, since most of it won't apply to mingw-w64 anyway.

>>> Does anyone think I should install the crt earlier in the process? Like
>> when
>>> I build the api I also build the crt.
>>>
>>
>> What API? The CRT should be built after you get a bootstrap GCC. Please
>> just use the documented process, you don't need to make things so hard.
>>
> the api is: mingw64api
> 

There isn't such a thing, maybe you mixed it up with mingw.org's w32api?



0xED74C077.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2___
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingw-users] Fwd: building gcc

2011-07-05 Thread Bj Raz 
On Tue, Jul 5, 2011 at 1:25 PM, Bj Raz  wrote:

> On Tue, Jul 5, 2011 at 7:05 AM, JonY  wrote:
>
>> On 7/5/2011 17:29, Bj Raz wrote:
>> > On Tue, Jul 5, 2011 at 5:05 AM, Bj Raz  wrote:
>> >
>> >> On Tue, Jul 5, 2011 at 4:58 AM, Bj Raz 
>> wrote:
>> >>
>> >>> On Tue, Jul 5, 2011 at 4:03 AM, JonY 
>> wrote:
>> >>>
>>  On 7/5/2011 15:04, Bj Raz wrote:
>> > On Mon, Jul 4, 2011 at 9:01 PM, JonY 
>>  wrote:
>> >
>> >> On 7/5/2011 07:19, Bj Raz wrote:
>> >>> On Mon, Jul 4, 2011 at 4:32 PM, Kai Tietz
>> >> wrote:
>> >>>
>>  Well,
>> 
>>  this can have different reasons.  First could be that you didn't
>>  installed binutils for x86_64-w64-mingw32 target. Second point
>> could
>>  be that you missed to setup PATH environment variable so that the
>>  folder /bin is included.
>> >>
>> > My path is set to:
>> > "/tools/bin/:/bin/:usr/bin" just like it says to in the LFS book.
>> > and what about cygwin... I'm not using it!
>> > I'm using Suse Linux 11 (x86_64-suse-linux-gnu) as my host
>> environment
>>  and
>> > there shouldn't be anything that has anything to do with
>> cyg-anything.
>> > and my target is: x86_64-w64-mingw32.
>> >
>> > I don't know where you are getting the idea I'm using Cygwin. :-/
>> >
>> 
>>  What do you have in /tools/bin?
>> 
>> >>> x86_64-w64-mingw32-addr2line
>> >>> x86_64-w64-mingw32-ar
>> >>> x86_64-w64-mingw32-as
>> >>> x86_64-w64-mingw32-c++filt
>> >>> x86_64-w64-mingw32-cpp
>> >>> x86_64-w64-mingw32-dlltool
>> >>> x86_64-w64-mingw32-dllwrap
>> >>> x86_64-w64-mingw32-elfedit
>> >>> x86_64-w64-mingw32-gcc
>> >>> x86_64-w64-mingw32-gcc-4.7.0
>> >>> x86_64-w64-mingw32-gcov
>> >>> x86_64-w64-mingw32-gprof
>> >>> x86_64-w64-mingw32-ld
>> >>> x86_64-w64-mingw32-ld.bfd
>> >>> x86_64-w64-mingw32-nm
>> >>> x86_64-w64-mingw32-objcopy
>> >>> x86_64-w64-mingw32-objdump
>> >>> x86_64-w64-mingw32-ranlib
>> >>> x86_64-w64-mingw32-readelf
>> >>> x86_64-w64-mingw32-size
>> >>> x86_64-w64-mingw32-strings
>> >>> x86_64-w64-mingw32-strip
>> >>> x86_64-w64-mingw32-windmc
>> >>> x86_64-w64-mingw32-windres
>> >>>
>>
>> No .exe? Are you on Windows or Linux?
>>
> No, I'm on linux, building an environment that will make a another
> envronment that I will use on Windows.
>
>>
>> 
>>  One would assume you already have a working cross compiler, or some
>> GCC
>>  installed on Windows, when you said:
>> 
>>  """
>> 
>> > Cause I'm not building for linux, I'm building so i can have better
>>  Windows
>> > utilities, cause I can't get a Linux distro that will run on my
>>  hardware.
>> > Its too new! So I'm making one...
>> 
>>  """
>> 
>>  I mentioned Cygwin and Interix because mingw-w64 doesn't have any
>> Unix
>>  translation layer to handle filename sensitivity that you will need
>>  later on. mingw-w64 on mingw-w64 hosted GCC is at most a dead end for
>>  you if you want to cross from Windows to Linux.
>> 
>>  Please describe clearly what you are planning to achieve, what system
>>  you are running, and how it is related to mingw-w64 clearly.
>> 
>> >>> I figured I'd start to worry about that once I finally have a working
>> >>> compiler built on Windows to cross back to Linux.
>> >>>
>>
>> In this case, you can't do it the LFS way, afaik, GLIBC requires you to
>> build it on a case sensitive FS, that leaves out mingw hosted
>> toolchains, unless you're going to copy debian/ubuntu glibc tarballs for
>> the glibc components.
>>
> I'm not building with glibc, I'm using msvc in my build. So I can compiler
> Windows '.exe's' on linux.
> Which regardless of the ranlib error the c compiler works fine when I use
> it. though I'd prefer not having the ranlib error.
>
> Cause when I start to try and build c++ it doesn't work.
>
>>
>> You'll still need a way to handle symlinks for .so versions.
>>
>> >>> For now I'm trying to cross to build for Windows, and if you know how
>> to,
>> >>> I can set flags so what "I" build will be case sensitive, when I
>> finally get
>> >>> to that point.
>> >>>
>>
>> No, FS case sensitivity isn't handled by WIN32 API at all, I don't know
>> where you get the idea it can be enabled at build time as a flag.
>>
> Case sensitivity could be forced on the application level of msys, cygwin
or interix.

>
>> 
>>  Here is a file with my tree.
>> >> This is up to before I install crt
>> >>
>> > Does anyone think I should install the crt earlier in the process? Like
>> when
>> > I build the api I also build the crt.
>> >
>>
>> What API? The CRT should be built after you get a bootstrap GCC. Please
>> just use the documented process, you don't need to make things so hard.
>>
> the api is: mingw64api
>
>>
>>
>> --
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It

Re: [Mingw-w64-public] [Mingw-users] Fwd: building gcc

2011-07-05 Thread Bj Raz 
On Tue, Jul 5, 2011 at 7:05 AM, JonY  wrote:

> On 7/5/2011 17:29, Bj Raz wrote:
> > On Tue, Jul 5, 2011 at 5:05 AM, Bj Raz  wrote:
> >
> >> On Tue, Jul 5, 2011 at 4:58 AM, Bj Raz  wrote:
> >>
> >>> On Tue, Jul 5, 2011 at 4:03 AM, JonY 
> wrote:
> >>>
>  On 7/5/2011 15:04, Bj Raz wrote:
> > On Mon, Jul 4, 2011 at 9:01 PM, JonY 
>  wrote:
> >
> >> On 7/5/2011 07:19, Bj Raz wrote:
> >>> On Mon, Jul 4, 2011 at 4:32 PM, Kai Tietz
> >> wrote:
> >>>
>  Well,
> 
>  this can have different reasons.  First could be that you didn't
>  installed binutils for x86_64-w64-mingw32 target. Second point
> could
>  be that you missed to setup PATH environment variable so that the
>  folder /bin is included.
> >>
> > My path is set to:
> > "/tools/bin/:/bin/:usr/bin" just like it says to in the LFS book.
> > and what about cygwin... I'm not using it!
> > I'm using Suse Linux 11 (x86_64-suse-linux-gnu) as my host
> environment
>  and
> > there shouldn't be anything that has anything to do with
> cyg-anything.
> > and my target is: x86_64-w64-mingw32.
> >
> > I don't know where you are getting the idea I'm using Cygwin. :-/
> >
> 
>  What do you have in /tools/bin?
> 
> >>> x86_64-w64-mingw32-addr2line
> >>> x86_64-w64-mingw32-ar
> >>> x86_64-w64-mingw32-as
> >>> x86_64-w64-mingw32-c++filt
> >>> x86_64-w64-mingw32-cpp
> >>> x86_64-w64-mingw32-dlltool
> >>> x86_64-w64-mingw32-dllwrap
> >>> x86_64-w64-mingw32-elfedit
> >>> x86_64-w64-mingw32-gcc
> >>> x86_64-w64-mingw32-gcc-4.7.0
> >>> x86_64-w64-mingw32-gcov
> >>> x86_64-w64-mingw32-gprof
> >>> x86_64-w64-mingw32-ld
> >>> x86_64-w64-mingw32-ld.bfd
> >>> x86_64-w64-mingw32-nm
> >>> x86_64-w64-mingw32-objcopy
> >>> x86_64-w64-mingw32-objdump
> >>> x86_64-w64-mingw32-ranlib
> >>> x86_64-w64-mingw32-readelf
> >>> x86_64-w64-mingw32-size
> >>> x86_64-w64-mingw32-strings
> >>> x86_64-w64-mingw32-strip
> >>> x86_64-w64-mingw32-windmc
> >>> x86_64-w64-mingw32-windres
> >>>
>
> No .exe? Are you on Windows or Linux?
>
No, I'm on linux, building an environment that will make a another
envronment that I will use on Windows.

>
> 
>  One would assume you already have a working cross compiler, or some
> GCC
>  installed on Windows, when you said:
> 
>  """
> 
> > Cause I'm not building for linux, I'm building so i can have better
>  Windows
> > utilities, cause I can't get a Linux distro that will run on my
>  hardware.
> > Its too new! So I'm making one...
> 
>  """
> 
>  I mentioned Cygwin and Interix because mingw-w64 doesn't have any Unix
>  translation layer to handle filename sensitivity that you will need
>  later on. mingw-w64 on mingw-w64 hosted GCC is at most a dead end for
>  you if you want to cross from Windows to Linux.
> 
>  Please describe clearly what you are planning to achieve, what system
>  you are running, and how it is related to mingw-w64 clearly.
> 
> >>> I figured I'd start to worry about that once I finally have a working
> >>> compiler built on Windows to cross back to Linux.
> >>>
>
> In this case, you can't do it the LFS way, afaik, GLIBC requires you to
> build it on a case sensitive FS, that leaves out mingw hosted
> toolchains, unless you're going to copy debian/ubuntu glibc tarballs for
> the glibc components.
>
I'm not building with glibc, I'm using msvc in my build. So I can compiler
Windows '.exe's' on linux.
Which regardless of the ranlib error the c compiler works fine when I use
it. though I'd prefer not having the ranlib error.

Cause when I start to try and build c++ it doesn't work.

>
> You'll still need a way to handle symlinks for .so versions.
>
> >>> For now I'm trying to cross to build for Windows, and if you know how
> to,
> >>> I can set flags so what "I" build will be case sensitive, when I
> finally get
> >>> to that point.
> >>>
>
> No, FS case sensitivity isn't handled by WIN32 API at all, I don't know
> where you get the idea it can be enabled at build time as a flag.
>
> 
>  Here is a file with my tree.
> >> This is up to before I install crt
> >>
> > Does anyone think I should install the crt earlier in the process? Like
> when
> > I build the api I also build the crt.
> >
>
> What API? The CRT should be built after you get a bootstrap GCC. Please
> just use the documented process, you don't need to make things so hard.
>
the api is: mingw64api

>
>
> --
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> ___
> Mingw-w64-public mailing

Re: [Mingw-w64-public] [Mingw-users] Fwd: building gcc

2011-07-05 Thread JonY 
On 7/5/2011 17:29, Bj Raz wrote:
> On Tue, Jul 5, 2011 at 5:05 AM, Bj Raz  wrote:
> 
>> On Tue, Jul 5, 2011 at 4:58 AM, Bj Raz  wrote:
>>
>>> On Tue, Jul 5, 2011 at 4:03 AM, JonY  wrote:
>>>
 On 7/5/2011 15:04, Bj Raz wrote:
> On Mon, Jul 4, 2011 at 9:01 PM, JonY 
 wrote:
>
>> On 7/5/2011 07:19, Bj Raz wrote:
>>> On Mon, Jul 4, 2011 at 4:32 PM, Kai Tietz
>> wrote:
>>>
 Well,

 this can have different reasons.  First could be that you didn't
 installed binutils for x86_64-w64-mingw32 target. Second point could
 be that you missed to setup PATH environment variable so that the
 folder /bin is included.
>>
> My path is set to:
> "/tools/bin/:/bin/:usr/bin" just like it says to in the LFS book.
> and what about cygwin... I'm not using it!
> I'm using Suse Linux 11 (x86_64-suse-linux-gnu) as my host environment
 and
> there shouldn't be anything that has anything to do with cyg-anything.
> and my target is: x86_64-w64-mingw32.
>
> I don't know where you are getting the idea I'm using Cygwin. :-/
>

 What do you have in /tools/bin?

>>> x86_64-w64-mingw32-addr2line
>>> x86_64-w64-mingw32-ar
>>> x86_64-w64-mingw32-as
>>> x86_64-w64-mingw32-c++filt
>>> x86_64-w64-mingw32-cpp
>>> x86_64-w64-mingw32-dlltool
>>> x86_64-w64-mingw32-dllwrap
>>> x86_64-w64-mingw32-elfedit
>>> x86_64-w64-mingw32-gcc
>>> x86_64-w64-mingw32-gcc-4.7.0
>>> x86_64-w64-mingw32-gcov
>>> x86_64-w64-mingw32-gprof
>>> x86_64-w64-mingw32-ld
>>> x86_64-w64-mingw32-ld.bfd
>>> x86_64-w64-mingw32-nm
>>> x86_64-w64-mingw32-objcopy
>>> x86_64-w64-mingw32-objdump
>>> x86_64-w64-mingw32-ranlib
>>> x86_64-w64-mingw32-readelf
>>> x86_64-w64-mingw32-size
>>> x86_64-w64-mingw32-strings
>>> x86_64-w64-mingw32-strip
>>> x86_64-w64-mingw32-windmc
>>> x86_64-w64-mingw32-windres
>>>

No .exe? Are you on Windows or Linux?


 One would assume you already have a working cross compiler, or some GCC
 installed on Windows, when you said:

 """

> Cause I'm not building for linux, I'm building so i can have better
 Windows
> utilities, cause I can't get a Linux distro that will run on my
 hardware.
> Its too new! So I'm making one...

 """

 I mentioned Cygwin and Interix because mingw-w64 doesn't have any Unix
 translation layer to handle filename sensitivity that you will need
 later on. mingw-w64 on mingw-w64 hosted GCC is at most a dead end for
 you if you want to cross from Windows to Linux.

 Please describe clearly what you are planning to achieve, what system
 you are running, and how it is related to mingw-w64 clearly.

>>> I figured I'd start to worry about that once I finally have a working
>>> compiler built on Windows to cross back to Linux.
>>>

In this case, you can't do it the LFS way, afaik, GLIBC requires you to
build it on a case sensitive FS, that leaves out mingw hosted
toolchains, unless you're going to copy debian/ubuntu glibc tarballs for
the glibc components.

You'll still need a way to handle symlinks for .so versions.

>>> For now I'm trying to cross to build for Windows, and if you know how to,
>>> I can set flags so what "I" build will be case sensitive, when I finally get
>>> to that point.
>>>

No, FS case sensitivity isn't handled by WIN32 API at all, I don't know
where you get the idea it can be enabled at build time as a flag.


 Here is a file with my tree.
>> This is up to before I install crt
>>
> Does anyone think I should install the crt earlier in the process? Like when
> I build the api I also build the crt.
> 

What API? The CRT should be built after you get a bootstrap GCC. Please
just use the documented process, you don't need to make things so hard.


0xED74C077.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2___
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public