Jim
Jim

Reputation: 21

How to created a shared library (dylib) using automake that JNI/JNA can use?

How do I convince LibTools to generate a library identical to what gcc does automatically?

This works if I do things explicitly:

gcc -o libclique.dylib -shared disc.c  phylip.c Slist.c  clique.c
cp libclique.dylib [JavaTestDir]/libclique.dylib

But if I do:

Makefile libclique.la (which is what automake generates)
cp .libs/libclique.1.dylib [JavaTestDir]/libclique.dylib 

Java finds the library but can't find the entry point.

I read the "How to create a shared library (.so) in an automake script?" thread and it helped a lot. I got the dylib created with a -shared flag (according to the generated Makefile). But when I try to use it from Java Native Access I get a "symbol not found" error.

Looking at the libclique.la that is generated by Makefile it doesn't seem to have any critical information in it, just looks to be link overloads and moving things around for the convenience of subsequent C/C++ compiler steps (which I don't have), so I would expect libclique.1.dylib to be a functioning dynamic library.

I'm guessing that is where I'm going wrong, but, given that JNA links directly to a dylib and is not compiled with it (per the example in the discussion cited above), it seems all the subsequent compilation steps described in the LibTools manual are moot.

Note: I'm testing on a Mac, but I'm going to have to do this on Windows and Linux machines also, which is why I'm trying to put this into Automake.

Note2: I'm using Eclipse for my Java development and, yes, I did import the dylib.

Thanks

Upvotes: 2

Views: 1332

Answers (1)

Diego Elio Pettenò
Diego Elio Pettenò

Reputation: 3240

You should be building a plugin and in particular pass

libclique_la_LDFLAGS = -avoid-version -module -shared -export-dynamic

This way you tell libtool you want a dynamically loadable module rather than a shared library (which for ELF are the same thing, but for Mach-O are not.)

Upvotes: 2

Related Questions