in reply to Re^2: Help with Inline C
in thread Help with Inline C

It should be:
use Inline C => Config => LIBS => '-lparser';
but that pre-supposes that there actually is a library named libparser.a that is going to resolve the symbol. If that's not the case then different action needs to be taken. Fawk, the library is actually named 'libfoo.a', in which case you need to:
use Inline C => Config => LIBS => '-lfoo';
and if the library is not to be found in one of the locations that is searched by default:
use Inline C => Config => LIBS => '-L/path/to/lib -lfoo';
It's also a good idea to force a verbose (noisy) build, as the compiler warnings you then see may help solve the problem:
use Inline C => Config => BUILD_NOISY => 1, LIBS => '-L/path/to/lib -lfoo';
If, however, there's no library at all that resolves parser(), then you need to spell the function out in the C code in the script:
use Inline C => <<END_C; #include <stdio.h> #include <stdlib.h> #include <string.h> // Wild guess follows: int parser (char * url, char * page, char * pool, int lenx2) { // C code that does whatever // it is that parser()does. } char* MyParser(char *url, char* page) { char *pool; int len; int ret; len = strlen(page); // page = (char*)malloc(len); pool = (char*)malloc(2*len+1); // parsing page ret = parser(url, page, pool, 2*len+1); if(ret > 0) return pool; free(pool); } END_C
Seems to me that once you get the C code to compile, the perl code will croak because you're calling MyParser() with one arg, but it needs 2 args.

Cheers,
Rob

Replies are listed 'Best First'.
Re^4: Help with Inline C
by downer (Monk) on Oct 15, 2007 at 14:37 UTC
    that seems to help. now I am just having compilation errors, a step in the right direction. I am a C newbie, so the mechanics of why everything is so is at this point beyond me.

    couldnt I also do something like  gcc -c parser.c mycode.c then  use Inline C => Config => LIBS => '-lparser.o';
    is this totally different than what is required?
      ... then use Inline C => Config => LIBS => '-lparser.o';

      I don't think that would work - but the following config option does:
      use Config; use Inline C => Config => LDDLFLAGS => $Config::Config{lddlflags} . ' /full/path/to/parser.o';
      Alternatively, once you've got 'parser.o', you could just go that one extra step and create 'libparser.a' with:
      ar cru libparser.a parser.o
      Then LIBS => '-L/full/path/to/lib -lparser' should also work fine.

      Cheers,
      Rob
Re^4: Help with Inline C
by downer (Monk) on Oct 15, 2007 at 14:49 UTC
    and of course i supplied MyParser with 2 arguments :)
Re^4: Help with Inline C
by downer (Monk) on Oct 15, 2007 at 15:02 UTC
    I have noticed that some quoted strings in my code "\r\n" are being translated to (to a return and newline) in the corresponding XS file. this is whats creating some errors- now i have some mis-formed lines! is there a way to avoid ths?
      downer
      I have noticed that some quoted strings in my code "\r\n" are being translated to (to a return and newline) in the corresponding XS file.

      When I write Inline-C stuff, I have to add an extra escape to the backslashes:

      ... char string [] = "Hello World\\n"; ...

      Regards

      mwa

      now i have some mis-formed lines

      I have not struck this problem before (though it seems mwah has). Do you mean that the following simple Inline::C function leads to a corrupted XS file:
      void greet() { printf("Hello World\n"); }
      If not, then can you provide a *small* complete script that demonstrates the issue.

      Cheers,
      Rob
      Update:I hadn't noticed the OP's usage of <<END_C and wasn't aware of the gotcha (explained below by tye) associated with that usage.

        <<END_C is the same as <<"END_C" which means one needs to put a backslash in front of any occurrences of \, $, or @ in the following C code. If he used <<'END_C' instead, then he wouldn't have that problem.

        - tye