> 2010/9/9 JonY <[email protected]>: >> 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 ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
