[Rd] Problem building DLL under Windows

[Simon Urbanek]

Jon,

On Apr 3, 2009, at 10:18 , Jon Senior wrote:

> Apologies if this has appeared before, but I've searched the  
> archives and all the documentation and I can't find anything which  
> helps.
>
> I'm trying to build a DLL under windows. The process (more on that  
> later) works fine under Linux and gives the illusion of working  
> under Windows, but attempting to load the resulting DLL using  
> dyn.load results in:
>
> Error in inDL(x, as.logical(local), as.logical(now), ...) :
>  unable to load shared library: 'C:/Documents... '
>  LoadLibrary failure: Invalid access to memory location.
>
> Searching Google shows that the LoadLibrary message is unique to R  
> (Or no-one else is admitting to it).
>
> The first problem is that the library is actually a wrapper around  
> an existing library to make it usable under R, but the original  
> library is built as a static object (and for reasons of controlling  
> exciting versioning problems, I'd prefer it to stay that way).
>
> Under Linux, I pass the library to gcc using PKG_LIBS=-static lib.a  
> and it builds fine.
>

That is true only for very specific architectures and OS combinations  
but not on most systems (including Linux). Shared objects must be  
compiled to contain position-independent code (PIC) such that they can  
be re-located when loaded dynamically. In general you cannot use a  
static library in a package unless the library was specifically  
compiled with -fPIC.

Also please note that the above is possibly not what you want: -static  
is not an option that applies to the library - it's a global option  
for the linker which affects *all* libraries and possibly even the crt  
code and compiler-related libraries (this depends on the platform). It  
may cause additional problems since you may need to link R library  
dynamically. All this is not related to Windows - this applies in  
general on any platform (including Linux).


> Under Windows, I put the following in Makevars.win:
> PKG_LIBS -Lc:/Path/To/Library -llib.name
> and it builds fine (GCC returns with no errors and I have what  
> appears to be an appropriately sized DLL in the directory).
>
> I've tried passing various flags into gcc, but I really don't know  
> what I'm doing at this point with regard to building under windows  
> (I have a pretty good grasp of how to compile libraries under Linux,  
> and understand the concepts involved in shared libraries. I get the  
> impression however that I'm missing something about Windows DLLs.
>

See above, this may not be DLL-specific. Additionally, please make  
sure you're using the right tools (MinGW gcc) for both your static  
library and the package (you have indicated the you do, but just  
making sure :))..
I have tested a toy example with your setup and all was working just  
fine, so for further help you may have to reveal exactly what library  
you are using etc. since the devil may be in the details (if the  
general advice above doesn't help).


> Compulsory version information:
> OS: Windows XP SP2
> R: 2.8.1
> GCC: 4.2.1-sjlj (mingw32-2) (From Rtools29.exe)
>
> For the record, I've read http://www.stats.uwo.ca/faculty/murdoch/software/compilingDLLs/readme.packages.txt 
>  which hints at some requirement for DLLs to use _cdecl. I've  
> started exploring along this line, but there's a lot of  
> documentation to trawl through to make sense of it all and I don't  
> want to go off chasing a red herring if I just need to pass a  
> special --make-it-work flag to gcc.
>

AFAICS that is only mentioned with respect to VC - the current tools  
are smart enough with gcc. There are some issues when importing  
variables from R itself, but that should not be related to your code  
(unless you use this feature outside of the standard R headers).

Cheers,
Simon


> In the only thread I found which appeared to have any similarities,  
> Prof. Ripley said that there was a solution (or hint): "It is there,  
> unfortunately along with a lot of uniformed speculation." Of course,  
> the uninformed speculation is still in the archives making it no  
> easier to find no than in August 2007! Perhaps someone who  
> understands this stuff (or has some experience of it) could provide  
> a hint as to how to proceed. :-)
>
> Thanks in advance.
>
> -- 
> Jon Senior <jon at restlesslemon.co.uk>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>