develooper Front page | perl.perl5.porters | Postings from February 2015

Re: Problems using perl headers with C++

Thread Previous | Thread Next
From:
Олег Пронин
Date:
February 4, 2015 20:38
Subject:
Re: Problems using perl headers with C++
Message ID:
CABFBc471wfGtaObFsy9YdXW6+GbDyY6-1ogHGR1fJ6csTfZvPw@mail.gmail.com
There are still collisions present, for example, do_open/do_close on
MacOSX when #include <ostream>

2015-01-30 6:54 GMT+03:00 bulk88 <bulk88@hotmail.com>:
> Jan Dubois wrote:
>>
>> On Thu, Jan 29, 2015 at 9:44 AM, Олег Пронин <syber@crazypanda.ru> wrote:
>>>
>>> 1) On windows, you can't include ostream after perl's headers.
>>>
>>> c:\strawberry\c\bin\../lib/gcc/x86_64-w64-mingw32/4.7.3/include/c++/ostream:333:49:
>>> error: macro "PerlLIO_write" requires 3 arguments, but only 2 given
>>>
>>> c:\strawberry\c\bin\../lib/gcc/x86_64-w64-mingw32/4.7.3/include/c++/istream:484:42:
>>> error: macro "PerlLIO_read" requires 3 arguments, but only 2 given
>>>
>>> That's because perl defines 'read' and 'write' macro for windows.
>>>
>>> 2) Unable to use std::vector with -std=c++11, because in bits/random.h
>>> there are calls to seed() method. Perl defines macro 'seed'.
>>>
>>> Are we gonna do something with all of these?
>>> IMHO marcos are big evil. If we use it, let's give them some
>>> non-conflicting names.
>>
>>
>> You are missing the point of the macros: They are used to create a
>> wrapper around standard C library functions to redirect them to the
>> Perl implementation instead of calling the RTL version.
>
>
> IDK why those libc hooking were ever created. Nearly all XS code links with
> a non-perl compiland, whether its a static link .o/.obj, or a .a/.lib to a
> DLL. Once the the perl header including .xs file is linked with non-perl
> header including .o/.obj, if any libc resource or ptr or fd is passed across
> the compiland boundaries, the DLL is fundamentally broken. Throw away
> Inline::C "XS modules" are the only use case for libc hooking. I've never
> seen a case where that libc hooking made anything work that didn't work
> before. If your rely on a XS module that was last released in 1995, maybe
> you should ask for comaint from the PAUSE admins.
>
>> If you know what you are doing, and you want to bypass the
>> redefinitions, then you can always
>>
>> #undef seed
>> #undef read
>> #undef write
>> #include <...>
>
>
> sometimes read/write/something is #defined to
> _read/_write/_something/_readex/_mingw_read/_read2 in the MS CRT or Mingw
> CRT headers, #undef won't fix that damage
>
>>
>> or include the additional headers *before* the Perl headers.
>>
>> See for example this code:
>>
>>     https://github.com/rjbs/Time-Piece/blob/82beba4/Piece.xs#L135-L142
>>
>> It has specific reasons for calling the RTL version of some functions,
>> so it makes sure not to go through the Perl layer.
>>
>> Cheers,
>> -Jan
>
>
> The correct fix is
>
> #define NO_XSLOCKS /* dont hook libc calls to virtualize different
> faux-processes for psuedofork, this the most common option*/
> #define PERLIO_NOT_STDIO 0 /* don't redirect stdio to perlio, this is rarely
> needed, but try it too if you get errors after NO_XSLOCKS*/
>
> before
>
> #define PERL_NO_GET_CONTEXT
> #include "EXTERN.h"
> #include "perl.h"
> #include "XSUB.h"
>
> Some minor residual problems result such as
>
> #define WORD 264
>
> from perly.h



-- 
Oleg Pronin,
CTO, Co-Founder,
Crazy Panda LTD
CP Decision LTD

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