[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl5-porters
Subject:    Re: [perl #132955] USE_CPLUSPLUS build broken in 5.27 blead and all 5.26 stables
From:       Steve Hay via perl5-porters <perl5-porters () perl ! org>
Date:       2018-04-28 14:12:58
Message-ID: CADED=K4gAdDKH607eVKiWYrqXb24SeAhipaiLUEsdU7s31vu8Q () mail ! gmail ! com
[Download RAW message or body]

On 28 April 2018 at 12:59, Steve Hay <steve.m.hay@googlemail.com> wrote:
> On 28 April 2018 at 12:38, Leon Timmermans <fawaka@gmail.com> wrote:
>> On Sat, Apr 28, 2018 at 12:09 PM, Dave Mitchell <davem@iabyn.com> wrote:
>>> On Fri, Apr 27, 2018 at 06:28:42PM +0100, Steve Hay via perl5-porters wrote:
>>>> So now I see there is an obvious solution that I could employ (add
>>>> /Zc:offsetof- to the compiler flags for this & later compilers), but
>>>> I'm still puzzled exactly what the problem is and why it only affects
>>>> Socket when there are so many other uses of STRUCT_OFFSET around the
>>>> code.
>>>
>>> Socket is the only non-core module (i.e. outside of ext/) which uses
>>> STRUCT_OFFSET. On unixy builds, cpan/ modules get passed a different
>>> set of compiler options than core code (generally less strict compiler
>>> warnings flags). Perhaps there's something similar for Windows builds?
>>>
>>> Commit v5.27.5-31-g346712be0b modified core to assume stddef.h and
>>> its features are always available. In particular it made this change to
>>> perl.h:
>>>
>>>
>>> -#if defined(STANDARD_C) && defined(I_STDDEF) && !defined(PERL_GCC_PEDANTIC)
>>> -#   include <stddef.h>
>>> -#   define STRUCT_OFFSET(s,m)  offsetof(s,m)
>>> -#else
>>> -#   define STRUCT_OFFSET(s,m)  (Size_t)(&(((s *)0)->m))
>>> -#endif
>>> +#include <stddef.h>
>>> +#define STRUCT_OFFSET(s,m)  offsetof(s,m)
>>>
>>> Perhaps that chunk should be reverted for now?
>>
>> Reverting it literally requires reverting more of Aaron's C89 work
>> (I_STDDEF is eliminated and STANDARD_C mostly too). Just using the old
>> definition here  for VC++ may be the best solution for now.
>>
>
> Ok, that makes sense of it.
>
> The old definition only needs to be used for VS2017 onwards, though -
> the C++ build works fine right now with VS2015. I'll look into this
> later. (I don't think the other approach of using different compiler
> flags for cpan/ would be easy - it looks to me like cpan/, ext/ and
> dist/ all use the same flags on Windows.)

Now in blead in commit 4bd4e9335ffc257cbe2bf1a42789f693f5797337.

(Actually, I'm still confused why Socket failed given that Windows
doesn't compile cpan/ differently to dist/ and ext/, but I've spent
too long staring at this now...)

That just leaves the GCC fixes from bulk88 to deal with on this
ticket. I'll look at them soon if nobody else gets there first.
[prev in list] [next in list] [prev in thread] [next in thread]