On Wed, Mar 24, 2010 at 1:26 PM, JonY <[email protected]> wrote: > 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. >
Sure there should - he's building a static library. This means that libtool will extract all the archive members from the dependent (convience/static) libraries and add them to the final library. ------------------------------------------------------------------------------ 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
