help-gsasl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible issue with static win32 gsasl


From: Simon Josefsson
Subject: Re: Possible issue with static win32 gsasl
Date: Mon, 11 Oct 2010 17:37:12 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux)

Lothar May <address@hidden> writes:

> It seems that both the gsasl x64 static lib as well as the dll contain
> debug information. Is this intended? After running strip.exe on it,
> libgsasl-7.dll has only around 100kB, and still seems to work. Maybe
> the link problem is related to debug information (the DWARF error
> suggests it). However, running strip.exe on a static lib does not seem
> to work.

I think one could argue both ways wrt debug info, thus I think we need
two separate builds -- one with debug info and one without.

There is some complexity in all these options though, we now need 32-bit
debug, 32-bit nondebug, 64-bit debug, 64-bit nondebug, 32-bit KfW debug,
32-bit KfW nondebug...  isn't it possible to build "fat" DLLs under
Windows to reduce this set somewhat?  I.e., with code for both 32-bit
and 64-bit.

Another alternative is to include both 32-bit and 64-bit binaries in the
same ZIP file.  The DLL could be named libgsasl32.dll or libgsasl64.dll
etc.  I dunno about gsasl.exe though, what should it link to?  Or should
there be gsasl32.exe and gsasl64.exe?  Sigh...  Hm.  Under unix systems,
we sometimes use lib64/ for 64-bit code.  One could do the same for the
ZIP-file: use bin32/ and bin64/ and lib32/ and lib64/.  Opinions?  I
kind of like this.  I'll see how difficult it would be to adapt the
build scripts for this variant.  It would simplify things since the
DLL/EXE wouldn't have to be renamed, which is always a pain.

/Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]