SOCKLEN_T not defined when compiling with mingw32.

[mgautier]

Cross compilation of xapian fails when cross-compiling from linux to windows using mingw32.

To provided patch fix the compilation. Another way to fix it is to replace SOCKLEN_T with int as it is how it is defined in ws2tcpip.h

[Olly Betts]

Thanks, will apply.

Interestingly we have a native mingw32 build on appveyor which is happy:

​https://ci.appveyor.com/project/ojwb/xapian/builds/46813181

(The one failure there appears to be bogus - it got "bad address" running the lemon parser generator which we seem to fail with occasionally.)

Is the mingw32 cross-compiler easy to install on Ubuntu? We could have a CI build of the cross-compiler if so.

[Olly Betts]

SOCKLEN_T is probed by configure, using the XAPIAN_TYPE_SOCKLEN_T macro defined in m4/xapian_type_socklen_t.m4 which tries to compile:

$t len;
getsockopt(0, 0, 0, 0, &len);

with $t being each of socklen_t, int, size_t, unsigned, long, unsigned long in turn until it finds one which works.

I think you must be getting SOCKLEN_T set to socklen_t (since if socklen_t isn't defined in the probe it'll fail with that then succeed with int) so we should be able to just leave the SOCKLEN_T alone and sort out why socklen_t isn't available here. Changing SOCKLEN_T to socklen_t here would likely break the build with MSVC. Changing to int would work but seems less future-proof, and given we already have the machinery for probing for this why bake in an assumption for a particular platform?

The headers used for the probe are:

        #include <sys/types.h>
        #if defined __WIN32__ || defined _WIN32
        # include <winsock2.h>
        #else
        # include <sys/socket.h>
        #endif

safewinsock2.h just includes safewindows.h before <winsock2.h> (because otherwise <winsock2.h> can include <windows.h> without our various workarounds for its stupidities), so probably we can just include <sys/types.h> here to fix this in a way which matches how we probed SOCKLEN_T?

[Olly Betts]

Is the mingw32 cross-compiler easy to install on Ubuntu? We could have a CI build of the cross-compiler if so.

I've added a pair of CI builds using the mingw-w64 cross-compilers which are in the Ubuntu repos (one's 32-bit, the other 64-bit). They currently only build xapian-core and don't try to run tests (which we probably could do using wine).

These both work with the current code, i.e. they don't hit your problem.

If I follow you're using mingw rather than mingw-w64 but I don't see an easy way to install a cross-compiler for that, and the native build we have on appveyor using mingw works.

[Olly Betts]

I've aligned the build-time header inclusion with that in the configure probe in [d2080b2feae47c9a263611e32244c6ebe7976755], which I think will resolve this problem (and even if it doesn't, it's a sensible change from a robustness point of view).

Can you confirm that patch works for you?

Also still interested in whether there's an easy way to get your cross-compiler setup in CI...

[Olly Betts]

Backported for 1.4.23 in 5d4a872397519737a06b30afe433e1332c3e64b8.

[mgautier]

Will test the patch.

Also still interested in whether there's an easy way to get your cross-compiler setup in CI...

The cross-compiler is the one provided by fedora.

Here a small dockerfile trying to compile xapian (and failing) on fedora cross-compiling. This is based on our dockerfile with use so it may install a few extra tools

[mgautier]

The patch does not fix the issue.

(I will upload new dockerfile which applies the patch)

[mgautier]

Dockerfile applying patch

[Olly Betts]

I've got a rough and ready CI job which runs on GHA inside a fedora docker container based on your dockerfile, which passes for git master:

​https://github.com/xapian/xapian/actions/runs/5360650495/jobs/9725777740

Now this is working I'll clean it up and merge it and then try it for RELEASE/1.4.

[Olly Betts]

Merged the new CI test to master.

Testing a backport to RELEASE/1.4 I get a different failure, it seems due to clashing definitions of byte:

​https://github.com/xapian/xapian/actions/runs/5366386860/jobs/9735784430

This isn't a clash with a definition of byte in our code as we eliminated our own byte typedef a while back in f527b61a65f259ce68b11ef9d89a959f5cf62a12 due to clashes with C++17 std::byte (there's still a byte typedef in the Snowball compiler, but that's compiled as C and doesn't use any platform-specific headers).

[Olly Betts]

Your SOCKLEN_T problem is triggered by using --disable-backend-remote - some support code in common/socket_utils.cc is still built, but fails because the configure probe for SOCKLEN_T hasn't been run so SOCKLEN_T isn't defined. This only manifests under WIN32 as the wrapper function in safesyssocket.h which uses SOCKLEN_T is only used there.

I've pushed a fix as 71ba7b1853431a9e39ad63d9389057594441f6f4 and backport to RELEASE/1.4 as fbddad92dfb824ac067d43360736ece14ae2b50d.

I've also fixed the std::byte issue in da6a15d00802ab54981ca376868b74af255f5dd9 (this doesn't affect git master as we already eliminated all using namespace std; in headers there).