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

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.

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

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

Reply via email to