some successful build report from host Windows build msys2/mingw-w64 #13
Comments
|
@class101 this is great we are nearly ready for a ct-ng PKGBUILD and integration into gcc packman package building by the sounds of this. I successfully built a gcc 4.8.2 newlib toolchain targeting the PS3 yesterday with help from Ray. |
|
Yes, thanks for helping test this stuff out guys, remaining bugs on my radar (feel free to grab them; I'm currently looking at number 4) are:
|
|
There is something strange when attempting to use them to compile helloworld c++ Windows target: Success with -L/x/libs/gcc-4.8.2-x86_64-w64-mingw32-seh/lib/gcc/x86_64-w64-mingw32/lib Linux target: With -I/x/libs/gcc-4.8.2-x86_64-unknown-linux-dw2/x86_64-unknown-linux-gnu/sysroot/usr/include Success with Darwin does not find lstdc++ And when adding the libstdc++.dylib (copy of full lib libstdc++.6.0.9.dylib), it can't read all the other dylib links Any idea for Win/Linux targets what I could have done wrong for the need of -I and -L on simple helloworld compilation ? |
|
To help with getting to the bottom of these simple testcase failures, you should add -v to the command line to see what header paths are being searched. You could also try compilations with -m32 and -m64 to see if either of those work. I'm guessing you are using the flosoft SDK? If so, your Darwin issues are because of extraction failure due to how the tarball is created and then extracted on Windows, due to it not supporting symlinks properly. There exists no extraction method that I know of on Windows that can do it correctly. 7zip can't do it, creating instead a file with the name of the target in it. MSYS2's tar possibly also can't do it. You could try adding "set MSYS=winsymlinks:nativestrict" in msys2_shell.bat if you have UAC disabled and re-running that batch file and then trying tar. Even if it then works I can't guarantee that using symlinks will work right in the compilers on Windows. If you have access to a real mac or Linux, to make a good tarball, I would install gnutar (via homebrew on OSX) then do: .. the -h option dereferences the symlinks at creation time. IMHO a patch should be written for gnutar to add an option on Windows so that symlinks are handled in a final pass after 'normal' files and directories, but symlinks to symlinks are an extra complication here! The full details of the problem is that proper symlinks can support a target not existing at time of creation of symlink (the target is created soon afterwards so it is ok) whereas implementations of symlink-as-copy fail in this scenario (I'm not sure about Windows native symlinks, whether this is possible or not - in theory it should be as it's not really a symlink otherwise); |
Well not really a problem for libgcc_s because I have checked the msys2 base in msys64\mingw64\lib\gcc\x86_64-w64-mingw32\ and there is no lib folder, libgcc_s.a is in the 4.8.2 folder with other lib, so I manually moves all in the $version folder since it is the first path checked and lib is never checked (checked with Process Monitor) I see for Darwin If I remember https://github.com/phracker/MacOSX-SDKs, I took the 10.6 on the mediafire links he provides, and then my mistake I think I have used 7-zip, will try again based on your recommendations and tar this time because indeed I experienced some other issues extracting tars with 7z in the past, thanks for pointing out this. |
|
Wow set MSYS=winsymlinks:nativestrict is wonderful this is what I was looking for makes true links ! I think I'm going to rebuild with this |
|
If you use -v but also supply a c/c++ file to compile you will get the paths printed out: e.g:
.. I think this (host=Win64 target=Linux) is the most interesting case to fix first. Most likely something went wrong with either kernel headers or libc build. I built an eglibc-2.18 with GCC 4.8.2 cross compiler that you can find here:
(you need to add /mingw64/bin to your PATH before running it!) .. this one works fine for me with both helloworld.c and helloworld.cpp without needing any -I or -L arguments. I tested both -m32 and -m64 and all cases generated executables that ran correctly on Arch Linux x86-64. Please compare your build.log with build.log.bz2 in that 7z to see if you can figure out what's different. Also, I've not had a chance to check over your patches yet and they're probably fine, but it might be a good idea to try a build using just:
to see if you get compilers that work the same as mine. I'm interested to know your results with Darwin SDK extracted with native symlinks, was everything ok? I will be taking a break from hacking for the next day and a half, but I'll try to respond to any questions via email. |
|
On Darwin I have just attempted yet to extract with msys tar the xz he mades but it was the same type of links just a filename inside the file For Linux ignoring nonexistent directory "X:/libs/gcc-4.8.2-x86_64-unknown-linux-dw2/x86_64-unknown-linux-gnu/sysrootX:/libs/gcc-4.8.2-x86_64-unknown-linux-dw2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../include" |
|
I think I see when the bug happens, when it is building gcc final it fails and when I have used process monitor I realize it is looking for X:\libs\gcc-4.8.2-x86_64-unknown-linux-dw2\x86_64-unknown-linux-gnu\include but they do not exists, so to fix I have made junction sys-include sysroot\usr\include but instead I must have done junction include sysroot\usr\include It compiles fine now without -I because the previous nonexistent directory is now junction: ignoring nonexistent directory "X:/libs/gcc-4.8.2-x86_64-unknown-linux-dw2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../x86_64-unknown-linux-gnu/include" |
|
The windows symlinks didn't cause problems to build windows and linux targets For Darwin not sure yet I fail at another point with -v |
|
Let's focus on Linux for now. I don't need to make any junction points. Why
|
|
3.13 and glibc 2.18, because it fails at final compiler for not finding some headers in x86_64-unknown-linux-gnu\include or x86_64-unknown-linux-gnu\sys-include so I made it just junction instead of patching |
|
OK when I get back I will try 3.13. As I say I didn't have this problem and
|
|
yeah but build.sh is too problematic, hardcoding version , uses multilib and I'm not, compiling gettext and libiconv twice so only the compilation of both of these package is as long or maybe longuer than building the whole gcc process so it is boring to do this on windows. Btw I have found your osx tarball in build.sh to correctly extract symlinks under a msys2 with nativestrict links so I will use this one that's cool. While try instead to compare the the build.logs at the configuration stage to see if I can notice important difference , will probably be faster |
|
I have uploaded my build.log for linux64 nomultilib and yours here: https://drive.google.com/folderview?id=0B4dcRcayW88VakstaUdkU2tCbXc&usp=sharing if you can help me find the diff |
|
compared both build log and the main difference I note is me using '--with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' instead of you using '-lstdc++ -lm' in LDFLAGS Also I'm building in a posix=1 environment and you not I think So below are the changes of my build.log with your build.log [WARN ] Your file system in '/c/ctng-build-x-l-none-4_8_2-x86_64-213be3fb/.build' is not case-sensitive! libiconv: no |
|
Btw I have found an explanation why libgcc_s is installed in wrong folders, this is due to --enable-version-specific-runtime-libs |
|
I am taking a day off from hacking today. I will try to look at it later on
|
|
In meantimes since I added bunch of custom args as --enable-version-specific-runtime-libs I will remove them to check if I can get better results because indeed I smell it is hiding a more general issue because in all of my 3 targets, I don't have any tupleDir\include at all and in place of tupleDir\lib I have a symlink to sysroot\lib where in yours you have tupleDir\include\c++ and your tupleDir\lib is not symlink but contains libs directly, I'm probably causing this with a custom option Im using everywhere like --enable-version-specific-runtime-libs , will do more tests //edit:Even my win target returns strange things when compiling with -v so It is not really linux issue |
|
also is it normal that with set MSYS=winsymlinks:nativestrict the configure scripts does not detect ln -s working ? because when building I still get a no for ln -s , using cp -Rr instead |
|
I never tried with that option..
|
|
nvm I should have read configure, I always forget there is the line number that is showable for this purpose. In case you wonder to know why this is a known issue : On MSYS, both "ln -s file dir" and "ln file dir" fail. this is the ln -s test done |
|
I confirm removing --enable-version-specific-runtime-libs I had added as custom option changes a lot of folder position, looks much better without and as it finds includes and libs without any special argument, still a non existent directory being searched but not a big deal I believe since sysroot\mingw is in the search path already |
|
I can reproduce the include bug I have on target linux64 include bug with also a target windows64 but non-sysrooted(did not happen with sysroot active), took the complete logs this time and if I execute the failing command with -v I get |
|
crosstool-ng doesn't work non-sysrooted (which implies native), in fact it should refuse to build in that scenario. How did you get it to start building, and also, why do you want to avoid using a sysroot? |
|
Answering my own question here, I'm guessing that you are trying without a sysroot because sysrooted versions end up with X:/blah/blah/blahX/:/blah/blah in their search paths? If so this is due to a limitation of MSYS and MSYS2. Again, you should use my build.sh script as that avoids the problem in the least intrusive way I could manage it. We added an env. var to MSYS2 to prevent specific path transformations and in build.sh this is done with:
|
|
I don't really need and like sysroot because it is creating lots of subfolders levels, you finally have multiple libs, include folders everywhere etc you finally don't know what is used, what is not. When you look the architecture of TDM GCC that is not sysrooted, it's much cleaner. Anyway I have one folder of each GCC so I don't see why I need to enclose again this in a sysroot. Or I would have preferred you sysroot this in the whole folder, not in a sysroot subfolder, like mingw-w64 pubbed builds they do sysroot=/mingw64 Also while trying winsymlinks:nativestrict I realize your build.sh patches assumes ln -s does not work so I realize a few of the patch here conflicts with what I'm trying yet and I will just apply the minimum patches from this project I have tested commenting in all the configure scripts of all packages, the configuration detected fine ln -s and it worked perfectly without more patches and it worked for all the packages because I believe ln -s file dir or ln -s dir file is rarely used, it is not a big help for WIndows target, but very good for linux targets, I don't need to patch rellns script anymore when it is about to create links |
|
What you prefer and what crosstool-ng is capable of are two different things I'm afraid. You will have to make changes to crosstool-ng to get what you want to work. I also think crosstool-ng's folder layout is weird and a bit broken and would be happy if you were to fix it. I guess we are in agreement that specifying a prefix is enough of a sysroot already and having subfolders beyond that serves no useful purpose. There is one exception to that though, which with Clang where the same Clang binaries can compile software for many different systems. In that case, suddenly sysroot subfolders are sensible things again. I am fairly sure that some of the sysroot folders that are created do not need to be created too. As for "ln -s", I'm not going to expend effort on that because even if you get it to work nicely, end users of your cross compilers may not have the administrator permissions necessary to create symlinks which makes them quite pointless from a software distribution perspective. I don't think I've patched anything in any way that's destructive to "ln -s" working, but please correct me if I'm wrong in that. |
|
(Includes a mingw-w64 crt build fix at the end of post, you should not build multilib crt when not needed) Instead I have successfully built sysroot=prefix build with winsymlinks:nativestrict, makes muuch cleaner directory architecture gcc-4.8.2-x86_64-w64-mingw32-seh-sysroot-prefix-winsymlinks.tar.xz (extracts with tar -xJvf) Notable patches used: feature-ctng-same-sysroot-and-prefix.patch : same short --with-sysroot and --prefix dirs fix-buildsh-wrong-multilib-condition.patch fix-mingw-only-install-required-lib-arch.patch : It is wrong to assume we all do multilib, you must include the switches to disable the generation of one of both when we dont want multilib |
libc/newlib: Canadian baremetal builds require core pass-1
Built everything in Windows host, builders x86_64-w64-mingw32 and i686-w64-mingw32 (msys2 bases with export PATH=/mingw64/bin:${PATH} before building)
gcc-4.8.2-i686-unknown-linux-dw2 (targets linux 32-bit)
gcc-4.8.2-x86_64-unknown-linux-dw2 (targets linux 64-bit)
gcc-4.8.2-x86_64-w64-mingw32-seh (targets windows 64-bit)
gcc-4.8.2-i686-w64-mingw32-dw2 (targets windows 32-bit)
gcc-5666.3-x86_64-apple-darwin10-dw2 (targets mac 64-bit)
To reproduce
For Ray Donelly:
Most patches are my personal not intended to be pushed but if you think some of them are interesting feel free to re-use at your will
Patch marked as:
update-* => just version updates
srcpatch-* => packages source patches (most are old port to new versions)
fix-* => Patches bugs I have encountered
feature-* => feature I believe missing, whether you statically build or not, you may need both --enable-static and --enable-shared for lib redistributions
Target x86_64-apple-darwin10-dw2:
had a small "Invalid Syntax" issue with Python 3.3 which I have fixed with 150-python-print.patch
Another issue in building final gcc near the end:
fixed by deleting the libc.dylib link and duplicated libSystem.B.dylib and renamed the duplication to libc.dylib
No more issues after that
Target i686-unknown-linux-dw2 / x86_64-unknown-linux-dw2:
at steps libc_start_files and libc you will have to edit the generated file stdio_lim.d which has in it the Windows drive letter which you need to replace in a mingw path, in my case I replace X: to /x
The same for a elf/librtld.map generated file, just need to replace some Windows to unix path
Target Windows : no special issues except one when you use the 32 or 64-bit compiler, it does not find gcc-4.8.2-x86_64-w64-mingw32-seh\lib\gcc\x86_64-w64-mingw32\lib\libgcc_s.a
It first look in X:\libs\gcc-4.8.2-x86_64-w64-mingw32-seh\lib\gcc\x86_64-w64-mingw32\4.8.2 but never in the lib folder near the 4.8.2 one so copying
gcc-4.8.2-x86_64-w64-mingw32-seh\lib\gcc\x86_64-w64-mingw32\lib\libgcc_s.a
to
gcc-4.8.2-x86_64-w64-mingw32-seh\lib\gcc\x86_64-w64-mingw32\4.8.2\libgcc_s.a
fixes the issue
The text was updated successfully, but these errors were encountered: