Bug #48104 for ExtUtils-ParseXS: [PATCH] const char *file breaks on 5.8.X

Fri Dec 21 11:40:31 2007 SMPETERS [...] cpan.org - Ticket #31807: Ticket created

Subject:

[PATCH] Get parsed XS to compile warnings free with gcc's -Wwrite-strings

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");

Fri Jun 26 14:53:16 2009 dagolden [...] cpan.org - Ticket #31807: Status changed from 'new' to 'open'

Fri Jun 26 14:53:16 2009 dagolden [...] cpan.org - Ticket #31807: Severity Unimportant added

Thu Jul 16 17:47:02 2009 http://10gen.myopenid.com/ - Ticket #31807: Correspondence added

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");

Wed Jul 22 23:10:56 2009 MARKLE [...] cpan.org - Ticket created

Subject:

cannot build Encode::Detect under perl 5.8.8

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.

Thu Jul 23 07:18:40 2009 dagolden [...] cpan.org - Status changed from 'new' to 'open'

Thu Jul 23 07:19:26 2009 dagolden [...] cpan.org - Correspondence added

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

Thu Jul 23 07:26:55 2009 dagolden [...] cpan.org - Correspondence added

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?

Thu Jul 23 10:52:04 2009 vpit [...] cpan.org - Correspondence added

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");

Thu Jul 23 18:10:48 2009 dagolden [...] cpan.org - Subject changed from 'cannot build Encode::Detect under perl 5.8.8' to '[PATCH] cannot build Encode::Detect under perl 5.8.8'

Thu Jul 23 18:10:48 2009 dagolden [...] cpan.org - Severity Normal added

Thu Jul 23 20:38:11 2009 MARKLE [...] cpan.org - Correspondence added

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.)

Thu Jul 23 23:01:26 2009 dagolden [...] cpan.org - Subject changed from '[PATCH] cannot build Encode::Detect under perl 5.8.8' to '[PATCH] const char *file breaks on 5.8.X'

Thu Jul 23 23:01:51 2009 dagolden [...] cpan.org - Ticket #31807: Merged into ticket #48104

Thu Jul 23 23:01:51 2009 dagolden [...] cpan.org - Merged into ticket #48104

Thu Jul 23 23:12:26 2009 dagolden [...] cpan.org - Correspondence added

Fixed in repository trunk.

Thu Jul 23 23:12:38 2009 dagolden [...] cpan.org - Status changed from 'open' to 'patched'

Wed Jul 29 14:19:22 2009 MARKLE [...] cpan.org - Correspondence added

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. :-(

Wed Jul 29 14:19:23 2009 The RT System itself - Status changed from 'patched' to 'open'

Wed Jul 29 14:21:27 2009 MARKLE [...] cpan.org - Status changed from 'open' to 'patched'

Wed Jul 29 14:21:55 2009 MARKLE [...] cpan.org - Fixed in 2.20_03 added

Wed Jul 29 14:21:55 2009 MARKLE [...] cpan.org - Broken in 2.2002 added

Fri Oct 02 14:52:52 2009 jd [...] cpanel.net - Correspondence added

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();

Fri Oct 02 14:52:53 2009 The RT System itself - Status changed from 'patched' to 'open'

Fri Oct 02 17:20:55 2009 MARKLE [...] cpan.org - Correspondence added

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.

Fri Oct 02 21:00:14 2009 jd [...] cpanel.net - Correspondence added

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.

Fri Oct 02 21:12:57 2009 MARKLE [...] cpan.org - Correspondence added

Argh this stuff is so hosed. David are you able to test on CentOS somehow?

Fri Oct 02 21:18:44 2009 SMPETERS [...] cpan.org - Correspondence added

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.

Fri Oct 02 21:22:57 2009 MARKLE [...] cpan.org - Correspondence added

ARP.c s/b APR.c btw

Fri Oct 02 23:02:54 2009 dagolden [...] cpan.org - Correspondence added

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>

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

Sat Oct 03 11:33:52 2009 dagolden [...] cpan.org - Correspondence added

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

Sat Oct 03 11:33:54 2009 dagolden [...] cpan.org - Status changed from 'open' to 'patched'

Mon Oct 05 10:44:00 2009 jd [...] cpanel.net - Correspondence added

2.20_07 allows mod_perl to build completely on my system.

Mon Oct 05 10:44:00 2009 The RT System itself - Status changed from 'patched' to 'open'

Mon Oct 05 11:34:37 2009 dagolden [...] cpan.org - Correspondence added

Thank you for the success report. I've released 2.21 to CPAN.

Mon Oct 05 11:34:38 2009 dagolden [...] cpan.org - Status changed from 'open' to 'resolved'

Bug #48104 for ExtUtils-ParseXS: [PATCH] const char *file breaks on 5.8.X

Preferred bug tracker