Skip to content

linking to R.dll on Win32 - issues with recent MinGW?

3 messages · Simon Urbanek, Brian Ripley, Duncan Murdoch

#
I encountered several strange issues when linking to R.dll on Windows 
and I wonder if anyone of the Windows savvy-folks here had seen some of 
the issues before and have some explanation.

My Rserve links to R dynamic library. That works perfectly on unix 
boxes and worked fairly well with older MinGW and older R (<=1.7.1). 
What I do in fact is that I specify
-L$(R_HOME)/bin -lR
when linking. This produced valid exe which was linked to R.dll. In 
fact you could compile everything with the regular binary distribution 
of R, even without R sources (MinGW got all it needs directly from 
R.dll).

Now with R-1.8.0 (which is presumably compiled with more recent MinGW) 
and MinGW 3.1 this doesn't work anymore on certain Win32 platforms, 
e.g. I got reports that on W2k Rserve bails out with "Can't load 
R.dll". Further investigation reveals that the .exe tries to load "R" 
file and not "R.dll". But if you copy R.dll to R then both R and R.dll 
get loaded, since R loads Rblas.dll which loads (correctly) R.dll. Then 
everything crashes (presumably the two dlls fight each other). XP seems 
to have a fix for that (i.e. a request for "R" will in fact load 
"R.dll"), but not W2k.

Did anyone see this or does anyone have an idea how to prevent this 
(except for downgrading MinGW)?

Now, I thought I'll use libR.a from the R sources instead of using the 
final R.dll, because that's what libR.a is for, right? The first 
obstacle was that libR.a doesn't export R_Home which I need to set in 
my init routine, but fortunately there is "exported-vars" for that 
case. But after finally compiling everything, Rserve crashes. It 
doesn't even get as far as main. What I get is this:
Warning: Invalid Address specified to RtlSizeHeap( 003F0000, 0146008 )
and later a crash somewhere deep in libwsock32 (the trace is rather 
weird) ... I guess the problem is the heap, not wsock itself. Any idea 
what that could be?

All the above was tested with MinGW-3.1.
Any ideas? Is that a MinGW bug or something I did? ;)

Thanks.
Simon

---
Simon Urbanek
Department of computer oriented statistics and data analysis
University of Augsburg
Universit?tsstr. 14
86135 Augsburg
Germany

Tel: +49-821-598-2236
Fax: +49-821-598-2200

Simon.Urbanek@Math.Uni-Augsburg.de
http://simon.urbanek.info
#
I was told that direct linking against foo.dll is not supported. One
problem is that the link priority order gets broken, and R.dll gets used
for things it should not be used for (malloc springs to mind).

You should be able to use libR.a, though.  It does not need to export 
R_Home, as you should know what that is when you call R_SetParams.
I would make sure that you are really using the mallocs you think you are.
(One day soon we will try to find a better solution for that, but that 
probably depends on me having a working Windows laptop again, as well as 
time to program on it.)

In a few places (Rlapack.dll as I recall) we have had to force in entry 
points to get things resolved in the right place: pedump will tell you 
where they are resolved, and at least this is done at link time and not 
run time so is fairly easy to track down.

Brian
On Thu, 23 Oct 2003, Simon Urbanek wrote:

            

  
    
#
On Thu, 23 Oct 2003 14:21:08 +0200, you wrote:

            
I can help with one of them, but not the main one.
This looks like what I see every time I run R under gdb.  The problem
is a bug/incompatibility in the MinGW run-time library.  R has its own
malloc, and some functions in the startup code expect the standard
MSVCRT malloc to be called, and it's not.  Within the debugger the
error is harmless, except for wasting some time.  I don't see the
later crash at a different location, but it sounds like a similar
symptom.

The workaround the MinGW folks told me was to rename the R malloc to
something else (e.g. by a define in Defn.h).  However, I got this
advice too close to the 1.8.0 release date to want to risk it.  I'll
try it for 1.9, not 1.8.1.

Duncan Murdoch