Network library patches

Johan Tibell johan.tibell at gmail.com
Tue Apr 20 09:27:59 EDT 2010


Hi Neil,

I had a little bit of time to look into this today. Unfortunately I
don't have a solution for your problem yet.

On Wed, Mar 24, 2010 at 7:33 AM, Neil Mitchell <ndmitchell at gmail.com> wrote:
> Agreed. Alas, that is not me. If the platform has network, then
> someone in the platform team might be best. If network was in the
> platform and worked reliably then I'd rather never compile/install
> network, since I usually use it only as a dependency to other packages
> I use.

Network is in the platform and has been since the start. Are you
seeing problems when installing the platform as well?

The platform team cannot maintain the packages in the platform, there
are too many packages and the list is expected to grow (while the
platform group most likely won't grow by much).

> I know my fix is Windows only, I wasn't aiming for portability, just
> simplicity. As Claus subsequently said,
> --configure-option="--host=i386-unknown-mingw32" makes it work for me,
> so perhaps the configure script is getting the wrong platform?

Here are the relevant lines from network's configure.ac:

case "$host" in
*-mingw32)
	EXTRA_SRCS="cbits/initWinSock.c, cbits/winSockErr.c, cbits/asyncAccept.c"
	EXTRA_LIBS=ws2_32
	CALLCONV=stdcall ;;
*-solaris2*)
	EXTRA_SRCS="cbits/ancilData.c"
	EXTRA_LIBS="nsl, socket"
	CALLCONV=ccall ;;
*)
	EXTRA_SRCS="cbits/ancilData.c"
	EXTRA_LIBS=
	CALLCONV=ccall ;;
esac
AC_SUBST([CALLCONV])

If anyone could figure out a better test than this we could change it.

Cheers,
Johan


More information about the Libraries mailing list