Mailing List Archive

On Thu, Jun 16, 2022 at 3:11 PM sisyphus <sisyphus359@gmail.com> wrote:

> Hi,
> Mingw runtime version 9 was released just prior to the release of
> perl-5.34.0.
> Mingw runtime version 10 was released a few weeks before 5.36.0.
>
> Mingw-w64 toolchains that have these latest runtimes (ie v9 or v10) are
> incapable of building perl from source.
>
> Part of the problem has already been fixed in blead - when
> https://github.com/Perl/perl5/pull/19663 was merged just after 5.36.0 was
> released. (Thank you, Karl.)
> That leaves only https://rt.cpan.org/Ticket/Display.html?id=142390 to
> deal with.
> ....
>

Perl-5.37.1 was released today, but there's no sign of any action being
taken on this yet.
It would be great if it could be fixed for perl-5.37.2

Cheers,
Rob

On Tue, 21 Jun 2022 13:36:54 +1000
sisyphus <sisyphus359@gmail.com> wrote:

> Perl-5.37.1 was released today, but there's no sign of any action
> being taken on this yet.
> It would be great if it could be fixed for perl-5.37.2

Hello,

This is in no way a complaint about you, but rather of my own
limitations... But I have read these messages and the related RT ticket
and I can't really work out what problem is being solved or how, nor
what it is I need to do.

Can you please explain in one short sentence each

a) What is the problem

b) What is the intended nature of a possible fix

and optionally (and I really mean optionally)

c) Provide a .diff file patch that fixes it

Thanks,

----

As a more general note to the world: This is verymuch the way to get me
to do something. Explain what's wrong with the code I've made, don't
try to fix it yourself.

There is a reason why most of my personal projects do not appear on
github. I find the entire culture is centered around "patch first, ask
questions later". It's a style of interaction that does not work well
for me. Explain to me the problem first and I'll likely be able to fix
it. But if you just come running in with a patch first, I have to
reverse-engineer what the problem was that it was trying to fix, before
I can evaluate the relative merits of that change vs. anything else
that could be done.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Sat, Jun 25, 2022 at 1:29 AM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:
.....

> Can you please explain in one short sentence each
>
> a) What is the problem


With Socket-2.033, the 'make' step fails to compile Socket.xs with
mingw-w64 ports of gcc if (and only if) the symbol InetNtopA is defined.


> b) What is the intended nature of a possible fix
>
>
To enable compilation of Socket.xs.

and optionally (and I really mean optionally)
>
> c) Provide a .diff file patch that fixes it
>
>
See attached Socket.xs.txt

To provide some elaboration, the compilation errors are (in brief) :
Socket.xs:101:12: error: static declaration of 'inet_pton' follows
non-static declaration
and:
Socket.xs:123:20: error: conflicting types for 'inet_ntop'.

InetNtopA is found in the windows header ws2tcpip.h.
I had never struck a perl build where this symbol was defined until about
14 months ago when I started using more recent mingw-w64 ports of gcc.
Unlike the older ports, these recent ports define _WIN32_WINNT to such a
sufficiently high value as to enable the defining of InetNtopA.
In turn, the Windows implementations of inet_ntop and inet_pton are found
if (and only if) InetNtopA is defined.

Sorry that it turned out to be such a confusing thread.
Please don't hesitate to ask for further info

On Sun, Jun 26, 2022 at 6:05 PM sisyphus <sisyphus359@gmail.com> wrote:

> ....
> InetNtopA is found in the windows header ws2tcpip.h.
>
>
Here are the pertinent parts of the relevant '#if" block from ws2tcpip.h:
/*******************************/
#if (_WIN32_WINNT >= 0x0600)

#define InetNtopA inet_ntop
WINSOCK_API_LINKAGE LPCSTR WSAAPI InetNtopA(INT Family, LPCVOID pAddr,
LPSTR pStringBuf, size_t StringBufSize);

#define InetPtonA inet_pton
WINSOCK_API_LINKAGE INT WSAAPI InetPtonA(INT Family, LPCSTR pStringBuf,
PVOID pAddr);

#endif /*(_WIN32_WINNT >= 0x0600)*/
/*******************************/

There's other stuff in that block which I've not shown because it's not
relevant to this particular issue.
As you can see, there will be no issue if _WIN32_WINNT < 0x0600, as is the
case with older mingw-w64 toolchains.
But recent mingw-w64 toolchains define _WIN32_WINNT to 0x0a00.

