User account creation filtered due to spam.
Created attachment 25130 [details] toplevel config.log I am cross-compiling a HOST=i686-apple-darwin10 BUILD=x86_64-redhat-linux TARGET=i686-w64_mingw32 cross-compiler. GCC 4.6 (and most probably 4.5) work fine, GCC 4.7 misconfigures and results in a build failure. Attached is top-level toplevel config.log, more to follow.
Created attachment 25131 [details] toplevel config.log Add proper toplevel config.log
Created attachment 25132 [details] gcc/config.log Attached gcc/config.log
Created attachment 25133 [details] Compressed build log detailing failure Attached build log. ("make all-gcc" output)
For those wondering how on Earth I am cross-compiling for Mac, see http://build1.openftd.org/fedora-cross-darwinx/ This is a cross toolchain for Fedora, which works quite well. The version used in the build is: Using built-in specs. Target: i686-apple-darwin10 Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=i686-apple-darwin10 --enable-languages=c,objc,c++,obj-c++ --with-sysroot=/usr/darwinx/SDKs/MacOSX10.5.sdk --with-as=/usr/bin/darwinx-as --with-ld=/usr/bin/darwinx-ld --enable-static --enable-shared --disable-nls --enable-multilib --enable-libssp Thread model: posix gcc version 4.2.1 (Apple Inc. build 5664)
Not necessarily related to your specific problem - but a "heads up": I've just committed a change to the Darwin port that will make the compiler (better) use the target system headers. However, it will also accentuate the issue that you are targeting Darwin10 using a Darwin9 system framework and toolset. You will need to fake a darwin10 "ld" that can handle the "-no_compact_unwind" unwind flag (or comment that section out of config/darwin10.h). Until someone has time to update odcctools or toolwhip to a Darwin10 version, I wonder if it is not simply easier to build an i686-Darwin9 executable? (which should run fine on Darwin10)
(In reply to comment #5) > Not necessarily related to your specific problem - but a "heads up": > > I've just committed a change to the Darwin port that will make the compiler > (better) use the target system headers. > > However, it will also accentuate the issue that you are targeting Darwin10 > using a Darwin9 system framework and toolset. > > You will need to fake a darwin10 "ld" that can handle the "-no_compact_unwind" > unwind flag (or comment that section out of config/darwin10.h). > > Until someone has time to update odcctools or toolwhip to a Darwin10 version, I > wonder if it is not simply easier to build an i686-Darwin9 executable? (which > should run fine on Darwin10) (this relates to the host libs and tools of course - not the mingw_32 stuff).
I'm still experiencing the same behavior. I don't think the darwinx toolchain has the problems you say? Why do you think it uses a Darwin9 system framework and headers? It has GCC 4.2.1 and the Mac OS X 10.5 SDK, which are all pretty Darwin10 as far as I can see. Something changed in 4.6 vs 4.7. I have sys/malloc.h , objc/malloc.h, and malloc/malloc.h. Somehow, HAVE_MALLOC_H is being wrongfully defined to 1 when it should be 0. auto-host.h has the define commented out. auto-build.h has it defined. These are the same for GCC 4.6. So the problem must lie elsewhere... I noticed the gengtype-lex.o object file is build with i686-apple-darwin10-gcc for GCC 4.7, and (Linux) gcc for GCC 4.6. This cannot be intended behavior.
(In reply to comment #7) > I'm still experiencing the same behavior. yes, I would guess so unless you re-build the cross tools (and that would probably not solve your config problems - given the other comments you made) ... > I don't think the darwinx toolchain has the problems you say? Why do you think > it uses a Darwin9 system framework and headers? It has GCC 4.2.1 and the Mac OS > X 10.5 SDK, which are all pretty Darwin10 as far as I can see. OSX 10.5 is darwin 9 (and gcc 4.2.1 is perfectly usable under OSX10.5/darwin9 - it's just not the default). Target: i686-apple-darwin10 Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=i686-apple-darwin10 --enable-languages=c,objc,c++,obj-c++ --with-sysroot=/usr/darwinx/SDKs/MacOSX10.5.sdk .........................................................^^^^^^^^^^^^ I'm not aware of a genuine darwin10 (OSX 10.6) cross-toolchain - but if there is I'd love to see it (I'm only aware of toolwhip and odcctools which are both on the darwin9 ld64 AFAIK).
I received a build of a darwinx-ld binary from the darwinx toolchain maintainer that accepts the -no_compact_unwind option, and the problem has not gone away. Configure is either using the wrong headers for the build or configure is messing up.
i686-apple-darwin10 isn't a cross-only target but also a host platform.
GCC 4.7.0 is being released, adjusting target milestone.
GCC 4.7.1 is being released, adjusting target milestone.
GCC 4.7.2 has been released.
> Until someone has time to update odcctools or toolwhip to a Darwin10 version, I wonder if it is not simply easier to build an i686-Darwin9 executable? (which should run fine on Darwin10) I've done this. I started from javacom's toolchain4 which uses odcctools. I heavily patched odcctools to bring them more up to date. Eventually, the hope is to merge these cross compilers with the crosstool-ng project. For now though, you can find the source code here: https://github.com/mingwandroid/toolchain4 (master branch should build ok with ./build-all.sh apple provided you've got MacOSX10.7.sdk) ..and binaries here (again to use these you need MacOSX10.7.sdk): http://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120724.tar.xz http://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Windows-120614.7z http://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Darwin-120615.7z (the Darwin native build is provided too for testing/QA purposes).
What brought me here was a desire to add some information about this bug, when I saw the odcctools comment from Iain I thought I may as well mention my compilers. Further Information: I'm also getting this when trying to build some Android cross compilers in the Canadian way, with failures when host is either Darwin or Windows. The bug only happens if --enable-plugins is specified to configure (as that's what triggers building a gengtype executable for the host machine). Darwin: build system type... x86_64-pc-linux-gnu host system type... i686-apple-darwin target system type... arm-unknown-linux-androideabi i686-apple-darwin-gcc -c -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -DGENERATOR_FILE -I. -Ibuild -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/build -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../include -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../libcpp/include -I/tmp/necessitas/ndk-build/build/host-gcc/i686-apple-darwin/temp-prereqs/include -I/tmp/necessitas/ndk-build/build/host-gcc/i686-apple-darwin/temp-prereqs/include -I/tmp/necessitas/ndk-build/build/host-gcc/i686-apple-darwin/temp-prereqs/include -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../libdecnumber -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../libdecnumber/dpd -I../libdecnumber -o build/genconstants.o /tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/genconstants.c In file included from /tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/genconstants.c:29: /tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/system.h:459:20: error: malloc.h: No such file or directory Windows: build system type... x86_64-pc-linux-gnu host system type... i686-w64-mingw32msvc target system type... arm-unknown-linux-androideabi i686-w64-mingw32msvc-gcc -c -Os -fomit-frame-pointer -s -D__USE_MINGW_ACCESS -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/. -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../include -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../libcpp/include -I/tmp/necessitas/ndk-build/build/host-gcc/i686-w64-mingw32msvc/temp-prereqs/include -I/tmp/necessitas/ndk-build/build/host-gcc/i686-w64-mingw32msvc/temp-prereqs/include -I/tmp/necessitas/ndk-build/build/host-gcc/i686-w64-mingw32msvc/temp-prereqs/include -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../libdecnumber -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../libdecnumber/dpd -I../libdecnumber /tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/genconstants.c -o genconstants.o In file included from /tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/genconstants.c:29:0: /tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/system.h:351:22: fatal error: sys/wait.h: No such file or directory ...so as Ruben said, it seems that there's config confusion going on.
Of course, when I wrote '--enable-plugins' I really mean't *not* passing --disable-plugin (without the 's').
GCC 4.7.3 is being released, adjusting target milestone.
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.
The 4.7 branch is being closed, moving target milestone to 4.8.4.
This PR appears to report two different issues: 1. cross-compiler targeting Darwin 2. cross-compiler hosted on Darwin The first one, as far as I know, simply doesn't work for recent darwin versions, due to lack of compiler tools (cross assembler and linker). Is that correct? For the second, could someone post a clear and up-to-date example of when it doesn't work?
(In reply to Francois-Xavier Coudert from comment #20) > This PR appears to report two different issues: > 1. cross-compiler targeting Darwin cross-compilers targeting Darwin <= 9 are possible using odcctools. For "the future" I am working on a set of GCC patches and a GAS port that solves part of the problem for newer cases. I intend to post these before stage#1 ends (but time is short - esp. with trunk trashed on darwin at the moment). However the static linker remains an issue (I have a build of ld64-127.2 which supports Darwin10, and ppc*) … however, this needs to be forward-ported to the latest published sources for ld64 before it will support "current" Darwin. In any event, it would be the User's responsibility to obtain a suitable SDK for the target - by downloading the appropriate Xcode and extracting the SDK as needed. in short: "can't be expected to work until there's a set of Darwin 'binutils' supporting > darwin 9". (working on providing that). > 2. cross-compiler hosted on Darwin I do this all the time - it's possible to cross from x86_64-darwin12 -> powerpc-darwin9, for example (assuming one has the relevant cctools and ld64, and enough patience). I have also built native-crosses [x86-64-darwin12=build powerpc-darwin8 host/target] for the record. Darwin works just fine as a host for cross-compilers to Linux. (building your own sysroot - in particular GLIBC can be a trial, but if you make a sysroot from a standard distro, it's not hard). in short (2) is very definitely "works for me"
(In reply to Iain Sandoe from comment #21) > in short (2) is very definitely "works for me" For me too: I regularly build darwin-to-mingw-w64 cross compilers, with no problem at all. But there were, apparently, problems with Canadian crosses (comments by Ray Donnelly).
GCC 4.8.4 has been released.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
GCC 4.9 branch is being closed