Bug 1078438 - Templated types are causing "Could not find a typemap for C type"
Summary: Templated types are causing "Could not find a typemap for C type"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: perl-ExtUtils-ParseXS
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Petr Pisar
QA Contact: Jakub Heger
URL:
Whiteboard:
Depends On:
Blocks: 1110700 1191021 1380363
TreeView+ depends on / blocked
 
Reported: 2014-03-19 17:17 UTC by Miro Hrončok
Modified: 2017-09-26 13:22 UTC (History)
6 users (show)

Fixed In Version: perl-ExtUtils-ParseXS-3.18-3.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1032181
Environment:
Last Closed: 2017-08-01 18:14:42 UTC
Target Upstream Version:


Attachments (Terms of Use)
Upstream fix ported to ExtUtils-ParseXS-3.18 (3.26 KB, patch)
2014-03-20 07:42 UTC, Petr Pisar
no flags Details | Diff
Test case (681 bytes, text/plain)
2014-03-20 07:44 UTC, Petr Pisar
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:1924 normal SHIPPED_LIVE perl-ExtUtils-ParseXS bug fix update 2017-08-01 18:06:55 UTC
CPAN 86367 None None None Never

Description Miro Hrončok 2014-03-19 17:17:46 UTC
+++ This bug was initially created as a clone of Bug #1032181 +++

Description of problem:
When using perl-ExtUtils-ParseXS to build XS stuff (I don't know the terminology here, sorry), errors like this happens:
https://rt.cpan.org/Public/Bug/Display.html?id=86367

Version-Release number of selected component (if applicable):
perl-ExtUtils-ParseXS-3.18-291.fc20.noarch

How reproducible:
Happend when building slic3r-xs

Steps to Reproduce:
1. Get slic3r tarball from https://github.com/alexrj/Slic3r/archive/1.0.0RC1.tar.gz
2. unpack && cd Slic3r-1.0.0RC1/xs/ # be usre to be in xs folder
3. perl Build.PL && ./Build

Actual results:
<snip>
Could not find a typemap for C type 'std::vector< double >'.
The following C types are mapped by the current typemap:
'AV *', <snip>, 'wchar_t *'
 in /usr/bin/perl -MExtUtils::XSpp::Cmd -e xspp -- -t "/home/churchyard/Stažené/Slic3r-1.0.0RC1/xs/xsp/typemap.xspt"  "/home/churchyard/Stažené/Slic3r-1.0.0RC1/xs/xsp/TriangleMesh.xsp", line 138

Expected results:
No errors, just warnings

Additional info:
This is fixed in upstream release 3.22 and also in development release 3.18_03.

Fix is in Bug #1032181.

See the error in this build.log: http://copr-be.cloud.fedoraproject.org/results/churchyard/epel7-3dprint/epel-7-x86_64/slic3r-1.0.0-0.4.RC3.fc21/build.log

Comment 2 Petr Pisar 2014-03-20 07:42:06 UTC
ExtUtils::ParseXS::Utilities::tidy_type() does not parse and normalize some C++ type declarations properly:

# perl -MExtUtils::ParseXS::Utilities=tidy_type -e 'print tidy_type(q{std::vector< unsigned int >}), qq{\n}'
std::vector< unsigned int >

While the output should be:

std::vector<unsigned int>

This is fixed by upstream perl commit:

commit ae7fdf584559a304eb5992a58cd58349cc7c58da
Author: Steffen Mueller <smueller@cpan.org>
Date:   Wed May 22 21:49:06 2013 +0200

    EU::ParseXS: Attempt to canonicalize C++ types in tidy_type
    
    Includes moving tidy_type to ExtUtils::Typemaps where it seems to
    belong. It's a pretty poor canonicalizer, but better than nothing!

The key change is:

+  # for templated C++ types, do some bit of flawed canonicalization
+  # wrt. templates at least
+  if (/[<>]/) {
+    s/\s*([<>])\s*/$1/g;
+    s/>>/> >/g;
+  }

in tidy_type().

Comment 3 Petr Pisar 2014-03-20 07:42:54 UTC
Created attachment 876725 [details]
Upstream fix ported to ExtUtils-ParseXS-3.18

Comment 4 Petr Pisar 2014-03-20 07:44:20 UTC
Created attachment 876726 [details]
Test case

This test case is included in the patch and is run at build time.

Comment 14 errata-xmlrpc 2017-08-01 18:14:42 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1924


Note You need to log in before you can comment on or make changes to this bug.