Re: [Wireshark-dev] Building on Windows with CMake: Status and help needed

2013-10-08 Thread Graham Bloice 
On 8 October 2013 00:22, Joerg Mayer  wrote:

> > > > This is undoubtedly about the fact that Makefile.nmake copies lots of
> > > > DLLs and etc to a separate "run" directory.
> > > >
> > > > The exe's won't run from the build dir on Windows.
> > > >
> > > > See install_all: target in Makefile.nmake (top-level)
> > > >
> > > > ...
> > > > # "install-all" will copy all files needed to run Wireshark/Tshark
> > > > # to the INSTALL_DIR, so you can run/debug Wireshark/Tshark from
> there.
> > > > install-all: install-generated-files
> > > > ...
> > >
> > > Dependency Walker (www.dependencywalker.com) is pretty useful for
> > > finding dependent DLLs.
> > >
> > >
> > I forgot to mention that when I mentioned "dumpbin /dependants" earlier.
>
> I think I've found an easier solution to run inside the source tree:
> Just the the PATH variable to all the libdirs. So far I have only tried
> this manually but I've finally managed to run capinfos (and get the
> usage output :-)
> If I find the time I'll add automatic PATH modification tomorrow evening,
> the idea is something like:
> check whether path has already been modified. if not:
> set( ENV{PATH} $ENV{PATH} ${CMAKE_BINARY_DIR}/lib
> )
>
> Feel free to beat me to it ;-)
>
> Good night
>
>
You got there with the idea before me.  I was thinking last night about the
DLL search path (http://msdn.microsoft.com/en-us/library/7d83bc18.aspx)
used by windows, and like you think that just modifying the path will do
the job.  Can that path extension be "exported" to the calling shell so
that a dev can build and then run from the same command prompt?

This actually leads to another bugbear of mine.  All the third party
libraries are extracted to separate directories with random locations for
their includes, import libraries (.lib) and DLL's that really complicates
the windows build.

I think it would be a good idea, when reworking the third party lib
downloader, to arrange for these three components of the third party libs
to all be in a consistent place, e.g. all headers under
.../include/somelib/, all import libs under .../lib and all binaries under
.../bin, similar to the organisation of these items on some other well
known platforms.  This means less messing around with paths to all these
things in CMake.

Graham
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Building on Windows with CMake: Status and help needed

2013-10-07 Thread Joerg Mayer 
> > > This is undoubtedly about the fact that Makefile.nmake copies lots of
> > > DLLs and etc to a separate "run" directory.
> > >
> > > The exe's won't run from the build dir on Windows.
> > >
> > > See install_all: target in Makefile.nmake (top-level)
> > >
> > > ...
> > > # "install-all" will copy all files needed to run Wireshark/Tshark
> > > # to the INSTALL_DIR, so you can run/debug Wireshark/Tshark from there.
> > > install-all: install-generated-files
> > > ...
> >
> > Dependency Walker (www.dependencywalker.com) is pretty useful for
> > finding dependent DLLs.
> >
> >
> I forgot to mention that when I mentioned "dumpbin /dependants" earlier.

I think I've found an easier solution to run inside the source tree:
Just the the PATH variable to all the libdirs. So far I have only tried
this manually but I've finally managed to run capinfos (and get the
usage output :-)
If I find the time I'll add automatic PATH modification tomorrow evening,
the idea is something like:
check whether path has already been modified. if not:
set( ENV{PATH} $ENV{PATH} ${CMAKE_BINARY_DIR}/lib )

Feel free to beat me to it ;-)

Good night

   Jörg

-- 
Joerg Mayer   
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Building on Windows with CMake: Status and help needed

2013-10-07 Thread Graham Bloice 
On 7 October 2013 15:37, Gerald Combs  wrote:

> On 10/6/13 4:35 PM, Bill Meier wrote:
> > On 10/6/2013 7:27 PM, Joerg Mayer wrote:
> >> The executables now compile and link except the gtk and qt guis.
> >> I have not yet been able to run the executables as running the binaries
> >> inside the build tree doesn't seem to work (unlike on linux).
> >> Ideas how to get this to work?
> >>
> >> Thanks
> >> Jörg
> >>
> >
> > This is undoubtedly about the fact that Makefile.nmake copies lots of
> > DLLs and etc to a separate "run" directory.
> >
> > The exe's won't run from the build dir on Windows.
> >
> > See install_all: target in Makefile.nmake (top-level)
> >
> > ...
> > # "install-all" will copy all files needed to run Wireshark/Tshark
> > # to the INSTALL_DIR, so you can run/debug Wireshark/Tshark from there.
> > install-all: install-generated-files
> > ...
>
> Dependency Walker (www.dependencywalker.com) is pretty useful for
> finding dependent DLLs.
>
>
I forgot to mention that when I mentioned "dumpbin /dependants" earlier.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Building on Windows with CMake: Status and help needed

