On Tue, Jul 5, 2011 at 1:25 PM, Bj Raz <whitequill...@gmail.com> wrote:
> On Tue, Jul 5, 2011 at 7:05 AM, JonY <jo...@users.sourceforge.net> wrote:
>
>> On 7/5/2011 17:29, Bj Raz wrote:
>> > On Tue, Jul 5, 2011 at 5:05 AM, Bj Raz <whitequill...@gmail.com> wrote:
>> >
>> >> On Tue, Jul 5, 2011 at 4:58 AM, Bj Raz <whitequill...@gmail.com>
>> wrote:
>> >>
>> >>> On Tue, Jul 5, 2011 at 4:03 AM, JonY <jo...@users.sourceforge.net>
>> wrote:
>> >>>
>> >>>> On 7/5/2011 15:04, Bj Raz wrote:
>> >>>>> On Mon, Jul 4, 2011 at 9:01 PM, JonY <jo...@users.sourceforge.net>
>> >>>> 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 <prefix>/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 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
>> Mingw-w64-public@lists.sourceforge.net
>> 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
