This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Crosstool-NG build produces all the tools except the compiler


I just tried the build which I originally described, and essentially the
same one Yann describes below (which he had trouble with) using the
latest crosstool-ng from the hg repo (default@1928_0535b588679a) and it
builds without problems.  Note that this is straight from the repo, no
extra patches applied.


> build : x86_64-suse-linux    (Yann's is i686-pc-linux-gnu)
> host  : i386-mingw32msvc     (Yann's is i586-mingw32msvc)
> target: m68k-unknown-elf


  .../m68k-unknown-elf/bin/m68k-unknown-elf-ranlib.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-strings.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-c++filt.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-addr2line.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-ld.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-cc.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-nm.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-readelf.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-ar.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-gcov.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-size.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-as.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-gcc.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-objcopy.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-strip.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-gprof.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-gcc-4.3.4.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-cpp.exe
  .../m68k-unknown-elf/bin/m68k-unknown-elf-objdump.exe
  .../m68k-unknown-elf/m68k-unknown-elf/bin/objcopy.exe
  .../m68k-unknown-elf/m68k-unknown-elf/bin/ld.exe
  .../m68k-unknown-elf/m68k-unknown-elf/bin/ar.exe
  .../m68k-unknown-elf/m68k-unknown-elf/bin/gcc.exe
  .../m68k-unknown-elf/m68k-unknown-elf/bin/nm.exe
  .../m68k-unknown-elf/m68k-unknown-elf/bin/ranlib.exe
  .../m68k-unknown-elf/m68k-unknown-elf/bin/objdump.exe
  .../m68k-unknown-elf/m68k-unknown-elf/bin/strip.exe
  .../m68k-unknown-elf/m68k-unknown-elf/bin/as.exe
  .../m68k-unknown-elf/libexec/gcc/m68k-unknown-elf/4.3.4/collect2.exe
  .../m68k-unknown-elf/libexec/gcc/m68k-unknown-elf/4.3.4/cc1.exe
  .../m68k-unknown-elf/libexec/gcc/m68k-unknown-elf/4.3.4/
          install-tools/fixincl.exe

I have not tested the exe files yet on Windoze but I will and I'll
report back.


On 04/20/2010 03:17 PM, Yann E. MORIN wrote:
> Hello All!
> 
> On Tuesday 20 April 2010 20:52:05 Remy Bohmer wrote:
>> 2010/4/19 Mitch Frazier <mitch@comwestcr.com>:
>>>> I'm trying to build an m68k-unknown-elf toolchain that will run on a
>>>> Windows system.  I'm building it on openSUSE 11.2.
>> You did nothing wrong... Unfortunately the canadian build is not yet
>> supported in Crosstool-ng.
>> Recently I posted a series of 19 patches that made it possible to
>> build exactly that what you need.
> 
> A good part of the series has been pushed upstream, now. Thanks again!
> 
>> These series of patches have been partially applied while it was
>> tested as a whole, some rework is pending on some other patches.
>> What did not help us though is that during the process of getting
>> these series to be applied several other patches got merged in that
>> had a huge impact on our series, with as result that we now do not
>> have a working a set of patches on top of ct-ng mainline.
> 
> Yes, sorry for not waiting a repost. A good part of that series were actual
> bug fixes. 1.7.0 is expected by the end of april, and those fixes were more
> than welcome! :-)
> 
> I applied so I could spend this week and the next one bashing out potential
> regressions, and update the samples, in order to get as clean a release as
> possible. Sorry for the inconvenience... :-(
> 
> As for the remaining patches, being new features, they'll have to wait
> post-1.7.0, sorry.
> 
>> Further, before we can continue with this series we need to wait on
>> Yann since he mentioned that he did not like the way we implemented
>> certain parts and that he would provide an alternative implementation
>> himself. Although this sounds good, it effectively pushed us out of
>> the game...
> 
> Sorry I was long to jump back in. The mail server that serves my address is
> experiencing some down-time, and it is much longer to bring it back up as
> it is holidays here in France, and I have some troubles getting in touch
> with the admins (I have an account there, but am not allowed to sudo).
> In the meantime, I skim the ML archives about once a day...
> 
> The good side of this is I can focus all my free time on polishing 1.7.0! :-]
> 
> I hope this will be fixed soon, though.
> 
>> I hope Yann has a good suggestion how to continue from
>> here and speed things up...
> 
> What's not been applied from the series:
> 
> 10 -> add m68k CPU selection
> No: it's a nightmare to maintain, as new gcc versions come out. Besides,
> if the list is kept up-to-date with gcc, older versions will fail to build
> as the new variants won't be recognised/allowed/... Also, binutils also
> has to be configured with the appropriate variant, and if the list is not
> in sync, then... Barf!
> 
> 11 -> add mingw32 kernel
> 12 -> add mingw32 libraries
> 13 -> add mingw32 sample
> New features: I have no strong objections for most of that, except for 12 (see
> below), and the few style-issues I pointed.
> 12: I would like a proper explanation of why this should go in crosstool-NG.
> I understand this is required to properly build for mingw32, but why not
> delegate to the user the responsibility to properly set up his/her build
> environment?
> 
> 15 -> add cygwin kernel
> New feature: no strong objections. Using pre-built binaries is not the way
> crosstool-NG has followed until now, but we can decide to go this route, and
> if it does not get /fixed/ by the next release, then it gets away. Let's give
> us the chance to add this cool new 'kernel'! :-)
> 
> 16 -> fix ppl configure for mingw32
> Bug-to-be fix: no reason not to be applied, except that mingw32 is not yet in.
> 
> 17 -> link with stdc++ when needed
> That one interferes with my previous work on static companion libraries.
> Fortunately, it should be much easier to get it right, now. The idea
> would be to link against stdc++ when needed, eg. at least one of:
> - static companion libraries
> - /exotic/ kernels
> 
> Something like:
> 
> config LINK_STDCXX_NEEDED
>     bool
>     default n
> 
> config KERNEL_mingw32
>     select LINK_STDCXX_NEEDED
> 
> and so on...
> 
> Then every components can rely on LINK_STDCXX_NEEDED to be set, and add
> -lstdc++ to their build flags or config options.
> 
> All in all, the remaining parts of the series is quite good-looking.
> Just rework the patchset against current tree, it should not change
> much, now, I promise! ;-]
> 
> And, by the way, when you fix an entry in the TODO, don't forget to
> provide a patch that shrinks the beast! Hehe! :-)
> 
>> So, for the short term, if you need to have a toolchain quickly I
>> would suggest to use hg to checkout the crosstool-ng tree and get to
>> the status of the tree of about 9 april 2010 and apply the 19-patch
>> series I posted. I rebased the patch-series to the snapshot just
>> minutes before going public with the series, so it will apply on that
>> snapshot.
> 
> Also, current tree is (should be!) up-to-date with all the fixes from that
> series, the rest being new features, and thus not required to fix this
> issue.
> 
> Oh, just an issue, I was unable to build this canadian bare metal on my
> Debian lenny:
>   build : i686-pc-linux-gnu
>   host  : i586-mingw32msvc
>   target: m68k-unknown-elf
> 
> That's because there is a missing sys/wait.h on mingw32 (which is expected).
> I did not have time to investigate, so I'll dump the issue until I have more
> time (wild guess: I selected too new a gcc).
> 
>> I also noticed you used the mingw cross compiler of your distribution.
>> Inside this series also support was added to build a mingw cross
>> compiler toolchain with crosstool-ng itself ;-)
> 
> Yes! I'm eager to merge that in. :-)
> 
>> P.S. we also have a working tree (based on the status of 9 april 2010)
>> that even supports cross-native compilations ;-)
> 
> Oh! \o/
> 
> Again, sorry for the delay in my answers...
> 
> Regards,
> Yann E. MORIN.
> 


--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]