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. ------------------------------------------------------------------------------ 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
