Hello all,
In short, I have a static library (.a) and want to make a shared library (.so)
that exports all of the functions in the static library for use by FFI. I have
something building, but it is presumably being too helpful and stripping out
the unreferenced symbols, leaving me with nothing?? Is there an easy way to
include the code in the resulting .so?
I am starting to work with a data acquisition board from Access IO. My
original plan was to write something in C++ that would wrap the board and
driver with a socket server. The idea was to get the benefit of a separate OS
process that could aggressively (quasi real time) move data as needed, allowing
Pharo to simply read from a socket and otherwise be unblocked.
On re-reading some of the documentation, this could turn out to be as simple as
calling a few functions to set options, allocating a block of memory and
calling a funtion to turn the board loose to fill the buffer with data. In
this model, I would then, on timer or user interaction, call a polling function
to see how much of the buffer has yet to be filled. It might turn out to be
very simple to do.
Snag: there is no .so, so AFAICT, there is nothing to ask FFI to load; I am
mostly concerned with doing this on Linux. I created a quick .so project and
linked the (.a) static library. The result builds, but at 5.3 kb, it cannot
possibly contain the code I hope to put in it. I am looking at options such as
-export-dynamic and hunting around for ways to disable stripping or similar
concepts. Any ideas? Worst case, I could add functions that wrap the
functions I want to call and bind FFI to them, but that is hopefully not
necesssary.
The closest I have come to this is the Gnu Scientific Library. The Linux .so
files would not load due to cyclic dependencies between BLAS and the balance of
the library, and it was clear from searches that they had no plans to fix it
("oh, that's one of those dynamic languages"). I was easily able to create a
shared library that links both parts of GSL, exports a few functions to avoid
having to roll my own callbacks, and all is well. Either I got lucky with the
exports and any relevant options, or the .so's make the problem less
challenging than my current task.
Bill
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
