[Rd] Problem building DLL under Windows

[Jon Senior]

On Fri, 3 Apr 2009 12:36:00 -0400
Simon Urbanek <simon.urbanek at r-project.org> wrote:

> 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.

It was indeed compiled with -fPIC on Linux. I had forgotten that and wonder if it might be related.
 
> 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).

AFAICT -static can be used to force inclusion of a library statically. It may not be the case, the bulk of my coding experience is in Java, not wrapping esoteric functions in to R-callable C code! :-) Strangely though, it seems to work fine. I'll have to do some more tinkering to see if it can forced into a single build, rather than a 2-stage one. 

> 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 :))..

Checked and doubled checked. It's a clean installation of XP running under QEMU and has nothing but R and Rtools installed.

> 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).

OK. Since my previous mail, I discovered the pedump tool, and found that both pedump and objdump will segfault (So it appears, Windoze doesn't give enough information to be sure!) if I attempt to retrieve the Ordinal table from the freshly compiled DLL. This suggests that something is going awry during the second stage of the build (since I can retrieve the same information from the .lib file).

The problem with adding more details is the nature of the work. At the minute, I'm obliged to keep the fine details secret. I had a feeling that this might have been the case, but I thought it was worth seeing if someone had already encountered this and solved it in a different specific case.

> 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).

OK.

Thanks for your help. Looks like the next step is probably going to be combining both compilation steps into a single Makefile. I really hate Makefiles! :-(

-- 
Jon Senior <jon at restlesslemon.co.uk>