Cheers,
Rob

On Sun, 26 Jun 2022 18:05:05 +1000
sisyphus <sisyphus359@gmail.com> wrote:

> With Socket-2.033, the 'make' step fails to compile Socket.xs with
> mingw-w64 ports of gcc if (and only if) the symbol InetNtopA is
> defined.

Socket-2.034 is now on CPAN with your patch in.

(And actually just today I've put version 2.035 which adds a couple
more constants).

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

Cool.

Sent from Yahoo Mail for iPhone


On Friday, July 1, 2022, 11:56 AM, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

On Sun, 26 Jun 2022 18:05:05 +1000
sisyphus <sisyphus359@gmail.com> wrote:

> With Socket-2.033, the 'make' step fails to compile Socket.xs with
> mingw-w64 ports of gcc if (and only if) the symbol InetNtopA  is
> defined.

Socket-2.034 is now on CPAN with your patch in.

(And actually just today I've put version 2.035 which adds a couple
more constants).

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ |  https://www.tindie.com/stores/leonerd/

On Sat, Jul 2, 2022 at 1:56 AM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

>
> Socket-2.034 is now on CPAN with your patch in.
>
> (And actually just today I've put version 2.035 which adds a couple
> more constants).
>
>
Oh .. excellent !!
Both 2.034 and 2.035 build and test fine on my Windows 7 system.
I tested the following archname-version combinations:

MSWin32-x86-multi-thread in 5.34.0 and 5.36.0
MSWin32-x86-multi-thread-ld in 5.34.0 and 5.36.0
MSWin32-x86-multi-thread-quadmath in 5.34.0 and 5.36.0
MSWin32-x86-multi-thread-64int in all stable 5.x.0 versions in the range
5.20.0 to 5.36.0 (inclusive)
MSWin32-x86-multi-thread-64int-ld in all stable 5.x.0 versions in the range
5.22.0 to 5.36.0 (inclusive)
MSWin32-x86-multi-thread-64int-quadmath in 5.34.0 and 5.36.0
MSWin32-x64-multi-thread in all stable 5.x.0 versions in the range 5.20.0
to 5.36.0 (inclusive)
MSWin32-x64-multi-thread-64int-ld in all stable 5.x.0 versions in the range
5.22.0 to 5.36.0 (inclusive)
MSWin32-x64-multi-thread-quadmath in 5.34.0 and 5.36.0

For perl-5.37.1 I settled for testing Socket-2.035 only.
In addition to the 9 archnames listed above, I also tested in:

MSWin32-x64-perlio
MSWin32-x64-perlio-ld
MSWin32-x64-perlio-quadmath
MSWin32-x86-perlio-quadmath
MSWin32-x86-perlio-64int-quadmath.

AFAICT, on Windows the occurrence of "-perlio" just means non multi-thread.
I expected (eg) "MSWin32-x64-perlio " to be simply "MSWin32-x64". It seems
odd to me that the makefiles go to the trouble of deliberately adding the
"-perlio", and I don't know why they do that.

Because they're unthreaded, the fork() function is not implemented, and
t/socketpair.t is therefore skipped on those "-perlio" builds.

The different perl versions generally involve different gcc compilers (from
4.8.x up to 12.1.0) and different mingw-w64 runtimes (from 3.1 to 10.0).
So I've covered a fairly broad range of mingw-w64 toolchains.

I also tested 2.034 and 2.035 on my x64 perl-5.36.0 built using Microsoft's
Visual Studio 2019.
No issues there, either.

LGTM, and I look forward to seeing 2.035 (or 2.034) pushed to blead in the
not-too-distant-future.

Thanks Paul.

Cheers,
Rob

On Sat, Jul 2, 2022, at 04:41, sisyphus wrote:
> On Sat, Jul 2, 2022 at 1:56 AM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>>
>> Socket-2.034 is now on CPAN with your patch in.
>>
>> (And actually just today I've put version 2.035 which adds a couple
>> more constants).
>
> Oh .. excellent !!
> Both 2.034 and 2.035 build and test fine on my Windows 7 system.

I have sync'd 2.035 to core.

--
rjbs

On Sun, Jul 3, 2022 at 6:04 AM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> .....
> I have sync'd 2.035 to core.
>
>
Thank you.
Now, perl is again building straight out of the box ... except for
https://github.com/Perl/perl5/pull/19912 (which is limited to x64 mingw-w64
ports of gcc-12).

Cheers,
Rob