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

[Tobias Verbeke]

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