Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re: With Inline::C, how to link to external library? (XS)

by tye (Sage)
on Aug 07, 2016 at 19:44 UTC ( #1169303=note: print w/replies, xml ) Need Help??


in reply to With Inline::C, how to link to external library?

Worst case you can use Inline::C to generate the XS and then build the XS module in the normal manner where you can add options to your Makefile.PL to control how linking is done. I tend to go that route anyway as Inline::C often encourages better (less buggy) interface choices while not attempting to rebuild at run-time is often a better choice.

- tye        

  • Comment on Re: With Inline::C, how to link to external library? (XS)

Replies are listed 'Best First'.
Re^2: With Inline::C, how to link to external library? (XS)
by stevieb (Canon) on Aug 07, 2016 at 21:33 UTC

    Thanks tye.

    So I've made an attempt at this, but am still getting XS errors that I can't figure out, and am hoping I'm doing something blatantly wrong, or someone with understanding can spot something else. Here's my Makefile.PL:

    use ExtUtils::MakeMaker; my %options = %{ { 'INC' => '-I/home/pi/repos/scripts/c/rpi/dht11/library -I/usr/local/ +lib -I/home/pi/repos/wiringPi/wiringPi', 'NAME' => 'perl_pl_b1a3', 'TYPEMAPS' => [ '/home/pi/perl5/perlbrew/perls/perl-5.24.0/lib/5.24.0/ExtUtils/typ +emap' ], 'VERSION' => '0.00', 'CCFLAGS' => ' -fwrapv -fno-strict-aliasing -pipe -fstack-protector- +strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=6 +4 -D_FORTIFY_SOURCE=2 -lwiringPi' } }; WriteMakefile(%options); # Remove the Makefile dependency. Causes problems on a few systems. sub MY::makefile { '' }

    The library I'm trying to load is wiringPi. I've tried also libwiringPi. I've also tried adding -I/usr/local/lib to the CCFLAGS, as well as -L/usr/local/lib. Here's the /usr/local/lib dir that I've included in INC:

    libwiringPiDev.so -> libwiringPiDev.so.2.32 libwiringPiDev.so.2.32 libwiringPi.so -> libwiringPi.so.2.32 libwiringPi.so.2.32

    ...and the error:

    Running Mkbootstrap for perl_pl_b1a3 () chmod 644 "perl_pl_b1a3.bs" cc -c -I/home/pi/repos/scripts/c/rpi/dht11/library -I/usr/local/lib - +I/home/pi/repos/wiringPi/wiringPi -fwrapv -fno-strict-aliasing -pipe +-fstack-protector-strong -I/usr/local/include -I/usr/local/lib -D_LAR +GEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -lwiringPi +-O2 -DVERSION=\"0.00\" -DXS_VERSION=\"0.00\" -fPIC "-I/home/pi/perl +5/perlbrew/perls/perl-5.24.0/lib/5.24.0/armv7l-linux/CORE" perl_pl_ +b1a3.c In file included from perl_pl_b1a3.xs:3:0: /home/pi/perl5/perlbrew/perls/perl-5.24.0/lib/5.24.0/armv7l-linux/CORE +/XSUB.h:142:31: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute_ +_’ before ‘void’ # define XS_EXTERNAL(name) void name(pTHX_ CV* cv __attribute__unu +sed__) ^ perl_pl_b1a3.c:163:1: note: in expansion of macro ‘XS_EXTERNAL’ XS_EXTERNAL(boot_perl_pl_b1a3); /* prototype to pass -Wmissing-protot +ypes */ ^ Makefile:331: recipe for target 'perl_pl_b1a3.o' failed make: *** [perl_pl_b1a3.o] Error 1

    It's like it's not finding the library or something, as I can reproduce this exact behaviour with this simple script, by trying to link to a non-existent library:

    use warnings; use strict; use Inline C => Config => ccflagsex => '-lblah'; use Inline C => 'END'; say(); __END__ __C__ void say() { int x = myget(); printf("myvar: %d\n", x); }

      See the "Dynamic Linking" section of "perl -V". My first thought was that you may need to specify changes/additions to one or more of ccdlflags, cccdlflags, and lddlflags, perhaps dropping parts of what you specified to be added to CCFLAGS.

      But, after several tries, I finally did find the actual error amid all of the context information:

      error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’ # define XS_EXTERNAL(name) void name(pTHX_ CV* cv __attribute__unu +sed__) ^

      Which sounded like a C preprocessor directive was being interpreted as C code. But then I realized that this was just more (actually helpful) context information and the location of the error was actually shown as:

      perl_pl_b1a3.c:163:1: note: in expansion of macro ‘XS_EXTERNAL’ XS_EXTERNAL(boot_perl_pl_b1a3); /* prototype to pass -Wmissing-protot +ypes */ ^

      Which tells me that you need to look at the line(s) before that, line 162 of perl_pl_bla3.c, where you are likely missing some terminating punctuation, like a ';'. Or you have some unclosed construct (like a comment or quoted string or such). The error could be further up from line 162, of course, and perhaps even in some other file (if line 163 is almost immediately preceeded by an #include, for example).

      I didn't notice any mistakes that would explain this problem in the C code that you posted.

      But I was surprised at a very specific path to your typemap definitions:

      'TYPEMAPS' => [ '/home/pi/perl5/perlbrew/perls/perl-5.24.0/lib/5.24.0/ExtUtils/typ +emap' ],

      - tye        

        You sent me down the right path from what I can tell, tye.

        On a different computer, different version of Perl (5.18 vs 5.24 which I was using yesterday), I was having the exact same issue, but I eventually tracked down something that fixed the issue, albeit I'm sure it's wrong.

        In /usr/lib/perl/5.18/CORE/XSUB.h which the error was referencing (same file, different location on yesterday's test), I made this change (ie. I removed void):

        diff XSUB.h.orig XSUB.h 141c141 < # define XS_EXTERNAL(name) void name(pTHX_ CV* cv __attribute__un +used__) --- > # define XS_EXTERNAL(name) name(pTHX_ CV* cv __attribute__unused_ +_)

        I also slightly changed up my Inline::C test code to this (which also breaks without the above change):

        use warnings; use strict; use Inline (C => 'DATA', libs => ' -lwiringPi'); say(); __DATA__ __C__ #include <stdio.h> #include <wiringPi.h> void say(){ pinMode(1, INPUT); printf("hello, world!\n"); }

        It works!

        If I remove the libs directive in the use Inline::C ... statement, I get undefined symbol PinMode, which I fully expect. Put it back in, and voila... things work.

        Without removing the void identifier, it breaks when trying to use ANY external shared library, whether it can be found or not. This is easily reproduceable... just try to include a library that does or doesn't exist on the system. As soon as it tries to do EXTERN type stuff, the line that I removed void from is triggered, and breaks.

        Does my change look proper to you? Is this a bug? I'm not sure how to test this without using Inline::C to see if it's a global XS thing, or just Inline thing. After I get some more feedback, I'll be glad to test further.

      I can reproduce this exact behaviour with this simple script, by trying to link to a non-existent library

      I can reproduce the problem with an even simpler script:
      use Inline C => 'END'; say(); __END__ __C__ void say() { printf("6\n"); }
      The first line of that code is wrong. The corrected version of that script is:
      use Inline C; say(); __END__ __C__ void say() { printf("6\n"); }
      Update: An alternative way of writing out the script would be:
      say(); use Inline C => <<'END'; void say() { printf("6\n"); } END
      I think that might have led to your confusion.

      Cheers,
      Rob

        Yep, for the love of all things good... after all of my testing, I made the one mistake I rarely make; I made two changes at once instead of one at a time then testing.

        Although hacking the .h file seemed to work, it was at that time I also changed from using END to DATA. After further testing and reverting the changed file, it works just dandy.

        Thanks all for the feedback.

        A small clarification as to what happens here: The string 'END' and the __C__ section are combined to produce the C unit (C source code). After preprocessing, C compiler will see it as

        END void boot_duh(PerlInterpreter* my_perl __attribute__((unused)), CV* cv + __attribute__((unused))); void boot_duh(PerlInterpreter* my_perl __attribute__((unused)), CV* cv + __attribute__((unused)))
        Resulting bogus code trips up the compiler.

        Now the question is, why such a feature? Is it used a lot? Shouldn't there be a warning when source string and section are both present? Hm.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1169303]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2020-10-28 02:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My favourite web site is:












    Results (259 votes). Check out past polls.

    Notices?