in reply to Re^2: GIMME_V==G_ARRAY anomaly on win32 (5.10 only)
in thread GIMME_V==G_ARRAY anomaly on win32 (5.10 only)

Admittedly that's not the compiler that actually *built* ActivePerl, ...

My speculation would be that this is the problem (but I don't have the prerequisites here to try).  GIMME_V is a rather complex macro which accesses code in the perl binary (without using the CRT, so it's irrelevant that the CRT is the same). G_ARRAY, OTOH, is a simple constant that gets compiled directly into the extension DLL. In other words, you are mixing code compiled with different compilers, but if you recompile, the macro presumably is being expanded appropriately...

Replies are listed 'Best First'.
Re^4: GIMME_V==G_ARRAY anomaly on win32 (5.10 only)
by syphilis (Archbishop) on Dec 19, 2009 at 01:59 UTC
    My speculation would be that this is the problem (but I don't have the prerequisites here to try).

    Seems reasonable - and it may be *part* of the problem, but I feel there's gotta be more to it than that.
    Presumably GIMME_V is also a complex macro in 5.8.x, yet there's no such problem there. I guess that some change in GIMME_V between 5.8 and 5.10 has triggered the event. I'm a little curious as to whether that change constitutes a bug.
    Also, note that there's no problem using this "foreign" MinGW compiler with ActivePerl. The problem arises only when binaries (involving GIMME_V) built on MinGW-built perl are installed onto ActivePerl (and vice-versa). Everything is sweet if the binaries installed on ActivePerl are compiled using ActivePerl and MinGW.

    So ... I guess we're also looking at some difference between the 2 perl dll's themselves. I'm of the uninformed opinion that such a difference ought *not* exist - which is just another way of saying "I don't know whether it's right that such a difference should exist, but I'd prefer it not to be".

    Thanks for your input.

    Cheers,
    Rob
[reply]
      Presumably GIMME_V is also a complex macro in 5.8.x, yet there's no such problem there.

      It's not the complexity per se, but rather the specifics of what happens in detail. And just because it works with 5.8 does not necessarily imply it would have to work with 5.10, too. A minor change could be sufficient to cause different behaviour.

      For one, compilers generate machine code based on implicit assumptions with respect to their inner workings (like widths of data types, alignment of fields within structs, etc.). If you mix machine code compiled with different compilers, the underlying assumptions may or may not match. Often, there is no problem, but there's no guarantees whatsoever.  OTOH, the same compiler can also generate different code depending on the build environment, such as compiler options, contents of header files involved, etc. — which would explain why when recompiling with the same compiler, but in the context of a different Perl (MinGW-built Perl vs. default ActivePerl), everything is sweet.

      I bet that if you use a debugger to step through the machine code behind that GIMME_V macro, you'll figure out why it evaluates to 0x80 (== G_VOID, btw), instead of 1 (== G_ARRAY), in the problem case.

[reply]
        Yep - I have no comeback to any of that :-)
        In future, I'll just make sure that I build my ppm packages using ActivePerl and MinGW, not MingW-built perl and MinGW - which is not such a big ask. That way, it will only be on the rare occasions of my ppm package being installed on a non-MSVC build of perl, that a potential for such a problem exists.

        Thanks, almut.

        Cheers,
        Rob
[reply]

In Section Seekers of Perl Wisdom