From mail at joeconway.com  Fri Apr  7 23:59:29 2006
From: mail at joeconway.com (Joe Conway)
Date: Fri, 07 Apr 2006 14:59:29 -0700
Subject: [Rd] Compiling PL/R against R.dll in Win32/MinGW
In-Reply-To: <4436DB0E.5040406@alumni.uwaterloo.ca>
References: <4436C162.8080106@alumni.uwaterloo.ca>	<4436C8B8.6020402@joeconway.com>
	<4436DB0E.5040406@alumni.uwaterloo.ca>
Message-ID: <4436E0C1.50005@joeconway.com>

Mike Leahy wrote:
> Ok...well I've been hacking around with the PL/R source a bit more, and
> I found that that substituting 'Rf_initEmbeddedR' with 'InitDynload'
> seemed to make code compile further - this was just a total guess based
> on the functions that are listed in the R.dll with dependency-walker.
> Now it appears that it's an issue compiling against postgres, rather
> than R.dll (see below).  Should I pursue this any further, or should I
> accept that it just won't happen and give up for now?

> 
> -DDLSUFFIX=\".dll\"  -c -o plr.o plr.c
> plr.c: In function `plr_init':
> plr.c:288: warning: implicit declaration of function `InitDynload'
> plr.c: In function `fetchArgNames':
> plr.c:1366: warning: passing arg 7 of `deconstruct_array' from

This looks like you're trying to compile with PostgreSQL cvs HEAD 
(8.2devel), correct? That won't work as I've not yet adjusted PL/R to 
handle NULL elements in arrays (which is brand new in HEAD). But this is 
is now off topic here...

Getting back on topic, unless someone can tell us that R.dll or some 
other mechanism exposes the same API as the libR shared object, I'd have 
to say it is probably hopeless.

Joe



[Rd] Compiling PL/R against R.dll in Win32/MinGW
Joe Conway