develooper Front page | perl.perl5.porters | Postings from May 2018

Re: [perl #128631] Win32 MinGW build failure

Thread Previous | Thread Next
From:
Steve Hay via perl5-porters
Date:
May 14, 2018 13:07
Subject:
Re: [perl #128631] Win32 MinGW build failure
Message ID:
CADED=K6TjNahcrRQXQz0jKpMp-tQ6Wn=QRrUdRqF-ccfQ9qfWg@mail.gmail.com
On 11 May 2018 at 14:56, sisyphus@cpan.org via RT
<perlbug-followup@perl.org> wrote:
> On Thu, 10 May 2018 05:58:06 -0700, shay wrote:
>
>> I've only just discovered that new mingw.org compilers (v5 and v6)
>> even exist.
>
> Ignoring my better judgement, I installed mingw.org's 6.3.0 compiler and tried to build perl-5.27.11.
> However, after working around the problem involving mkstemp (which is easy enough, for some definition of "easy enough"), I then get hammered with:
>
> win32sck.c: In function 'win32_select':
> win32sck.c:494:12: erreur: expected ';' before 'nrd'
>      FD_SET nrd, nwr, nex;
>
> When I take a look at the pertinent winsock.h, I find the following pedantic drivel:
>
> /********************************/
> #ifndef FD_SET
> #if !_WINSOCK_ANOMALOUS_TYPEDEFS
> /* WinSock is intended to mimic the Berkeley Sockets API, for which
>  * POSIX.1 provides a reference specification; this states that FD_SET
>  * may be implemented as either a macro, or as a function.  The reference
>  * <winsock.h> implementation at http://www.sockets.com/winsock.htm#WinsockH
>  * includes a typedef for FD_SET, which a) conflicts with the latter POSIX.1
>  * provision, and b) creates potential confusion with the former.  Thus, we
>  * prefer to conform with POSIX.1 functional semantics, and recommend that
>  * users avoid the potentially confusing FD_SET typedefs, so allowing us
>  * to provide this function prototype:
>  */
> void FD_SET (SOCKET, fd_set *);
>
> #else   /* _WINSOCK_ANOMALOUS_TYPEDEFS */
> /* However, for users who insist on eschewing standard C/C++ syntax, and
>  * for whatever reason must use FD_SET as a data type, instead of correctly
>  * referring to fd_set, or for pointer references, use PFD_SET or LPFD_SET
>  * instead of standard fd_set * references, we make these anomalous types
>  * visible, when the _WINSOCK_ANOMALOUS_TYPEDEFS feature test macro is
>  * defined with a non-zero value.
>  */
> #warning "FD_SET, PFD_SET, and LPFD_SET data types are non-portable."
> #warning "Use portable fd_set, and fd_set * type references instead."
>
> typedef struct fd_set FD_SET, *PFD_SET, *LPFD_SET;
> #endif
> #define FD_SET( __fd, __set )  __FD_SET ((__fd), (__set))
> __CRT_ALIAS void __FD_SET (SOCKET __fd, fd_set *__set)
> { if( (__set->fd_count < FD_SETSIZE) && ! FD_ISSET (__fd, __set) )
>     __set->fd_array[__set->fd_count++] = __fd;
> }
> #endif  /* ! defined FD_SET */
> /********************************/
>
> So ... at line 570 of GNUmakefile I added -D_WINSOCK_ANOMALOUS_TYPEDEFS to the defines:
>
> DEFINES         = -DWIN32 -D_WINSOCK_ANOMALOUS_TYPEDEFS
>
> That unleashes a shitload of warnings elicited by the above code, but at least the damn thing then builds ok until we get to:
>
> #######################
> APItest.o:APItest.c:(.text+0x5c83): undefined reference to `_imp__Perl_to_utf8_title'
> APItest.o:APItest.c:(.text+0xb293): undefined reference to `_imp__Perl_to_utf8_upper'
> APItest.o:APItest.c:(.text+0xb9e3): undefined reference to `_imp__Perl_to_utf8_fold'
> APItest.o:APItest.c:(.text+0xc2d3): undefined reference to `_imp__Perl_to_utf8_lower'
> collect2.exe: erreur: ld a retourné 1 code d'état d'exécution
> Makefile:483: recipe for target '..\..\lib\auto\XS\APItest\APItest.dll' failed
> gmake[1]: *** [..\..\lib\auto\XS\APItest\APItest.dll] Error 1
> gmake[1]: Leaving directory 'C:/_32/mingw32_new_comp/perl-5.27.11/ext/XS-APItest
> '
> Unsuccessful make(ext/XS-APItest): code=512 at ..\make_ext.pl line 570.
> GNUmakefile:1578: recipe for target 'Extensions' failed
> make: *** [Extensions] Error 2
> #######################
>
> At that point it became a case of either throwing a brick through the console, or walking away.
> Wisely, I decided to walk away. Perhaps I can return to it later.
>
> Back last century, I was a big fan of mingw.org's work.
> But, these days, I find it not in the least surprising that they're being deserted in favour of the mingw-w64 compilers.
>

I didn't realize things were so bad in the new (v5.3.0 and v6.3.0)
versions. I thought the project had died after v4.8.1 actually. I'm
slightly wishing it had done now!

Even v4.8.1 doesn't work overly well - I also see warnings (not
errors) about the FD_SET thing, though the build does at least work.
(But not in C++ mode, where those warnings become errors...)

I think I will let this go since it's looking like more trouble than
it's worth. But I will update documentation to reflect the fact that
we only now have support for MinGW v3 and v4. (We currently claim to
support v3.4.5 or higher.)

Similar problems were also reported in [perl #133041] for v6.3.0. I
will merge the two tickets if I can figure out how to do that.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About