## SWI-Prolog FFI Problem: Getting Prolog and C to work together on MacOS?

Hi,
I'm trying to get SWI-Prolog and C to work together on MacOS 10.4.11 (Tiger) using the Prolog's Foreign Interface. Unfortunately I'm not an expert in either Prolog, or C, so I would appreciate some help.

It seems that there are some issues with the foreign function interface specifically on MacOS. The Prolog manual has a very nice example of how to use FFI with C (http://gollem.science.uva.nl/SWI-Prolog/Manual/foreignxmp.html)... which this doesn't work for me on MacOS, but worked fine under Linux (Ubuntu 8.04 Hardy).

I don't understand what's wrong with 'strlen' initially:

$gcc -I/opt/local/lib/swipl-5.6.15/include -fpic -c lowercase.c lowercase.c:1: warning: -fpic is not supported; -fPIC assumed lowercase.c: In function 'pl_lowercase': lowercase.c:14: warning: incompatible implicit declaration of built-in function 'strlen' ... and even though we do get an object file in the end, we can't create (and register?) a library at the next step (this seems to be the MacOS-specific problem):$ gcc -shared -o lowercase.so lowercase.o
i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
/usr/bin/ld: Undefined symbols:
_main
_PL_get_atom_chars
_PL_register_foreign
_PL_unify_atom_chars
_PL_warning
collect2: ld returned 1 exit status

Any suggestions? I couldn't find anything online except http://www.phil.uu.nl/~xges/HOWTO/swipldynlib.html which seems quite old? Should I go for it anyway?

Thank you,
-- Georgi

## Comment viewing options

### Sorry..

LtU is a language theory discussion site. A better place to ask this sort of question is a prolog or swi forum or irc channel..

### Not just "theory", but

Not just "theory", but indeed only topics that are of general interest and not issues with specific tools.

### Indeed...

... I must agree with Ehud. FFI is an interesting (and hard!) problem, in theory and in practice, and relevant to LtU. If I knew anything about SWI Prolog's FFI, I would answer, and I would certainly be interested in reading a guru's comments on this subject, as long as it went a little beyond a recipe to get this particular case to work.

I'm somewhat of the philosophy that FFI should be avoided. I think that inter-process communication via sockets or some other message-passing mechanism is a superior solution for 80-90% of the programs that use FFI.

However, I also have the nagging feeling that the other 10-20% is a rather important set of programs, and that completely neglecting FFI is a mistake. I'm having a hard time coming up with good arguments for or against this, though.

### Industry examples

Traditionally, I think few people would use FP if they can't get at the "metal" when writing video games or embedded systems. That can be changing given the big horsepower in some of today's video game systems, of course.

### Don't Bother

FFIs are archaic and brutally difficult to get working. Write a some small programs tie them together using the a little bit of shell script to wire them together.

That's how it's supposed to be done. OSX *is* UNIX.

Of course, all I read is how shell is archaic too, but I've never had a linking problem with a pipe...