develooper Front page | perl.perl5.porters | Postings from July 2010

Re: Smoke [5.13.2] v5.13.2-245-g9df83ff FAIL(Xm) linux2.6.32-22-generic [debian] (x86_64/8 cpu)

Thread Previous | Thread Next
From:
Tony Cook
Date:
July 13, 2010 03:39
Subject:
Re: Smoke [5.13.2] v5.13.2-245-g9df83ff FAIL(Xm) linux2.6.32-22-generic [debian] (x86_64/8 cpu)
Message ID:
20100713103923.GA11291@mars.tony.develop-help.com
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.

Should Perl_my_memcmp() be changed to match ANSI C?

Tony

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About