2013-10-07 Thread Gerald Combs 
On 10/6/13 4:35 PM, Bill Meier wrote:
> On 10/6/2013 7:27 PM, Joerg Mayer wrote:
>> The executables now compile and link except the gtk and qt guis.
>> I have not yet been able to run the executables as running the binaries
>> inside the build tree doesn't seem to work (unlike on linux).
>> Ideas how to get this to work?
>>
>> Thanks
>> Jörg
>>
> 
> This is undoubtedly about the fact that Makefile.nmake copies lots of
> DLLs and etc to a separate "run" directory.
> 
> The exe's won't run from the build dir on Windows.
> 
> See install_all: target in Makefile.nmake (top-level)
> 
> ...
> # "install-all" will copy all files needed to run Wireshark/Tshark
> # to the INSTALL_DIR, so you can run/debug Wireshark/Tshark from there.
> install-all: install-generated-files
> ...

Dependency Walker (www.dependencywalker.com) is pretty useful for
finding dependent DLLs.

___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Building on Windows with CMake: Status and help needed

2013-10-06 Thread Bill Meier 

On 10/6/2013 7:27 PM, Joerg Mayer wrote:

The executables now compile and link except the gtk and qt guis.
I have not yet been able to run the executables as running the binaries
inside the build tree doesn't seem to work (unlike on linux).
Ideas how to get this to work?

Thanks
Jörg



This is undoubtedly about the fact that Makefile.nmake copies lots of 
DLLs and etc to a separate "run" directory.


The exe's won't run from the build dir on Windows.

See install_all: target in Makefile.nmake (top-level)

...
# "install-all" will copy all files needed to run Wireshark/Tshark
# to the INSTALL_DIR, so you can run/debug Wireshark/Tshark from there.
install-all: install-generated-files
...

Bill


___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Building on Windows with CMake: Status and help needed

2013-10-06 Thread Joerg Mayer 
The executables now compile and link except the gtk and qt guis.
I have not yet been able to run the executables as running the binaries
inside the build tree doesn't seem to work (unlike on linux).
Ideas how to get this to work?

Thanks
   Jörg
-- 
Joerg Mayer   
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Building on Windows with CMake: Status and help needed

2013-10-06 Thread Graham Bloice 
On 5 October 2013 12:03, Joerg Mayer  wrote:

> Hello,
>
> I've made some progress and am now able to almost build a first 32 bit
> executable with VSEE2010. The executable (capinfos) using nmake as build
> tool.
> The cmake stage (for nmake) is working as much as is needed, i.e. no GUI
> package detection right now.
> Compilation is working, but linking fails:
>   capinfos.c.obj : error LNK2001: unresolved external symbol __imp__optind
>   capinfos.c.obj : error LNK2019: unresolved external symbol __imp__getopt
> referenced in function _main
> I've spent some hours digging into it but everything I've tried has failed.
>
> Other open issues:
> - The same warning over and over again:
>   cl : Command line warning D9025 : overriding '/MD' with '/MDd'
> - Problems with the WS_DLL_PUBLIC mechanism, one out of many examples:
>   C:\wireshark\trunk\epan\plugins.c(31) : warning C4273:
> 'wslua_plugin_list' : inconsistent dll linkage
> c:\wireshark\trunk\epan\plugins.h(65) : see previous definition of
> 'wslua_plugin_list'
>
> My next steps (not necessarily in that order):
> - Try to get the remaining executables as close to linking as possible.
> - GTK3 and GTK2 builds (gtk detection).
> - Is there a recipe for Qt5 builds on Windows (esecially the qt5 package)?
> - Go for 64 bit builds.
>
> If someone feels motivated to help with any of the problems or unfinished
> tasks above or anything else: Go ahead - I don't want a monoploly on this
> ;-)
> Coordination via the list or IRC(freenode) #wireshark?
>
> Full logs of a build of svn revision 52377
> cmake -G "NMake Makefiles" ..\..\trunk
> cmake --build . -- VERBOSE=1
>
> can be found here:
> http://www.loplof.de/kram/cmake.log
> http://www.loplof.de/kram/build.log
>
>
>
Hi Joerg,

I was also working on this yesterday, but I was using CMake to build a
Visual Studio solution (VS2010 Pro).  I was trying to get randpkt to build
and at least one issue you mention (import of getopt) is where I had issues.

The issues I ran into were:

* Needed to add a definition for MSC_VER_REQUIRED to CMakeList.txt.  I
cheated and just hacked in a fixed one for my version
(MSC_VER_REQUIRED=1600).

* randpkt, and a lot of other things depend on wsutil.  CMake doesn't seem
to add a dependency on wsutil though.

* wsutil on windows also requires 5 files to be added
to WSUTIL_PLATFORM_FILES: inet_aton.c, inet_ntop.c, inet_pton.c,
strptime.c, wsgetopt.c

* wsutil requires at least ws2_32.lib to link

