New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GIMME_V broken with 5.10.0/GCC and XS? #9215
Comments
From rob@themayfamily.me.ukCreated by robertmay@cpan.orgThis is a bug report for perl from robertmay@cpan.org, ----------------------------------------------------------------- GIMME_V appears to always return G_VOID (128), regardless of the The same code and compiler works fine when built against ActiveState #include "EXTERN.h" MODULE = GimmeVTest PACKAGE = GimmeVTest int Testing with the following code: my $scalar = GimmeVTest::context(); results in the following output: not ok 1 - in scalar context not ok 2 - in list context not ok 3 - in list context not ok 4 - in list context I have reached the end of my knowledge in the internals trying Module distribution for the above code and tests attached to save Regards, Perl Info
|
From @janduboisOn Tue, 29 Jan 2008, Robert May (via RT) wrote:
This is not really a core Perl bug; the problem is that VC++ and GCC unsigned op_type:9; \ In VC++ the combined size of the fields above is 4 bytes, whereas The GIMME_V() function retrieves the context information from the VC++ uses the base type (unsigned int, in this case) to determine I guess for Perl 5.12 we need a way to let us use the smaller base I would suggest to keep this bug report open until the size of For ActivePerl 5.10.x we will probably modify op.h to provide an I have not yet verified that otherwise the bit mapping between The ability to compile extensions with GCC for a Perl compiled http://bugs.activestate.com/show_bug.cgi?id=74532 Cheers, |
The RT System itself - Status changed from 'new' to 'open' |
From rob@themayfamily.me.ukJan, Many thanks for the very quick analysis, and clear explanation. Further research turns up the '-mms-bitfields' option for (mingw Regards, [1] Although I have in the process discovered that On 30/01/2008, Jan Dubois <jand@activestate.com> wrote:
-- |
From @janduboisOn Wed, 30 Jan 2008, Robert May wrote:
Awesome. Yes, this is much better than having to hack op.h to Cheers, |
From rob@themayfamily.me.ukOn 30/01/2008, Jan Dubois <jand@activestate.com> wrote:
So, in the meantime, can anyone suggest a mechanism for testing I can't just blindly add -mms-bitfields' if the compiler is gcc, as Or am I stuck with putting a big warning in the README (which won't Thanks for any insight. |
From @janduboisOn Wed, 30 Jan 2008, Robert May wrote:
I don't understand why you need to do this at all; you should just Or are you just creating a workaround for the already released if (defined &Win32::BuildNumber) { I doubt that there are any other configurations out there where If you want make sure you also catch any instance where somebody use Config qw(%Config); I dislike this one though, as it calls a private function, so use Config qw(%Config); Maybe the most general solution would be: my $cc; This of course will still fail if someone builds with VC++ and then Cheers, |
From rob@themayfamily.me.ukOn 31/01/2008, Jan Dubois <jand@activestate.com> wrote:
That's it exactly - I'm on the verge of making a 5.10 compatible
But won't Strawberry Perl have this too? Are you saying that
But that won't catch someone who built Perl from the official sources
I actually just wrote this: use Config; print +(is_msvc() ? '' : 'NOT '), "MSVC\n"; sub is_msvc { for ('Config.pm', 'config_heavy.pl') { Yours is much more elegant though.
Indeed :-) Many thanks, |
From @janduboisOn Wed, 30 Jan 2008, Robert May wrote:
It is an ActivePerl addition, reporting the ActivePerl build number. Strawberry Perl is build from the original P5P sources, so it won't have I doubt many people do this though.
Yes, but this is only an issue if after building Perl they suddenly
As your example below points out, it shouldn't die, but just skip the
Cheers, |
From @janduboisOn Wed, 30 Jan 2008, Jan Dubois wrote:
[...]
I've attached a patch that defined PERL_BITFIELD8, PERL_BITFIELD16 These symbols are then being redefined for VC (and MinGW GCC) to use the I've also added -mms-bitfields to the default options for MinGW in Cheers, |
From @jandubois |
From @janduboisAre there any questions about this patch, or is there some other reason Cheers, On Fri, 01 Feb 2008, Jan Dubois wrote:
|
From @janduboisSize of OP structures fixed for VC with change 33292: http://public.activestate.com/cgi-bin/perlbrowse/p/33292 This change also adds the -mms-bitfields flag to MinGW compiler options. |
@jandubois - Status changed from 'open' to 'resolved' |
From @iabynOn Fri, Feb 01, 2008 at 01:40:41PM -0800, Jan Dubois wrote:
Jan, is this patch safe for 5.10.1 - specifically is it binary compatible? -- |
From @janduboisOn Tue, 27 May 2008, Dave Mitchell wrote:
No, it is not. :( For 5.10 we'll have to live with the slightly bloated Cheers, |
Migrated from rt.perl.org#50386 (status was 'resolved')
Searchable as RT50386$
The text was updated successfully, but these errors were encountered: