Front page | perl.perl5.porters |
Postings from July 2010
Re: [perl #76570] Re: Smoke [5.13.2] v5.13.2-245-g9df83ff FAIL(Xm)linux 2.6.32-22-generic [debian] (x86_64/8 cpu)
Thread Previous
|
Thread Next
From:
karl williamson
Date:
July 19, 2010 21:41
Subject:
Re: [perl #76570] Re: Smoke [5.13.2] v5.13.2-245-g9df83ff FAIL(Xm)linux 2.6.32-22-generic [debian] (x86_64/8 cpu)
Message ID:
4C4528D9.9040309@khwilliamson.com
George Greer (via RT) wrote:
> # New Ticket Created by George Greer
> # Please include the string: [perl #76570]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=76570 >
>
>
> On Tue, 13 Jul 2010, Tony Cook wrote:
>
>> On Tue, Jul 13, 2010 at 03:13:00AM -0400, George Greer wrote:
>>> sv.c: In function ‘I32 Perl_sv_cmp(SV*, SV*)’:
>>> sv.c:6849: error: invalid conversion from ‘const void*’ to ‘const char*’
>>> sv.c:6849: error: initializing argument 1 of ‘I32 Perl_my_memcmp(const char*, const char*, I32)’
>>> sv.c:6849: error: initializing argument 2 of ‘I32 Perl_my_memcmp(const char*, const char*, I32)’
>>> sv.c: In function ‘I32 Perl_sv_cmp_locale(SV*, SV*)’:
>>> sv.c:6906: error: invalid conversion from ‘void*’ to ‘const char*’
>>> sv.c:6906: error: initializing argument 1 of ‘I32 Perl_my_memcmp(const char*, const char*, I32)’
>>> sv.c:6906: error: initializing argument 2 of ‘I32 Perl_my_memcmp(const char*, const char*, I32)’
>> This appears to be two problems:
>>
>> a) the prototype for the replacement Perl_my_memcmp() doesn't match
>> the standard C memcmp(). Presumably this matches historical
>> (pre-ANSI) memcmp.
>>
>> b) Configure doesn't find the available memcmp() - so why?
>>
>> One thing that confused me initially was why it worked under gcc but
>> not under g++. hints/linux.sh defaults use of nm when building with
>> g++, while for gcc, nm isn't used because the library is detected as
>> GNU libc.
>>
>> The nm mechanism is failing because of a GNU extension:
>>
>> tony@saturn-ubuntu64:~$ nm --dynamic /lib64/libc.so.6 | grep memcmp
>> 0000000000085260 i memcmp
>> 000000000008e780 T wmemcmp
>>
>>> From man nm:
>> "i" For PE format files this indicates that the symbol is in a
>> section specific to the implementation of DLLs. For ELF format
>> files this indicates that the symbol is an indirect function.
>> This is a GNU extension to the standard set of ELF symbol
>> types. It indicates a symbol which if referenced by a
>> relocation does not evaluate to its address, but instead must
>> be invoked at runtime. The runtime execution will then return
>> the value to be used in the relocation.
>>
>> Which presumably a symbol with a type of "i" should be treated as
>> defined.
>>
>> As simple change:
>>
>> diff --git a/Configure b/Configure
>> index 4217f8c..db52ff8 100755
>> --- a/Configure
>> +++ b/Configure
>> @@ -7672,7 +7672,7 @@ $echo $n ".$c"
>> $grep fprintf libc.tmp > libc.ptf
>> xscan='eval "<libc.ptf $com >libc.list"; $echo $n ".$c" >&4'
>> xrun='eval "<libc.tmp $com >libc.list"; echo "done." >&4'
>> -xxx='[ADTSIW]'
>> +xxx='[ADTSIWi]'
>> if com="$sed -n -e 's/__IO//' -e 's/^.* $xxx *//p'";\
>> eval $xscan;\
>> $contains '^fprintf$' libc.list >/dev/null 2>&1; then
>>
>> allows perl to build and test successfully.
>>
>> (Configure change, so not committed.)
>>
>> An alternative would be to remove the usenm hint for g++, but
>> presumably that was added for a reason.
>
> I failed miserably regenerating a Configure from metaconfig so I give up
> and here's a patch that would do what is above for U/modified/libc.U
>
> I also noticed a documentation bug while trying to follow the README, so
> that's included too.
>
>> Should Perl_my_memcmp() be changed to match ANSI C?
>
> The definition of (Perl_)?my_memcmp hasn't changed since it was added back
> in the Perl 4 days and I couldn't find evidence the official prototype was
> using 'char*', so IMHO it should. A patch also attached for that. I
> forget the results of the 'who does "make regen"' debate, so if you want
> that commit too, see:
> http://m-l.org/~perl/misc/0001-Auto-generated-results-of-perl-regen.pl.patch
> (it's trivial though).
>
>
> Even with all of the changes, we still die on a strchr() call now because
> glibc provides "correct" strchr prototypes rather than the C ones.
>
> C:
> char *strchr(const char *s, int c)
> C++:
> const char *strchr(const char *s, int c)
> char *strchr( char *s, int c)
>
> and of course C++ doesn't let you convert a 'const char *' to a 'char *'
> so boom on util.c:3972 in Perl_grok_bslash_o (due to 'e')
If you declare 'e' as a const char *, does that make the problem go away?
.
>
> Guess I'll switch my g++ smoker back to gcc for now.
>
> (This was Bcc:'d to perlbug to create a ticket for the patches.)
>
>
Thread Previous
|
Thread Next