-1

I'm using MSVC2013 Update 5 and import library for R.dll from Revolution R 3.2.2 x64 to compile custom version of Rserve (https://rforge.net/Rserve/), which used embdded R.dll. CRT type is multithreaded debug DLL. Program crashes when calling to fprintf(stderr, ...) in a very strange way:

ntdll.dll!RtlRaiseStatus()  Unknown
ntdll.dll!string "Enabling heap debug options\n"()  Unknown
ntdll.dll!RtlEnterCriticalSection() Unknown
msvcrt.dll!_lock_file() Unknown
msvcrt.dll!putc()   Unknown
R.dll!000000006c8dd814()    Unknown
R.dll!000000006c8df8e8()    Unknown
R.dll!000000006c8e3d74()    Unknown
R.dll!000000006c8dd00d()    Unknown
RServe.exe!loadConfig(const char * fn) Line 2113    C
RServe.exe!main(int argc, char * * argv) Line 4247  C
[External Code]

The code is like this:

 if(checkScriptFileName(p) != 0)
        fprintf(stderr, "Error: Invalid script file name: '%s'.\n", p);

According to my understanding, fprintf() should be located in the msvcr120d.dll, but it accesses somehow msvcrt.dll and goes through R.dll.

Did anyone face similar issue? Can you please suggest, what can I do in this case in order to solve the issue? (For those who did not understood what about this question) THE QUESTION IS THAT HOW TO FIX THIS CRASH (which normally should not happen, because I've passed all correct parameters to the fprintf()).

Update: More interesting details - tried to switch to static variant of CRT, got following interesting stuff:

1>  Generating Code...
1>LIBCMTD.lib(sprintf.obj) : error LNK2005: sprintf already defined in R.lib(R.dll)
1>LIBCMTD.lib(printf.obj) : error LNK2005: printf already defined in R.lib(R.dll)
ivan.ukr
  • 2,853
  • 1
  • 23
  • 41
  • You do understand that the _very official position from R Core_ is that anything to do with MSVC is _unsupported_. R is built with the MinGW toolchain. – Dirk Eddelbuettel Oct 15 '15 at 01:07
  • It doesn't matters. This is indeed bad design. Even with MinGW any DLL should not export symbol found in the C runtime library. – ivan.ukr Oct 15 '15 at 06:27
  • And unfortunately, when the deal comes to postmortem debugging, all MinGW executables became useless. Read more here. http://blog.morlad.at/ I've also tried mentioned there tool cv2pdb, it didn't help me - just did not generated correct PDB from EXE with standard GCC-generated debug info. – ivan.ukr Oct 15 '15 at 06:34
  • Posted bug report to the R Bugzilla https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16565 Hopefully, they will fix in some later versions. In fact, just need to have manual DEF file and exclude all CRT stuff that may happen in the DLL for some reason (or better, completely exclude CRT stuff). – ivan.ukr Oct 15 '15 at 06:39
  • So MINGW will be my choice when it will be able to generate full-featued PDB files (no matter, only it or in additioan to standard formarts like DWARF) for the executables/DLLs. – ivan.ukr Oct 15 '15 at 06:45
  • R behaves as documented and advertised. You need MinGW. Feel free to post a bug report at Microsoft's site informing them that their compiler fails to produce proper code from the R sources. – Dirk Eddelbuettel Oct 15 '15 at 11:57
  • @Dirk, of course, you may tell me any "official"-like statements like this, but I don't care. What I really care of is what we have in really. What I can see is that function printf() which usually comes from C runtime libary now suddenly comes from R.dll. In my humble opinion, as a Senior software Engineer with 15 years experience in developong backend systems, this is BAD DESIGN. And I have posted the bug report and suggest how to improve/fix this situation. I hope R developers and comminity are highy interested in the making R available and compatible with the mainstream Windows toolchain. – ivan.ukr Oct 15 '15 at 12:33
  • You still don't get it. The bug is with the toolchain. – Dirk Eddelbuettel Oct 15 '15 at 12:47
  • @Dirk, I still think including into custom DLL functions that come from CRT DLL is BAD DESIGN. Toolchain doen't have artificial intelligence and just does what it does as it should. And in my opinion,this is bad design in R.dll, but not in the MS toolchain. Not because I'm trying to defend MS toolchain "positions" over the MINGW or any other toolchain, but just because this is what I think generally bad design - override standard library functions in the custom DLL without special need to do so. – ivan.ukr Oct 15 '15 at 12:56
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/92389/discussion-between-ivan-ukr-and-dirk-eddelbuettel). – ivan.ukr Oct 15 '15 at 13:03

1 Answers1

0

I've came up with followinf solution. Here is my script for the manual generation of import library from R.dll:

:: Read more at the http://stackoverflow.com/questions/9946322/how-to-generate-an-import-library-lib-file-from-a-dll
setlocal
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" amd64
SET MACHINE=x64
SET LIBNAME=R
dumpbin /exports %LIBNAME%.dll > %LIBNAME%.exports
echo LIBRARY R > %LIBNAME%.def
echo EXPORTS >> %LIBNAME%.def
for /f "skip=19 tokens=4" %%A in (%LIBNAME%.exports) do echo %%A >> %LIBNAME%.def
start /wait win32pad.exe %LIBNAME%.def
lib /def:%LIBNAME%.def /out:%LIBNAME%.lib /machine:%MACHINE%
endlocal

Actually, I have added this

start /wait win32pad.exe %LIBNAME%.def

before running lib.exe. This start text editor and allows me to edit DEF file manually and drop away from it all flavors of "printf" (there are multiple ones) that should actually go from native toolset's CRT version.

After linking with such adjusted import library the issue have gone.

I hope this will be useful info for the people who aim to embed R into their Windows application.

ivan.ukr
  • 2,853
  • 1
  • 23
  • 41