I still can't produce a dll yet as the link fails looking for strncasecmp
required by strptime_internal.  This has me stumped.  I checked what the
normal nmake produced dll imports (using dumpbin /imports libwsutil.dll)
and that function isn't listed.  I think it's something to do with all the
macro wizardy in strptime.c

For what it's worth I think the link libs we supply are mostly far beyond
what is needed, for this dll produced by the normal nmake build the
dependences are (using dumpbin /dependents):

Dump of file ..\..\trunk\wireshark-gtk2\libwsutil.dll

File Type: DLL

  Image has the following dependencies:

KERNEL32.dll

WS2_32.dll

ADVAPI32.dll

SHELL32.dll

libglib-2.0-0.dll

libgmodule-2.0-0.dll

libgcrypt-11.dll

MSVCR100.dll

  Summary

1000 .data

C000 .rdata

1000 .reloc

1000 .rsrc

   11000 .text


I've also attached the build output for the dll from the normal nmake build
and the CMake generated VS2010 build for comparison as there must be a
vital difference somewhere.
cl -WX /DPCAP_VERSION=4_1_3 /Zi /W3 /MD /DWIN32_LEAN_AND_MEAN 
/DMSC_VER_REQUIRED=1600  /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE 
-DPSAPI_VERSION=1 /D_BIND_TO_CURRENT_CRT_VERSION=1 /MP /GS /w34295  /I. /I.. 
/IE:\Wireshark\wireshark-win32-libs\gtk3\include\glib-2.0  
/IE:\Wireshark\wireshark-win32-libs\gtk3\lib\glib-2.0\include  
-DG_DISABLE_DEPRECATED  -DG_DISABLE_SINGLE_INCLUDES 
/IE:\Wireshark\wireshark-win32-libs\gnutls-2.12.18-1.2-win32ws\include 
/DNOCRYPT /DIMPORT_LIGNUTLSDLL  
/IE:\Wireshark\wireshark-win32-libs\WPdpack\include -DWS_BUILD_DLL -Fd.\ -c 
file_util.c inet_aton.c inet_ntop.c inet_pton.c aes.c airpdcap_wep.c 
crash_info.c crc6.c crc7.c crc8.c crc10.c crc11.c crc16.c crc16-plain.c crc32.c 
crcdrm.c des.c eax.c g711.c md4.c md5.c mpeg-audio.c nstime.c privileges.c 
sha1.c strnatcmp.c str_util.c swar.c rc4.c report_err.c tempfile.c type_util.c 
u3.c strptime.c unicode-utils.c wsgetopt.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

file_util.c
inet_aton.c
inet_ntop.c
inet_pton.c
aes.c
airpdcap_wep.c
crash_info.c
crc6.c
crc7.c
crc8.c
crc10.c
crc11.c
crc16.c
crc16-plain.c
crc32.c
crcdrm.c
des.c
eax.c
g711.c
md4.c
md5.c
mpeg-audio.c
nstime.c
privileges.c
sha1.c
strnatcmp.c
str_util.c
swar.c
rc4.c
report_err.c
tempfile.c
type_util.c
u3.c
strptime.c
unicode-utils.c
wsgetopt.c
link  /INCREMENTAL:NO /NOL

[Wireshark-dev] Building on Windows with CMake: Status and help needed

2013-10-05 Thread Joerg Mayer 
Hello,

I've made some progress and am now able to almost build a first 32 bit
executable with VSEE2010. The executable (capinfos) using nmake as build tool.
The cmake stage (for nmake) is working as much as is needed, i.e. no GUI
package detection right now.
Compilation is working, but linking fails:
  capinfos.c.obj : error LNK2001: unresolved external symbol __imp__optind
  capinfos.c.obj : error LNK2019: unresolved external symbol __imp__getopt 
referenced in function _main
I've spent some hours digging into it but everything I've tried has failed.

Other open issues:
- The same warning over and over again:
  cl : Command line warning D9025 : overriding '/MD' with '/MDd'
- Problems with the WS_DLL_PUBLIC mechanism, one out of many examples:
  C:\wireshark\trunk\epan\plugins.c(31) : warning C4273: 'wslua_plugin_list' : 
inconsistent dll linkage
c:\wireshark\trunk\epan\plugins.h(65) : see previous definition of 
'wslua_plugin_list'

My next steps (not necessarily in that order):
- Try to get the remaining executables as close to linking as possible.
- GTK3 and GTK2 builds (gtk detection).
- Is there a recipe for Qt5 builds on Windows (esecially the qt5 package)?
- Go for 64 bit builds.

If someone feels motivated to help with any of the problems or unfinished
tasks above or anything else: Go ahead - I don't want a monoploly on this ;-)
Coordination via the list or IRC(freenode) #wireshark?

Full logs of a build of svn revision 52377
cmake -G "NMake Makefiles" ..\..\trunk
cmake --build . -- VERBOSE=1

can be found here:
http://www.loplof.de/kram/cmake.log
http://www.loplof.de/kram/build.log

Ciao
   Jörg
-- 
Joerg Mayer   
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe