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

From: Tobias Verbeke <>
Date: Wed, 08 Aug 2007 21:24:19 +0200

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

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

all: $(XFILE) copyop

        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)

        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("./", 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 "", and dlopen'ing
>> "$R_HOME/library/<package>/inst/" instead.

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

(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 Verbeke - Consultant
Business & Decision Benelux
Rue de la révolution 8
1000 Brussels - BELGIUM

+32 499 36 33 15

______________________________________________ mailing list
Received on Thu 09 Aug 2007 - 07:12:16 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Fri 10 Aug 2007 - 07:38:52 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.