From tobias.verbeke at telenet.be  Wed Aug  8 21:24:19 2007
From: tobias.verbeke at telenet.be (Tobias Verbeke)
Date: Wed, 08 Aug 2007 21:24:19 +0200
Subject: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS
	in	R	package
In-Reply-To: <46B96EE6.2090606@statistik.uni-dortmund.de>
References: <W906017980119021186410641@nocme1bl6.telenet-ops.be>	<Pine.LNX.4.64.0708062029410.27542@gannet.stats.ox.ac.uk>	<46B7B87C.1070808@cimr.cam.ac.uk>	<Pine.LNX.4.64.0708070340290.31210@gannet.stats.ox.ac.uk>	<46B8D6AD.9040707@cimr.cam.ac.uk>
	<46B96EE6.2090606@statistik.uni-dortmund.de>
Message-ID: <46BA1863.6030609@telenet.be>

Thank you very much for your input.

In the meantime I was -- thanks to
the pointer to the Rserve Makefile
by Professor Ripley -- able to have
a Makefile that built the package
correctly:

SFILE = ../inst/OpenBUGS/linbugs.c
XFILE = ../inst/OpenBUGS/linbugs
SOFILE = ../src/linbugs.so

all: $(XFILE) copyop

$(XFILE): $(SFILE)
	gcc -m32 -o $(XFILE) $(SFILE) -ldl

copyop:	$(XFILE)
# Only *.so get copied. Therefore we need to fake the bin files as 
".so"s to get
# copied. Not a nice hack, but it works... (Comment from Rserve)
	cp $(XFILE) $(SOFILE)
clean:
	rm -f *.so *~ $(XFILE)
.PHONY: copyop clean

(Note that I changed the naming of the C source and compiled
file following a complaint by the package checker that observed
that the OpenBUGS distribution has a directory Bugs which on
case-insensitive systems could be confused with bugs, the previous
name of the executable)

Uwe Ligges wrote:
> Hin-Tak Leung wrote:
>> Prof Brian Ripley wrote:
>>> OpenBUGS is distributed under GPL2, so this seems not to apply.
>>> It is distributed as source and as binaries: the difficulty is that it 
>>> is written in Object Pascal for which a compiler is not readily available.
>> Argh, I just thought of a proper technical reason, and I think I have 
>> spotted a possible bug in the original poster's code! Some choose to do
>> dlopen() when the DLL/so is in a non-standard/non-system location, as an
>> alternative to setting LD_LIBRARY_PATH explicitly or other link-loader
>> magics.
>>
>> The line:
>>     handle = dlopen("./brugs.so", RTLD_LAZY);
>>
>> Seems to suggest this, However, the problem with this code, is that
>> the current directory  (./) may not be where the user thinks it is.
>> I think the user meant to prepend $R_HOME/library/<package>/inst/ 
>> somehow to "brugs.so", and dlopen'ing 
>> "$R_HOME/library/<package>/inst/brugs.so" instead.

This should be "$R_HOME/library/<package>/OpenBUGS/brugs.so"

(without the inst level that is taken out when installing the package)

> No, it's fine if the executable is started in the same directory, and 
> that can be assured by the calling R code. Otherwise it will only work 
> if you have the package in the main library of R.
> Anyway, it is still highly preferable to just load the Bugs lib into R, 
> if we only could compile the stuff...

Actually, I think Hin-Tak is right about the absolute path. Even when 
the R code will call the executable that resides in that directory, R 
will call it from any directory and that (current) directory will be 
resolved (at least that is what I observe experimentally).

When such an absolute path is coded in, everything runs fine -- we now 
can run a BUGS script from within R under GNU/Linux !

It would however be nice to solve the remaining problem of the
absolute path in the dlopen() call, i.e. being able to fill in
`dynamically' the library path to which the package is actually installed.

Is there a way to have the library path to which a package is installed 
available during package installation and then to do some 
text-processing to fill in this path dynamically into the C file i.e.
as argument of dlopen() before compiling it?

Thanks again,
Tobias

-- 

Tobias Verbeke - Consultant
Business & Decision Benelux
Rue de la r?volution 8
1000 Brussels - BELGIUM

+32 499 36 33 15
tobias.verbeke at businessdecision.com



[Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Tobias Verbeke