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: Lothar May
Subject: Re: Possible issue with static win32 gsasl
Date: Tue, 12 Oct 2010 12:19:36 +0200

Hi Simon,

2010/10/11 Simon Josefsson <address@hidden>:
> 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...

By the way, does the normal build still include libidn? I'm not sure
about this. However, I just set up a linux system so I can also use a
cross compiler now, and build things.

> 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.

I never heard of "fat" DLLs on Windows like they exist on Mac OS...
But a little searching reveals that this might be possible:

http://en.wikipedia.org/wiki/Compound_File_Binary_Format

However, it does not seem to be as integrated in the system as on Mac.

> 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?

That would be fine! How about release/debug? If using the DLL becomes
standard, I can run strip.exe on it, but a non-debug build might be
better considering optimisation. One could also use release/debug
subdirectories, or use different names.

Regards,
Lothar



reply via email to

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