Re: different linker parameters from similar Makefiles when building MSVC DLLs in cygwin (with erlang wrappers)

[Peter Rosin]

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 <address@hidden> 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