Hello all, With no small amount of help, I might have done it!!! :) After a few overly verbose sets of search results, something like "convert .a to .so" turned up the following: http://www.linuxquestions.org/questions/linux-software-2/convert-static-libr... In this case, the natural steps are: ar -x libaiousb.a gcc -shared *.o -o libAccessIO-USB.so rm *.o Hitting the resulting .so with objdump suggests that it might be what I need. It will take some time to create and check the bindings, but I'm optimistic. At the least, it was a nice exercise. More to come. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab@anest.ufl.edu] Sent: Thursday, August 19, 2010 9:31 PM To: Pharo-project@lists.gforge.inria.fr; squeak-dev@lists.squeakfoundation.org Subject: [Pharo-project] Wrap .a into a .so for use by FFI 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project