[Rd] Including multiple third party libraries in an extension

[Simon Urbanek]

Tyler,

On Nov 11, 2011, at 7:55 PM, Tyler Pirtle wrote:

> Hi,
> 
> I've got a C extension structured roughly like:
> 
> package/
>  src/
>    Makevars
>    foo.c
>    some-lib/...
>    some-other-lib/..
> 
> where foo.c and Makevars define dependencies on some-lib and
> some-other-lib. Currently I'm having
> Makevars configure;make install some-lib and some-other-lib into a local
> build directory, which produces
> shard libraries that ultimately I reference for foo.o in PKG_LIBS.
> 
> I'm concerned about distribution. I've setup the appropriate magic with
> rpath for the packages .so

That is certainly non-portable and won't work for a vast majority of users.


> (meaning
> that when the final .so is produced the dynamic libraries dependencies on
> some-lib and some-other-lib
> will prefer the location built in src/some-lib/... and
> src/some-other-lib/... But does this preclude me from
> being able to distribute a binary package?

Yes. And I doubt the package will work the way you described it at all, because the "deep" .so won't be even installed. Also there are potential issues in multi-arch R (please consider testing that as well).


> If I do want to build a binary
> distribution, is there a way I can
> package up everything needed, not just the resulting .so?
> 
> Or, are there better ways to bundle extension-specific third party
> dependencies? ;) I'd rather not have
> my users have to install obscure libraries globally on their systems.
> 

Typically the best solution is to compile the dependencies as --disable-shared --enable-static --with-pic (in autoconf speak - you don't need to actually use autoconf). That way your .so has all its dependencies inside and you avoid all run-time hassle. Note that it is very unlikely that you can take advantage of the dynamic nature of the dependencies (since no one else knows about them anyway) so there is not real point to build them dynamically.

Also note that typically you want to use the package-level configure to run subconfigures, and *not* Makevars. (There may be reasons for an exception to that convention, but you need to be aware of the differences in multi-arch builds since Makevars builds all architectures at once from separate copies of the src directories whereas the presence of configure allows you to treat your package as one architecture at a time and you can pass-though parameters).

Cheers,
Simon