ExtUtils/typemap references unresolved symbol

[p5pRT]

Migrated from rt.perl.org#128107 (status was 'open')

Searchable as RT128107$

[p5pRT]

From @sisyphus

Hi,

This report is in response to
ingydotnet/inline-c-pm#52

Perls 5.24.0, 5.22.0 (and probably others) are affected.

The demo script​:

#########################
use strict;
use warnings;

use Inline C => Config =>
  BUILD_NOISY => 1;

use Inline C => <<'EOC';

int foo(char ** x) {
  return 1;
}

void bar() {
  char ** p;
  printf("%d\n", foo(p));
}

EOC
bar();
foo(0);
########################

On Windows, the compilation of the C code fails.
Firstly there's a couple of warnings​:

bug_pl_307a.c​: In function 'XS_main_foo'​:
bug_pl_307a.c​:178​:14​: warning​: implicit declaration of function
'XS_unpack_charPtrPtr' [-Wimplicit-function-declaration]
  char ** x = XS_unpack_charPtrPtr(ST(0))
  ^
bug_pl_307a.c​:178​:14​: warning​: initialization makes pointer from integer
without a cast [-Wint-conversion]

and then the error​:

bug_pl_307a.o​:bug_pl_307a.c​:(.text+0xd6)​: undefined reference to
`XS_unpack_charPtrPtr'

On Ubuntu, it's just the one warning​:

bug_pl_d189.c​: In function ‘XS_main_foo’​:
bug_pl_d189.c​:178​:14​: warning​: initialization makes pointer from integer
without a cast [enabled by default]

and then, being linux, the error of course doesn't arise until runtime when
foo() gets called from perl​:

1
perl​: symbol lookup error​:
/home/sisyphus-sis/pscrpt/_Inline/lib/auto/bug_pl_d189/bug_pl_d189.so​:
undefined symbol​: XS_unpack_charPtrPtr

Apparently Inline​::C assumes that if it's in the typemap then it can be
bound to perl - and I guess the wisdom of that assumption could be
questioned, though it seems reasonable to me.
But surely the typemap should not contain unusable mapping ?

'perl -V' for the 5.24.0 that produced the above (Windows) warnings and
error is given below.
Inline-C version is 0.76, gcc-5.3.0.

Cheers,
Rob

Summary of my perl5 (revision 5 version 24 subversion 0) configuration​:

  Platform​:
  osname=MSWin32, osvers=6.1, archname=MSWin32-x86-multi-thread-64int
  uname=''
  config_args='undef'
  hint=recommended, useposix=true, d_sigaction=undef
  useithreads=define, usemultiplicity=define
  use64bitint=define, use64bitall=undef, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='gcc', ccflags
=' -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS
-DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields',
  optimize='-s -O2',
  cppflags='-DWIN32'
  ccversion='', gccversion='5.3.0', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678,
doublekind=3
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12,
longdblkind=3
  ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='long
long', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='g++', ldflags
='-s -L"c​:\MinGW\perl524_64int\lib\CORE" -L"C​:\_32\gcc-mingw-530\mingw32\lib"'
  libpth=C​:\_32\gcc-mingw-530\mingw32\lib C​:\_32\gcc-mingw-530\mingw32\lib
C​:\_32\gcc-mingw-530\mingw32\i686-w64-mingw32\lib
C​:\_32\msys_530\1.0\local\lib
C​:\_32\gcc-mingw-530\mingw32\lib\gcc\i686-w64-mingw32\5.3.0
  libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32
-lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion
-lodbc32 -lodbccp32 -lcomctl32
  perllibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32
-lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion
-lodbc32 -lodbccp32 -lcomctl32
  libc=, so=dll, useshrplib=true, libperl=libperl524.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
  cccdlflags=' ',
lddlflags='-mdll -s -L"c​:\MinGW\perl524_64int\lib\CORE" -L"C​:\_32\gcc-mingw-530\mingw32\lib"'

Characteristics of this binary (from libperl)​:
  Compile-time options​: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY
  PERLIO_LAYERS PERL_COPY_ON_WRITE
  PERL_DONT_CREATE_GVSV
  PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
  PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
  PERL_MALLOC_WRAP PERL_PRESERVE_IVUV USE_64_BIT_INT
  USE_ITHREADS USE_LARGE_FILES USE_LOCALE
  USE_LOCALE_COLLATE USE_LOCALE_CTYPE
  USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_PERLIO
  USE_PERL_ATOF
  Built under MSWin32
  Compiled at May 9 2016 22​:40​:05
  @​INC​:
  C​:/MinGW/perl524_64int/site/lib
  C​:/MinGW/perl524_64int/lib
  .

[p5pRT]

From @tonycoz

On Mon May 09 18​:10​:58 2016, sisyphus wrote​:

bug_pl_307a.c​: In function 'XS_main_foo'​:
bug_pl_307a.c​:178​:14​: warning​: implicit declaration of function
'XS_unpack_charPtrPtr' [-Wimplicit-function-declaration]
char ** x = XS_unpack_charPtrPtr(ST(0))
^
bug_pl_307a.c​:178​:14​: warning​: initialization makes pointer from
integer
without a cast [-Wint-conversion]

and then the error​:

bug_pl_307a.o​:bug_pl_307a.c​:(.text+0xd6)​: undefined reference to
`XS_unpack_charPtrPtr'

Removing it would break existing code on CPAN, for example XML​::LibXML.

Most code that uses that typemap entry seems to use the same or similar code, probably originally from​:

https://metacpan.org/release/CookBookA

( https://metacpan.org/source/DMR/CookBookA-19960430/Ex8 )

Maybe that could be packaged with Inline​::C

Tony

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @sisyphus

-----Original Message-----
From​: Tony Cook via RT
Sent​: Wednesday, May 11, 2016 10​:43 AM
To​: sisyphus1@​optusnet.com.au
Subject​: [perl #128107] ExtUtils/typemap references unresolved symbol

On Mon May 09 18​:10​:58 2016, sisyphus wrote​:

bug_pl_307a.c​: In function 'XS_main_foo'​:
bug_pl_307a.c​:178​:14​: warning​: implicit declaration of function
'XS_unpack_charPtrPtr' [-Wimplicit-function-declaration]
char ** x = XS_unpack_charPtrPtr(ST(0))
^
bug_pl_307a.c​:178​:14​: warning​: initialization makes pointer from integer
without a cast [-Wint-conversion]

and then the error​:

bug_pl_307a.o​:bug_pl_307a.c​:(.text+0xd6)​: undefined reference to
`XS_unpack_charPtrPtr'

Removing it would break existing code on CPAN, for example XML​::LibXML.

Shouldn't they be putting that mapping into their own typemaps rather than
the one in ExtUtils ?

Most code that uses that typemap entry seems to use the same or similar
code, probably originally from​:

https://metacpan.org/release/CookBookA

( https://metacpan.org/source/DMR/CookBookA-19960430/Ex8 )

Thanks for digging that out.
I copied the functions from
https://metacpan.org/source/DMR/CookBookA-19960430/Ex8/Av_CharPtrPtr.c to
the beginning of the Inline C code, and that appears to fix the problem.
(There's an SvPV() call in there that needs fixing because it references the
'na' symbol that is no longer supported. I replaced that SvPV() call with
SvPV_nolen().)

Maybe that could be packaged with Inline​::C

I think so. If I was going to do that I think I'd just have the bound
functions scanned for an argument or return type of 'char **' - and if
there's one found then insert those Av_CharPtrPtr.c functions into the
beginning of the Inline C code section.
A problem that shouldn't exist (imo) thereby gets turned into a useful gain.

Cheers,
Rob