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
[EMAIL PROTECTED]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
