Simon Urbanek
2003-Oct-23 14:20 UTC
[Rd] linking to R.dll on Win32 - issues with recent MinGW?
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
Prof Brian Ripley
2003-Oct-23 15:08 UTC
[Rd] linking to R.dll on Win32 - issues with recent MinGW?
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:> 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 > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > >-- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
Duncan Murdoch
2003-Oct-24 01:01 UTC
[Rd] linking to R.dll on Win32 - issues with recent MinGW?
On Thu, 23 Oct 2003 14:21:08 +0200, you wrote:>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.I can help with one of them, but not the main one.>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?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> >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 > >______________________________________________ >R-devel@stat.math.ethz.ch mailing list >https://www.stat.math.ethz.ch/mailman/listinfo/r-devel