Front page | perl.perl5.porters |
Postings from July 2010
[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:
George Greer
Date:
July 19, 2010 02:04
Subject:
[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:
rt-3.6.HEAD-11314-1279507981-1258.76570-75-0@perl.org
# 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').
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.)
--
George Greer
Thread Previous
|
Thread Next