On 9/9/2010 08:00, Xiaofan Chen wrote: > On Tue, Sep 7, 2010 at 8:00 PM, Xiaofan Chen<[email protected]> wrote: >> On Tue, Sep 7, 2010 at 10:36 AM, JonY<[email protected]> wrote: >>> >>> Ok, to clear everything up, for non-multilib 4.6, you should only have >>> "lib", "lib64" only if you have non-multilib 4.5. >>> >> >> It seems the latest automatic build version still has the same issue >> as previous versions, I just checked the following one. It has the same >> non-linked lib64 directory with a few files, same issue as the previous >> mingw-w64-1.0-bin_i686-mingw_20100702.zip and private build >> mingw-w64-bin_i686-mingw_20100711_sezero.zip. >> >> In this case, I will have issues to build libusb-1.0 Windows backend. >> >> The problem is that in this case, the generated libtool script seems to >> want to use lib64. >> >> # Compile-time system search path for libraries. >> sys_lib_search_path_spec="d:/work/mingw-w64/mingw-w64-1.0-bin_i686-mingw_20100906/lib/gcc/x86_64-w64-mingw32/4.5.2 >> d:/work/mingw-w64/mingw-w64-1.0-bin_i686-mingw_20100906/lib/gcc >> d:/work/mingw-w64/mingw-w64-1.0-bin_i686-mingw_20100906/x86_64-w64-mingw32/lib64 >> >> D:\work\mingw-w64\mingw-w64-1.0-bin_i686-mingw_20100906>bin\x86_64-w64-mingw32-gcc >> -v >> Using built-in specs. >> COLLECT_GCC=bin\x86_64-w64-mingw32-gcc >> COLLECT_LTO_WRAPPER=d:/work/mingw-w64/mingw-w64-1.0-bin_i686-mingw_20100906/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.2/lto-wrapper.exe >> Target: x86_64-w64-mingw32 >> Configured with: ../../../build/gcc/src/configure >> --target=x86_64-w64-mingw32 >> --prefix=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/ >> build/root >> --with-sysroot=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root >> --enable-languages=all,obj-c++ --enable-fully-dyna >> mic-string --disable-multilib >> Thread model: win32 >> gcc version 4.5.2 20100906 (prerelease) (GCC) >> >> You can see that it has disabled multilib. >> >> D:\work\mingw-w64\mingw-w64-1.0-bin_i686-mingw_20100906>dir >> x86_64-w64-mingw32 /w >> [.] [..] .mkdir.marker [bin] >> [include] [lib] [lib32] [lib64] >> >> D:\work\mingw-w64\mingw-w64-1.0-bin_i686-mingw_20100906>dir >> x86_64-w64-mingw32\lib64 /w >> [.] [..] libgcc_s.dll.a >> libgfortran.a libgfortran.dll.a >> libgfortran.la libiberty.a libobjc.a >> libobjc.dll.a libobjc.la >> libssp.a libssp.dll.a libssp.la >> libssp_nonshared.a libssp_nonshared.la >> libstdc++.a libstdc++.dll.a >> libstdc++.dll.a-gdb.py libstdc++.la libsupc++.a >> libsupc++.la >> > > > Can this be fixed and lib64 directory be removed? >
If you have moved them and lib64 becomes empty, yes. > Another thing, typically other MinGW-w64 binaries for WIndows > will have gcc along with x86_64-w64-mingw32-gcc.exe and other > similar links. But the automatic build does not have that. > You should not be using "gcc", but x86_64-w64-mingw32-gcc instead. It is a cross compiler. > One good thing is that mingw_i686 version is now provided > (mingw-w64-1.0-bin_i686-mingw_20100906.zip). Thanks. Just > wondering if it is better to have a 64bit Windows build as well > (like http://www.drangon.org/mingw/ ). 64bit Linux build is > provided along with 32bit Linux. > I don't know about 64bit windows builds, but there is no benefit from using 64bit compilers, unless you need more than 4GB to process your sources. Its a low priority for now, we really lack manpower. ------------------------------------------------------------------------------ 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
