Hi Dave, Please keep replies on the list. Thanks!
Den 2011-06-29 04:20 skrev Dave Cottlehuber: >> Den 2011-06-28 13:47 skrev Dave Cottlehuber: >>> Hi libtoolers, >>> >>> I am building 2 Win32 DLLs to be loaded into the erlang runtime VM as NIFs, >>> based on snappy (mixed C & C++) and ejson/yajl (in C), all part of porting >>> latest CouchDB trunk to Windows - config is at [8]. >>> >>> They use a similar Makefile.am [2],[3] and share configure.ac [1], but >>> during >>> compile & linking ejson succeeds [7] and snappy doesn't [6], despite the >>> Makefiles being almost identical. >>> >>> There are 2 errors reported; >>> - output filename is specified twice & therefore fails >>> >>> LINK : fatal error LNK1149: output filename matches input >>> filename 'C:\cygwin\relax\git_couch\src\snappy\.libs\snappy_nif.dll' >>> >>> - libtool adds unwanted flags, instead of -DLL (per working build) >>> >>> LINK : warning LNK4044: unrecognized option '/shared'; ignored >>> LINK : warning LNK4044: unrecognized option '/nostdlib'; ignored >>> LINK : warning LNK4044: unrecognized option >>> '/-enable-auto-image-base'; ignored >>> LINK : warning LNK4044: unrecognized option '/Xlinker'; ignored >>> LINK : warning LNK4044: unrecognized option '/-out-implib'; ignored >>> LINK : warning LNK4044: unrecognized option '/Xlinker'; ignored >>> >>> Only the final link phases differ materially in the parameters passed. If >>> [7] is >>> manually run with these changes, bringing it into line with [6], it works: >>> >>> - remove '-Xlinker --out-implib -Xlinker \$lib' >>> - swap '-shared -nostdlib' ' for '-dll' >>> >>> When libtool is hacked up [4], I can get a cleanish link [5] but this >>> clearly >>> isn't the Right Thing To Do. >>> >>> What do I need to change, to ensure libtool passes the linker the same >>> options >>> in both DLLs? What am I missing? >>> >>> Finally, given we are using these makefiles/configure.ac on multiple >>> platforms >>> have you got any other suggestions to improve things? >>> Thanks, >>> Dave > On 29 June 2011 02:00, Peter Rosin <p...@lysator.liu.se> wrote: > > Thanks Peter for your reply. Inline. > >> Lots of questions. Here's a a couple of my questions... >> What is cc.sh? Some kind of wrapper I suppose? > yup, provided with Erlang/OTP as part of their build chain under > windows & other platforms. Is cc.sh available for anyone to have a peek at it? >> Have you checked how the libtool testsuite fares when run with that wrapper? > Built from git; passes make -k without issue. In that case, why do you need the -k option? Did you imply the "check" argument to make or are you only saying that you can build libtool without issue? >> Have you tried to build with MinGW? > No; Erlang doesn't AFAIK work under MinGW yet. > > >> How did you configure the different packages? > Only CouchDB gets a configure; the rest are part of the couch source tree: > > ./configure \ > --prefix=$ERL_TOP/release/win32 \ > --with-erlang=$ERL_TOP/release/win32/usr/include \ > --with-win32-icu-binaries=/relax/icu \ > --with-win32-curl=/relax/curl \ > --with-openssl-bin-dir=/relax/openssl/bin \ > --with-msvc-redist-dir=/relax \ > --with-js-lib=/relax/tracemonkey-57a6ad20eae9/js/src/dist/lib \ > --with-js-include=/relax/tracemonkey-57a6ad20eae9/js/src/dist/include \ > 2>&1 | tee $COUCH_TOP/build_configure.txt How is the compiler selected as cc.sh? I wouldn't guess that autoconf would find a compiler named cc.sh without help. >> In my experience, attempting to write ad-hoc wrappers that makes MSVC look >> like gcc is not what works best. I dearly recommend that you ditch the > > Agreed but I'm not in a position to do that without breaking how > Erlang is built :-( > >> cc.sh wrapper and instead use the compile wrapper from automake and trigger >> its use with AM_PROG_CC_C_O in your configure.ac. Unfortunately you need >> to get copies of a recent version the compile wrapper from the Automake git >> repository (master branch, in the lib subdir). Also grab the ar-lib wrapper >> script from there. Then configure your packages along these lines: >> >> .../configure CC="cl -nologo" CFLAGS=-MD CXX="cl -nologo" CXXFLAGS=-MD >> LD=link AR=/path/to/ar-lib NM="dumpbin -symbols" STRIP=: RANLIB=: > > The Erlang scripts already use these flags but passed through in the > scripts themselves. Would you mind clarifying a bit what the above > should do differently? Yes, they probably do, but not in a way that libtool sees them, at least not for C++ (snappy). > While I agree with your points, I still don't see where in libtool > source it decides _not_ to use '-dll' (as it does on the working > ejson), and switches on '-shared -nostdlib' and '-Xlinker -out-implib > -Xlinker \$lib'. The wrapper scripts etc are a mess but the different > behaviour in libtool seems like a good place to fix the underlying > issue - almost certainly an upstream one! The reason it is failing for snappy seems to be that the CXX tag is configured differently from the CC tag. --tag=CC is working, --tag=CXX is not. For CXX, libtool appears to choose the "gcc path" through libtool which is why you get these -shared -nostdlib options etc, but you have not provided enough detail for me to figure out why the two tags differ. > If some light can be shed on this, the whole mess above can be worked > around. Having a reliance on libtool git master is not going to > simplify the build chain for CouchDB, and for me that's the primary > reason for using autotools. Cheers, Peter _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
