On 3/24/2010 20:15, Sisyphus wrote: > Hi, > > I've posted to gsl-bugs about this ... without success. I'm not even sure > that it's a gsl bug - there's a thread at > http://www.mail-archive.com/[email protected]/msg00374.html where the > error is of a very similar type. In that particular instance it turned out > to be a libtool (ltmain.sh) bug. However, I've been unable to adapt the > ltmain.sh patch that worked there to my particular situation. > > No problems with a dynamic build of gsl-1.14, btw ... it's just the static > build that's being uncooperative. > > When trying to build a static gsl-1.14 library with mingw64 in the MSYS > shell, I start with: > > $ ./configure --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 > CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ > AR=x86_64-w64-mingw32-ar > LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm > RANLIB=x86_64-w64-mingw32-ranlib --disable-shared --enable-static&& make > > (For the dynamic build I use the same, except that it's > "--disable-static --enable-shared".) > Everything is fine until we get near the end of the make process, when this > happens: > > ########################## > /bin/sh ./libtool --tag=CC --mode=link > x86_64-w64-mingw32-gcc -g -O2 -version-info 15:0:15 -no-undefined -o > libgsl.la -rpath /usr/local/lib version.lo block/libgslblock.la > blas/libgslblas.la bspline/libgslbspline.la > [SNIP lots of other.la files] > wavelet/libgslwavelet.la cblas/libgslcblas.la -lm > libtool: link: (cd .libs/libgsl.lax/libgslblock.a&& x86_64-w64-mingw32-ar x > "/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a") > libtool: link: object name conflicts in archive: > .libs/libgsl.lax/libgslblock.a//c/_64/comp/gsl-1.14/block/.libs/libgslblock.a > make[2]: *** [libgsl.la] Error 1 > make[2]: Leaving directory `/c/_64/comp/gsl-1.14' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/c/_64/comp/gsl-1.14' > make: *** [all] Error 2 > ########################### > > The 'cd .libs/libgsl.lax/libgslblock.a&& x86_64-w64-mingw32-ar x > "/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a"' command apparently > succeeds - the 3 > object files in libgslblock.a are to be found in the > .libs/libgsl.lax/libgslblock.a/ folder. > > Does that error mean anything to anyone here ? > Any advice on something I could try to get around it ? > > My "x86_64-w64-mingw32-gcc -v" is provided below my sig. > > Cheers, > Rob > > r...@desktop2 ~ > $ x86_64-w64-mingw32-gcc -v > Using built-in specs. > Target: x86_64-w64-mingw32 > Configured with: > ../../../build/gcc/gcc/configure --target=x86_64-w64-mingw32 > --prefix=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root > > --with-sysroot=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root > --with-gmp=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/gmp/install > > --with-mpfr=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpfr/install > > --with-mpc=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpc/install > --enable-languages=all,obj-c++ --enable-fully-dynamic-string > --disable-multilibThread model: win32gcc version 4.4.4 20100208 > (prerelease)(GCC) >
Hi, Strange, there should not be any folders below .libs. this sounds like an MSYS issue, what happens if you used something like "--prefix=c:/_64"? Failing that, try building out of tree. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
