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] |
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] |