From: Ronnie Sahlberg
| Oliver Biot wrote:
| >Thanks to Stephen Blackheath's hints I eventually succeeded in
building an
| >Ethereal version that is linked against "native Win32" libraries.
If you
| >drop the so-built ethereal.exe in an existing Ethereal installation
| >directory (e.g., "C:\Program Files\Ethereal"), then it runs
smoothly (and
| >*much* faster than a cygwin binary). For some symbols you still
need
| >cygwin1.dll so drop that library too in the same directory as
| >ethereal.exe).
| >
| >The only trick is to compile the whole Ethereal code with
"-mms-bitfields"
| >and then to *manually* fix the final libtool that builds Ethereal
by
| >replacing all occurrences of cygwin libraries (in /usr/local/lib...
or
| >/usr/lib/... or even -l<lib>) with the native Win32 libraries
(which I put
| >in /target/lib/).
|
| VERY cool. Are you planning to update the build scripts in cvs with
these
| changes so that it will build Cygwin with the native libraries by
default?
That's on my TODO list :)
However fixing the libtool library expansion is very hard. Currently I
am thinking of performing a "hard" replacement of "-lpcre" with
"/target/lib/pcre-4.4/lib/libpcre.dll.a" etc., as using "-lpcre"
yields "/target/lib/pcre-4.4/lib/.libs/libpcre.a" which does not
exist. Additionally this "lib/.libs" path fragment does not appear
anywhere (not even within the libraries) so I have really no idea on
what goes wrong here...
| The reason Im asking is that it may be much easier to build Heimdal
| kerberos under cygwin than porting it to windows. And if we used
| Cygwin compiled versions of ethereal using native GTK etc DLLs
| this would make it possibly for us to reasonably easily start
getting
| a version of ethereal running under windows that support
| kerberos decryption.
And another *very* important reason to do so is the increased
performance. When running cygwin Ethereal, it runs slowly because of
the slow cygwin interface (Win32 path conversion to *NIX patchs and
the opposite way takes ages).
Regards,
Olivier