Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the ExtUtils-ParseXS CPAN distribution.

Report information
The Basics
Id: 48104
Status: resolved
Priority: 0/
Queue: ExtUtils-ParseXS

People
Owner: Nobody in particular
Requestors: MARKLE [...] cpan.org
SMPETERS [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 2.2002
Fixed in: 2.20_03

Attachments


Subject: [PATCH] Get parsed XS to compile warnings free with gcc's -Wwrite-strings
Download (untitled) / with headers
text/plain 414b
Without the patch below, the boot function generated spits out warnings when using gcc with -Wwrite-strings. ==== //depot/perl/lib/ExtUtils/ParseXS.pm#24 (text) ==== @@ -940,7 +940,7 @@ #-Wall: if there is no $Full_func_name there are no xsubs in this .xs #so `file' is unused print Q(<<"EOF") if $Full_func_name; -# char* file = __FILE__; +# const char* file = __FILE__; EOF print Q("#\n");
From: kristina
This patch kind of borks things on OS X, which still uses Perl 5.8.8. In 5.8.8, newXS still takes a char* (not a const char*) as a fourth argument. I'm writing a module that uses C++ to compile, so I get a million errors like: xs/OID.c: In function ‘void boot_MongoDB__OID(PerlInterpreter*, CV*)’: xs/OID.c:98: error: invalid conversion from ‘const char*’ to ‘char*’ xs/OID.c:98: error: initializing argument 4 of ‘CV* Perl_newXS(PerlInterpreter*, char*, void (*)(PerlInterpreter*, CV*), char*)’ Changing "const char*" back to "char*" makes it work fine. On Fri Dec 21 11:40:31 2007, SMPETERS wrote: Show quoted text
> Without the patch below, the boot function generated spits out warnings > when using gcc with -Wwrite-strings. > > ==== //depot/perl/lib/ExtUtils/ParseXS.pm#24 (text) ==== > > @@ -940,7 +940,7 @@ > #-Wall: if there is no $Full_func_name there are no xsubs in this .xs > #so `file' is unused > print Q(<<"EOF") if $Full_func_name; > -# char* file = __FILE__; > +# const char* file = __FILE__; > EOF > > print Q("#\n");
Subject: cannot build Encode::Detect under perl 5.8.8
Download (untitled) / with headers
text/plain 3.4k
mysql.c:2281: warning: passing argument 4 of ‘Perl_newXS’ discards qualifiers from pointer target type Since DBD::SQLite broke the other day under mod_perl2/perl5.8.8 in CentOS 5 I have been fiddling with perl to get things working again, rebuilding lots of modules. I see the above error message all over the place in many modules. mysql.c from DBD::mysql is just an example. And I cannot install Encode::Detect at all because of a similar error, see below. Could this be due to recent upgrades of ExtUtils::CBuilder or ExtUtils::ParseXS ? If you are cutting off people who use 5.8.8 please say so, then I can convince my boss to use Debian to keep up with rest of the world. Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/site_perl/5.8.8/ExtUtils/ParseXS.pm line 558, <GEN36> line 71. gcc -Isrc -I/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -DXS_VERSION="1.01" -DVERSION="1.01" -fPIC -x c++ -Iinclude -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -o lib/Encode/Detect/Detector.o lib/Encode/Detect/Detector.c cc1plus: warning: command line option "-Wdeclaration-after-statement" is valid for C/ObjC but not for C++ lib/Encode/Detect/Detector.c: In function ‘void boot_Encode__Detect__Detector(PerlInterpreter*, CV*)’: lib/Encode/Detect/Detector.c:330: error: invalid conversion from ‘const char*’ to ‘char*’ lib/Encode/Detect/Detector.c:330: error: initializing argument 4 of ‘CV* Perl_newXS(PerlInterpreter*, char*, void (*)(PerlInterpreter*, CV*), char*)’ lib/Encode/Detect/Detector.c:331: error: invalid conversion from ‘const char*’ to ‘char*’ lib/Encode/Detect/Detector.c:331: error: initializing argument 4 of ‘CV* Perl_newXS(PerlInterpreter*, char*, void (*)(PerlInterpreter*, CV*), char*)’ lib/Encode/Detect/Detector.c:332: error: invalid conversion from ‘const char*’ to ‘char*’ lib/Encode/Detect/Detector.c:332: error: initializing argument 4 of ‘CV* Perl_newXS(PerlInterpreter*, char*, void (*)(PerlInterpreter*, CV*), char*)’ lib/Encode/Detect/Detector.c:333: error: invalid conversion from ‘const char*’ to ‘char*’ lib/Encode/Detect/Detector.c:333: error: initializing argument 4 of ‘CV* Perl_newXS(PerlInterpreter*, char*, void (*)(PerlInterpreter*, CV*), char*)’ lib/Encode/Detect/Detector.c:334: error: invalid conversion from ‘const char*’ to ‘char*’ lib/Encode/Detect/Detector.c:334: error: initializing argument 4 of ‘CV* Perl_newXS(PerlInterpreter*, char*, void (*)(PerlInterpreter*, CV*), char*)’ lib/Encode/Detect/Detector.c:335: error: invalid conversion from ‘const char*’ to ‘char*’ lib/Encode/Detect/Detector.c:335: error: initializing argument 4 of ‘CV* Perl_newXS(PerlInterpreter*, char*, void (*)(PerlInterpreter*, CV*), char*)’ lib/Encode/Detect/Detector.c:336: error: invalid conversion from ‘const char*’ to ‘char*’ lib/Encode/Detect/Detector.c:336: error: initializing argument 4 of ‘CV* Perl_newXS(PerlInterpreter*, char*, void (*)(PerlInterpreter*, CV*), char*)’ error building lib/Encode/Detect/Detector.o from 'lib/Encode/Detect/Detector.c' at /usr/lib/perl5/site_perl/5.8.8/ExtUtils/CBuilder/Base.pm line 110.
Download (untitled) / with headers
text/plain 155b
There was definitely no intention to cut off perl 5.8.8. I'll see if I can wrangle some help to investigate this bug. Thank you for the report. -- David
Download (untitled) / with headers
text/plain 576b
On Wed Jul 22 23:10:56 2009, MARKLE wrote: Show quoted text
> Since DBD::SQLite broke the other day under mod_perl2/perl5.8.8 in > CentOS 5 I have been fiddling with perl to get things working again, > rebuilding lots of modules. I see the above error message all over the > place in many modules. mysql.c from DBD::mysql is just an example. > > And I cannot install Encode::Detect at all because of a similar error, > see below. Could this be due to recent upgrades of ExtUtils::CBuilder > or ExtUtils::ParseXS ?
What version of ExtUtils::ParseXS and ExtUtils::CBuilder are you using?
Download (untitled) / with headers
text/plain 369b
In 5.8.x and lower, newXS expects its file argument to be a char *, while "file" is defined as a const char *. This causes this breakage for C++ compilers but also warnings in the testsuite with recent gccs. The attached patch fixes this by storing the file string into a non-const local char array instead of taking a pointer to the string constant __FILE__. Vincent.
--- lib/ExtUtils/ParseXS.pm 2009-07-18 23:23:17.000000000 +0200 +++ lib/ExtUtils/ParseXS.pm 2009-07-23 16:42:34.000000000 +0200 @@ -976,10 +976,15 @@ ##endif EOF + #Under 5.8.x and lower, newXS is declared in proto.h as expecting a non-const + #file name argument. If the wrong qualifier is used, it causes breakage with + #C++ compilers and warnings with recent gcc. + my $file_decl = ($] < 5.009) ? "char file[]" : "const char* file"; + #-Wall: if there is no $Full_func_name there are no xsubs in this .xs #so `file' is unused print Q(<<"EOF") if $Full_func_name; -# const char* file = __FILE__; +# $file_decl = __FILE__; EOF print Q("#\n");
Download (untitled) / with headers
text/plain 573b
That is awesome! No I did not seriously think people were trying to cut off 5.8.8 I just get annoyed having to use CentOS mostly because I think it's unrealistic that three volunteers can maintain an up-to-date operating system. BTW the problem with DBD::SQLite (did I conflate that) is probably a buggy httpd-dev deployed in CentOS. ExtUtils::ParseXS 2.2002, ExtUtils::CBuilder 0.2603. (I tried removing site_perl and installing my CPAN list again, upgrading everything in CPAN, wiping all of perl and most yum packages and boostrapping from a near-clean system, etc.)
Fixed in repository trunk.
Download (untitled) / with headers
text/plain 594b
If this patch is in the latest dev release 2.20_03 then it fixes most of the problem. I can build Encode::Detect with CPAN and libapreq2 from source. I rebuilt all my site_perl. BTW ExtUtils::ParseXS 2.20_03 installs to site_perl/5.8.8, is that right or should it be in core 5.8.8 like ExtUtils::CBuilder? (That was a bug about that one. Actually that's when everything started to go downhill.) There are still a lot of warnings building modules in CentOS 5.3 with perl 5.8.8 so I filed another bug. DBD::SQLite still does not work under mod_perl2; this may be a different problem. :-(
Download (untitled) / with headers
text/plain 1.2k
These changes break the compile of mod_perl-2.0.4 on many systems. Reinstalling ExtUtils-ParseXS-2.2002 allows the compile to complete correctly. gcc -c -I/home/cpeasyapache/src/mod_perl-2.0.4/src/modules/perl -I/home/cpeasyapache/src/mod_perl-2.0.4/xs -I/usr/local/apache/include -I/usr/local/apache/include -I/usr/local/apache/include -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -I/usr/include/gdbm -DMOD_PERL -DMP_COMPAT_1X -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -DAP_HAVE_DESIGNATED_INITIALIZER -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DVERSION=\"0.009000\" -DXS_VERSION=\"0.009000\" -fPIC "-I/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE" -DMP_HAVE_APR_LIBS APR.c APR.xs: In function ‘boot_APR’: APR.xs:66: error: incompatible types in assignment make[3]: *** [APR.o] Error 1 perl = 5.8.8 OS = CentOS 5.3 Kernel = 2.6.18-128.1.10.el5 arch = x86_64 gcc = 4.1.2 20080704 (Red Hat 4.1.2-44) Relevant section of APR.xs: MODULE = APR PACKAGE = APR PROTOTYPES: disable BOOT: file = file; /* -Wall */ <--- line 66 APR_initialize(); extra_apr_init(aTHX); void END() CODE: APR_terminate();
Download (untitled) / with headers
text/plain 487b
Show quoted text
> APR.xs: In function ‘boot_APR’: > APR.xs:66: error: incompatible types in assignment > make[3]: *** [APR.o] Error 1
Is it possible this is a bug in APR that was ignored in previous versions that did not check types strictly? The trouble is, without this patch, it's impossible to build a whole bunch of other CPAN modules in CentOS other than mod_perl. I am more and more convinced that CentOS perl setup is completely hosed, that the whole thing is about to fall into the sea.
Download (untitled) / with headers
text/plain 495b
On Fri Oct 02 17:20:55 2009, MARKLE wrote: Show quoted text
> Is it possible this is a bug in APR that was ignored in previous > versions that did not check types strictly?
I'm not entirely sure what causes GCC to spit out an error here. When I use the same syntax in a normal C file with identical compiler flags I get no error messages. Switching it from: char file[] = "APR.c"; to char* file = "ARP.c"; allows it to compile without errors. If the only problem is the "const" that might be a solution.
Argh this stuff is so hosed. David are you able to test on CentOS somehow?
Download (untitled) / with headers
text/plain 1.2k
On Fri Oct 02 21:00:14 2009, jlightsey wrote: Show quoted text
> On Fri Oct 02 17:20:55 2009, MARKLE wrote:
> > Is it possible this is a bug in APR that was ignored in previous > > versions that did not check types strictly?
> > I'm not entirely sure what causes GCC to spit out an error here. When I > use the same syntax in a normal C file with identical compiler flags I > get no error messages. Switching it from: > > char file[] = "APR.c"; > > to > > char* file = "ARP.c"; > > allows it to compile without errors. If the only problem is the "const" > that might be a solution.
The original reason that this change was made was to quiet warnings that appear when compiling perl using gcc with -Wwrite-strings or with g++. Other C++ compilers react badly as well, but my memory of what they do is failing me at the moment. Essentially, what happens with -Wwrite-strings or compiling with g++ is that all string constants are converted to const char [length]. So when passing a const string to a function, it will warn appropriately. Looking at the declaration of what you have above, it appears to be faulty. "ARP.c" is a const string, so assigning it to char file[] should generate warnings, and will with nearly any compiler but gcc by default.
ARP.c s/b APR.c btw
Subject: Re: [rt.cpan.org #48104] [PATCH] const char *file breaks on 5.8.X
Date: Fri, 2 Oct 2009 23:02:16 -0400
To: bug-ExtUtils-ParseXS [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
Download (untitled) / with headers
text/plain 470b
On Fri, Oct 2, 2009 at 9:12 PM, Mark Hedges via RT <bug-ExtUtils-ParseXS@rt.cpan.org> wrote: Show quoted text
> David are you able to test on CentOS somehow?
I've downloaded a virtual machine and will try to get it set up. Note -- using the latest ExtUtils::ParseXS on CPAN (2.200403) I was able to compile all mod_perl modules on a Ubuntu box without any errors. Please try 2.200403 and let me know how that works. If it fails, maybe it really is a CentOS specific issue. -- David
Download (untitled) / with headers
text/plain 686b
Prior fixes to this ticket wound up using 'char[] file' for perl < 5.9, whereas the original behavior back in 5.8.8 was 'char* file'. I have reverted to the original behavior and released 2.20_07 to CPAN with this fix. I have tested this change (applied to 2.200403) with mod_perl on CentOS (after manually fixing an annoying OPT_INCNOEXEC problem with the stock httpd on the VM I used) and it compiled and passed all tests. Please try 2.20_07 and see if it works for you on your systems. After I see some positive smoke test results from 2.20_07, I will release 2.21 and hopefully this absurd issue should be behind us. Thank you to all for your patience and guidance. -- David
2.20_07 allows mod_perl to build completely on my system.
Thank you for the success report. I've released 2.21 to CPAN.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.