Nut upsdev - Oct 2010 - cross-compiling the windows_port branch (socklen_t)

Fr?d?ric,

I'm curious as to how you are configuring the windows_port branch.  
When I try to cross-compile, configure complains about socklen_t:

$ ./configure --host=i686-pc-mingw32
Network UPS Tools version 2.4.3
[...]
checking for socklen_t... no
checking for socklen_t equivalent... configure: error: Cannot find a  
type to use in place of socklen_t

The test (m4/nut_type_socklen_t.m4) is only looking in sys/types.h and  
sys/socket.h, which don't exist in either of the two mingw32 cross- 
compiler setups that I have tried (on Ubuntu 10.04 and Fink).

I am unsure as to whether rsync (the apparent source of that autoconf  
test) will properly compile on mingw32.

We might be able to do something like this, but I am open to other  
ideas (and I am not suggesting we depend on gnulib):

http://www.mail-archive.com/bug-gnulib at gnu.org/msg01920.html

On mer., 2010-10-20 at 09:05 -0400, Charles Lepple
wrote:
> Fr?d?ric,
> 
> I'm curious as to how you are configuring the windows_port branch.  
> When I try to cross-compile, configure complains about socklen_t:
> 
> $ ./configure --host=i686-pc-mingw32
> Network UPS Tools version 2.4.3
> [...]
> checking for socklen_t... no
> checking for socklen_t equivalent... configure: error: Cannot find a  
> type to use in place of socklen_t
> 
> The test (m4/nut_type_socklen_t.m4) is only looking in sys/types.h and  
> sys/socket.h, which don't exist in either of the two mingw32 cross- 
> compiler setups that I have tried (on Ubuntu 10.04 and Fink).
> 
> I am unsure as to whether rsync (the apparent source of that autoconf  
> test) will properly compile on mingw32.
> 
> We might be able to do something like this, but I am open to other  
> ideas (and I am not suggesting we depend on gnulib):
> 
> http://www.mail-archive.com/bug-gnulib at gnu.org/msg01920.html
Indeed, the current configure.in has a number of issues.
They are related to :
	- libusb detection
	- libneon detection
	- linking to regex
	- duplication of DATADIR macro
	- definition of socklen_t
	- inet_aton detection

Arnaud is currently working on all this.

The way I use to build the project is by commenting out faulty macros in
configure.in and adding LIBS=-lregex to the configure command line (and
--without-serial too, because those drivers has not been ported yet).
Not the clean way but it is just a temporary workaround while waiting
for Arnaud's commit.

regards,
Fred

--------------------------------------------------------------------------

On Oct 20, 2010, at 9:30 AM, Fr?d?ric Boh? wrote:
> 	- definition of socklen_t
Looks like the fix in r2659 is working for the cross-compiler.

How is winevent.h generated? (From the #include in common/wincompat.c,  
I assume it is not part of the standard include files.)

It is generated from the winevent.mc file.
This is what I do to work with windows event log (Registry edition will
be done by an installer in the future. Arnaud is working on automatic
winevent.h and winevent.dll generation):

Run the following commands :

windmc winevent.mc
windres winevent.rc winevent.o
dllwrap --output-lib=libwinevent.a --dllname=winevent.dll
--driver-name=gcc winevent.o


Create the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Services\EventLog\Application\<Service Name> and add the following
registry values to this key :
Value	Type	Description
EventMessageFile = dll_path	REG_SZ	The path to the resource-only DLL
that contains strings that the service can write to the event log.
TypesSupported = 0x00000007	REG_DWORD	A bit mask that specifies the
supported event types. The value 0x000000007 indicates that all types
are supported.


On mer., 2010-11-03 at 21:21 -0400, Charles Lepple
wrote:
> How is winevent.h generated? (From the #include in common/wincompat.c,  
> I assume it is not part of the standard include files.)

--------------------------------------------------------------------------