On 9/9/2010 19:45, Mario Emmenlauer wrote: >> 2010/9/9 JonY<jo...@users.sourceforge.net>: >>> On 9/9/2010 12:36, Nils Woetzel wrote: >>>>>> cd gcc-4.5.1-build >>>>>> ln -s /mypath/x86_64-w64-mingw32 ./mingw >>>>>> >>>>>> assuming, that you are building/configuring gcc in the folder >>>>>> gcc-4.5.1-build - otherwise whatever path >>>>>> I guess the howto assumes that /mypath is also the configure and >>>>>> build >>>>>> directory, than you do not have that problem, but if your >>>>>> build/configure directory is somewhere totally else, than gcc does >>>>>> not >>>>>> know here to find the mingw folder >>>>>> >>>>>> make and make install runs smoothly afterwards!! >>>>>> >>>>> >>>>> No, the symlink is done after install, you shouldn't be doing any >>>>> symlinks during build time, unless I am misunderstanding something. >>>> >>>> I am not sure, what is right, but this is what the howto says: >>>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/branches/releases/v1.0/mingw-w64-doc/howto-build/mingw-w64-howto-build.txt?revision=3506&view=markup >>>> line 230 and following: >>>> 230 Step 3) GCC requires the x86_64-w64-mingw32 directory be mirrored >>>> as a >>>> 231 directory 'mingw' in the same root. So, if using configure >>>> default >>>> 232 /usr/local, type: >>>> 233 ln -s /usr/local/x86_64-w64-mingw32 /usr/local/mingw >>>> 234 or, for sysroot, type: >>>> 235 ln -s /mypath/x86_64-w64-mingw32 /mypath/mingw >>>> 236 >>>> 237 Step 4) Manually create the x86_64-w64-mingw32/lib directory: >>>> 238 mkdir -p /usr/local/x86_64-w64-mingw32/lib >>>> 239 or, for sysroot: >>>> 240 mkdir -p /mypath/x86_64-w64-mingw32/lib >>>> 241 If it already exists and you get an error, ignore it. >>>> 242 >>>> 243 Step 5) Symlink x86_64-w64-mingw32/lib directory as >>>> x86_64-w64-mingw32/lib64: >>>> 244 ln -s /usr/local/x86_64-w64-mingw32/lib >>>> /usr/local/x86_64-w64-mingw32/lib64 >>>> 245 or, for sysroot: >>>> 246 ln -s /mypath/x86_64-w64-mingw32/lib >>>> /mypath/x86_64-w64-mingw32/lib64 >>>> >>> >>> yes, those are the symlinks done after install-gcc target and crt is >>> install. There are no manually created symlinks in the build directory. >>> >>>>>> After make install, the last thing I did was, to make symlinks in >>>>>> sysroot or prefix >>>>>> ln -s /mypath/lib/gcc/x86_64-w64-mingw32/lib32/libgcc_s.a >>>>>> /mypath/x86_64-w64-mingw32/lib32/ >>>>>> and >>>>>> ln -s /mypath/lib/gcc/x86_64-w64-mingw32/lib64/libgcc_s.a >>>>>> /mypath/x86_64-w64-mingw32/lib64/ >>>>>> >>>>>> compiler and linker works (at least -m32, I have not tried the 64bit) >>>>>> >>>>> >>>>> This is a known issue when --enable-runtime-specific-libs is used, >>>>> happens in Linux as well. >>>>> >>>> >>>> I did configure with --enable-runtime-specific-libs so this makes >>>> sense - I was not aware that would be the consequence.. >>>> >>>>>> There are only warnings, but ultimately, the error is: >>>>>> /blue/meilerlab/apps/Linux2/x86_64/mingw-w64/2010.09.07/x86_64-w64-mingw32/bin/ld: >>>>>> cannot find -lmingw32 >>>>>> >>>>>> the same for: >>>>>> -lmingwex, -lmoldname, -lmsvcrt, -luser32, -lkernel32, -ladvapi32, >>>>>> -lshell32 >>>>>> >>>>> >>>>> This does not occur for me. Perhaps you want to try >>>>> --with-build-sysroot. >>>>> >>>> >>>> I tried building binutils and gcc with --with-build-sysroot, and the >>>> stage 2 gcc will fail with that error: >>>> The directory that should contain system headers does not exist: >>>> yes/mingw/include >>>> >>>> so I assume, that I have to specifically pass the sysroot, that I also >>>> passed to --with-build-sysroot=/mypath >>>> >>>> but when I do this for binutils and gcc I get this error: >>>> float.h .. error: #error Corrupt install of gcc's internal headers, or >>>> search order was changed. >>>> >>>> There is something I still do not understand. >>>> >>> >>> I think Kai just fixed this error, but I'm not sure. Kai do you know the >>> nature of this error? >>> >>>>>> The problem is, xgcc does not know about the lib32 mypath - when >>>>>> calling >>>>>> /blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/./gcc/xgcc >>>>>> -m32 --print-search-dirs >>>>>> >>>>>> this is the output >>>>>> libraries: >>>>>> =/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/../lib/gcc/x86_64-w64-mingw32/4.5.1/32/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/../lib/gcc/32/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.1/32/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/lib/../lib32/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/..//mingw/lib/x86_64-w64-mingw32/4.5.1/32/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/..//mingw/lib/../lib32/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/../lib/gcc/x86_64-w64-mingw32/4.5.1/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32 >>> /g >>>>> cc-4.5.1/gcc/../lib/gcc/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.1/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/lib/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/..//mingw/lib/x86_64-w64-mingw32/4.5.1/:/blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/gcc/..//mingw/lib/ >>>>>> >>>>>> it only list the builddir subfolders of: >>>>>> /blue/meilerlab/apps/Linux2/src/mingw-w64/build/x86_64-w64-mingw32/gcc-4.5.1/ >>>>>> but my sysroot and prefix are both: >>>>>> /blue/meilerlab/apps/Linux2/x86_64/mingw-w64/2010.09.07/ >>>>>> and that is where everything is installed >>>>>> >>>>> >>>>> Thats because uninstalled gcc works by searching directory by relative >>>>> paths. >>>> >>>> I guess I understand that, but how does the uninstalled xgcc know >>>> about the mingw include and lib, lib32, lib64 directory - if it just >>>> searches in the source or build directory? Where does the build >>>> directory have to be relative to the mingw folder? >>>> >>> >>> xgcc is normally called with -B...path, -L and such, so it normally >>> finds its libraries. >>> >>>>> I tried a recent 4.6 gcc build, I didn't need to do this. >>>> >>>> I tried the mingw source distro with gcc and binutils packaged from >>>> 20100907 but I could not get it work. >>>> I guess we will have to wait for answers from other people having >>>> similar problmes building the cross compiler. >>>> >>>> I guess I can give some details on my system: >>>> uname -a >>>> Linux hostname 2.6.18-164.15.1.el5 #1 SMP Wed Mar 17 11:30:06 EDT 2010 >>>> x86_64 x86_64 x86_64 GNU/Linux >>>> on this system I want to compile the cross compiler for mingw-w64 >>>> multilib, and I do not have root rights (It is actually going to be >>>> installed in a network share, so I have to use prefix and >>>> with-sysroot) >>>> >>>> Thanks for your help though and for the good work on the mingw-w64! >>>> Compiling with VisualStudio just takes hours for our project, and with >>>> the gcc cross compiler, we can use distcc and it compiles in 5 >>>> minutes! and links in 1 minute! >>> >>> You could try the auto-builds for linux, but I think you need a fairly >>> recent glibc installed. >>> >> >> Well, for 4.6 the include order had changed and cause by a typo (of >> myself) if failed badly for float.h. This is fixed on our trunk. >> Yeah, binutils HEAD changed for 64-bit windows target. It enables by >> default 32-bit support too. This seems to lead to some issue in our >> crt make. I noticed that yesterday, too. By giving our configure >> explicit the options '--disable-lib32 --enable-lib64' I could solve >> this issue. > > Ok, that could be the indicator. I will try later today. The only thing > that still worries me is that I had originally reported the error months > ago - was binutils changed that long ago? > Either way, I will try. Could this also be added to makebuildroot-test.mk? > > Thanks Kai and JonY, and all the best, > > Mario
I will make makebuildroot-test.mk more explicit with crt configure soon. ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
