Summary: | [11/12/13/14 Regression] Can't cross compile for i686-apple-darwin10/11/12 from x86_64-redhat_linux | ||
---|---|---|---|
Product: | gcc | Reporter: | Ruben Van Boxem <vanboxem.ruben> |
Component: | bootstrap | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | NEW --- | ||
Severity: | normal | CC: | astrand, egallager, fxcoudert, iains, jakub, peter, rguenth, rmansfield |
Priority: | P4 | ||
Version: | 4.7.0 | ||
Target Milestone: | 11.5 | ||
See Also: | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103677 | ||
Host: | x86_64-linux | Target: | i686-apple-darwin10 |
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2014-11-08 00:00:00 | |
Attachments: |
toplevel config.log
toplevel config.log gcc/config.log Compressed build log detailing failure |
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 (In reply to Iain Sandoe from comment #21) > (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" So does this bug need to stay open then? (In reply to Eric Gallager from comment #27) > (In reply to Iain Sandoe from comment #21) > > (In reply to Francois-Xavier Coudert from comment #20) > > > This PR appears to report two different issues: > > > 1. cross-compiler targeting Darwin > > > 2. cross-compiler hosted on Darwin > > in short (2) is very definitely "works for me" > So does this bug need to stay open then? I reported the original issue using Fedora's Mac OS X cross compiler toolchains that were available at the time. They are still described here, but the repo has become unavailable: https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework I cannot seem to locate an active repository providing these now. So it is really your number one. If the problem lies outside of GCC sources, perhaps it's best to close this issue, but as it used to work in GCC 4.6, it seems something changed that made this setup nonfunctional. (In reply to Ruben Van Boxem from comment #28) > (In reply to Eric Gallager from comment #27) > > (In reply to Iain Sandoe from comment #21) > > > (In reply to Francois-Xavier Coudert from comment #20) > > > > This PR appears to report two different issues: > > > > 1. cross-compiler targeting Darwin > > > > 2. cross-compiler hosted on Darwin > > > in short (2) is very definitely "works for me" > > So does this bug need to stay open then? > > I reported the original issue using Fedora's Mac OS X cross compiler > toolchains that were available at the time. They are still described here, > but the repo has become unavailable: > https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework > > I cannot seem to locate an active repository providing these now. > > So it is really your number one. If the problem lies outside of GCC sources, > perhaps it's best to close this issue, but as it used to work in GCC 4.6, it > seems something changed that made this setup nonfunctional. Well looking back at comment #21 Iain did say some of his patches were for GCC so at least some of the problem is in GCC sources, even if most of it is in the rest of the toolchain... I'll change the status to NEW since it's not you we're WAITING on. Changing milestone since gcc-5-branch has been closed. (In reply to Eric Gallager from comment #30) > Changing milestone since gcc-5-branch has been closed. ...and again now that gcc-6-branch has been closed. The GCC 7 branch is being closed, re-targeting to GCC 8.4. GCC 8.4.0 has been released, adjusting target milestone. GCC 8 branch is being closed. GCC 9.4 is being released, retargeting bugs to GCC 9.5. GCC 9 branch is being closed GCC 10.4 is being released, retargeting bugs to GCC 10.5. GCC 10 branch is being closed. |
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.