The simplest solution is to build nlopt as a shared library and link to that. See http://ab-initio.mit.edu/wiki/index.php/NLopt_Installation#Shared_libraries (I may be wrong, but I don't think it's always possible to link a static library into a shared library regardless of how the static library was build (think: PIC) and on all platforms. This is why I say replacing the static library with a shared library is the simplest solution -- we know it will work.)
[Rcpp-devel] Symbol not found when including an external library
3 messages · Steve Jaffe, Dirk Eddelbuettel, Simon Zehnder
On 4 September 2013 at 21:08, Steve Jaffe wrote:
| The simplest solution is to build nlopt as a shared library and link to | that. See http://ab-ini tio.mit.edu/wiki/index.php/NLopt_Installation#Shared_libraries Please see the subsequent posts by Doug -- we already have that. | (I may be wrong, but I don't think it's always possible to link a static | library into a shared library regardless of how the static library was build | (think: PIC) and on all platforms. If memory serves, you need -fPIC and can just 'glue' the object files into a static libfoo.a via the ar command. Been there, done that, but don't have an example handy. | This is why I say replacing the static library with a shared library is the | simplest solution -- we know it will work.) I fear it is far from that easy as you also need ldd to play along, ie dll needs to be told where the library is. What R does is (AFAICR) not identical because it manages dlopen() itself -- which is why we have libs/foo.so rather than a standard libfoo.so (and also why Rcpp ships two libraries but I digress). It is _all_ hairy. The easiest approaches are, in my view, -- to rely on a system-wide library -- possibly rely on another build (hence Doug's post about other nlopt packages) provided they built the library in a way we can use -- punt and place all files in src/ which is what I convinced the authors / maintainers of phylobase to do -- and then the multi-arch builds "just work" as R know how to the The Right Thing (TM) Very easy to get pulled into a fight against wind mills here. Resist, if you can. Dirk
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
Short question at this point of the discussion: Is it possible to use useDynLoad in the NAMESPACE file to load in addition to a dynamic library of nlopt? Best Simon Gesendet ?ber den BlackBerry? Service von E-Plus. -----Original Message----- From: Dirk Eddelbuettel <edd at debian.org> Sender: rcpp-devel-bounces at lists.r-forge.r-project.orgDate: Wed, 4 Sep 2013 21:38:02 To: Steve Jaffe<sjaffe at riskspan.com> Cc: rcpp-devel at lists.r-forge.r-project.org<rcpp-devel at lists.r-forge.r-project.org> Subject: Re: [Rcpp-devel] Symbol not found when including an external library
On 4 September 2013 at 21:08, Steve Jaffe wrote:
| The simplest solution is to build nlopt as a shared library and link to | that. See http://ab-ini tio.mit.edu/wiki/index.php/NLopt_Installation#Shared_libraries Please see the subsequent posts by Doug -- we already have that. | (I may be wrong, but I don't think it's always possible to link a static | library into a shared library regardless of how the static library was build | (think: PIC) and on all platforms. If memory serves, you need -fPIC and can just 'glue' the object files into a static libfoo.a via the ar command. Been there, done that, but don't have an example handy. | This is why I say replacing the static library with a shared library is the | simplest solution -- we know it will work.) I fear it is far from that easy as you also need ldd to play along, ie dll needs to be told where the library is. What R does is (AFAICR) not identical because it manages dlopen() itself -- which is why we have libs/foo.so rather than a standard libfoo.so (and also why Rcpp ships two libraries but I digress). It is _all_ hairy. The easiest approaches are, in my view, -- to rely on a system-wide library -- possibly rely on another build (hence Doug's post about other nlopt packages) provided they built the library in a way we can use -- punt and place all files in src/ which is what I convinced the authors / maintainers of phylobase to do -- and then the multi-arch builds "just work" as R know how to the The Right Thing (TM) Very easy to get pulled into a fight against wind mills here. Resist, if you can. Dirk
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com _______________________________________________ Rcpp-devel mailing list Rcpp-devel at lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel