[Rd] modules with libtool and -dlpreopen
Kurt Hornik
Kurt.Hornik at wu-wien.ac.at
Sun Feb 6 15:29:51 CET 2005
>>>>> Marcus G Daniels writes:
> Prof Brian Ripley wrote:
>> Some of them use Fortran, please note, and libtool is none too good at
>> that.
> I didn't have an (obvious) problem with that. I did notice that
> DYLIB_* variables in Makeconf.in didn't have USE_LIBTOOL_TRUE/FALSE
> conditionalizations. That was a place it broke for me with Fortran
> code in modules. Was it a compile-time problem or a run-time problem
> you saw?
> Also I noticed compilation invocations weren't set up in R 2.0.1 to
> prepend "libtool --mode=compile". When I inserted those for C and
> Fortran, reactivated the linkage code for libtool that was already
> there, and then went through each module and made *.lo the dependency
> instead of *.o, and made *.la the target instead of *.so, I managed to
> get (.la) modules installed in the build tree under
> /build/R/library/{tools,grid,methods,splines,stats,tools).
Marcus,
This is very interesting.
As you can tell from the current code base, we attempted to move to
using libtool for building dynamic objects quite some time ago, and
found that all libtool could handle then was C (no FORTRAN, no C++). I
have not returned to this yet, as evidenced by the following in
configure.ac:
## <FIXME>
## Completely disable using libtool for building shlibs until libtool
## fully supports Fortran and C++.
## AC_ARG_WITH([libtool],
## [AC_HELP_STRING([--with-libtool],
## [use libtool for building shared libraries @<:@yes@:>@])],
## [use_libtool="${withval}"],
## [use_libtool=yes])
## </FIXME>
The fact the the dylib rules are unconditionalized is because they were
added way after the failed initial attempts.
I think Brian has meanwhile tried to build the R "shared library" using
libtool, and was not amused.
Is there a systematic set of patches you could make available?
Ideally, we'd have a configure option for maybe using libtool, and the
patches would be conditional on that ...
(Not that I can promised to deal with this anytime soon ...)
Best
-k
> Next I went to the src/unix directory and removed the object code, and
> rebuilt using:
> make CPPFLAGS='-Ddlsym=lt_dlsym -Ddlopen=lt_dlopen -Ddlclose=lt_dlclose'
> After that I went back to the src/main directory and first edited
> Rmain.c to add an include of ltdl.h , a call to
> LTDL_SET_PRELOADED_SYMBOLS() and a call to "lt_dlinit ()" before
> "Rf_initialize_R (ac, av)".
> Then I modified the linkage of R.bin to add this at the start of the
> command:
> -dlpreopen /build/R/library/tools/libs/tools.la -dlpreopen
> /build/R/library/stats/libs/stats.la -dlpreopen
> /build/R/library/methods/libs/methods.la -dlpreopen
> /build/R/library/grid/libs/grid.la -dlpreopen
> /build/R/library/stats/libs/splines.la
> and:
> -lltdl
> at the end of the link (the libtool dlopen compatibility interface).
> Following that I just went to the top of the build tree of R and let the
> build finish.
> As you can see, no calls to dlsym get made:
> $ R_HOME=/build/R gdb ./R.bin -q
> Using host libthread_db library "/lib/tls/libthread_db.so.1".
> (gdb) break main
> Breakpoint 1 at 0x8060c52: file /src/R-2.0.1/src/main/Rmain.c, line 32.
> (gdb) run -q
> Starting program: /build/R/src/main/R.bin -q
> Breakpoint 1, main (ac=2, av=0xfefbce44) at /src/R-2.0.1/src/main/Rmain.c:32
> 32 {
> (gdb) break dlsym
> Breakpoint 2 at 0xf6fa3de6
> (gdb) c
> Continuing.
> Detaching after fork from child process 6376.
>>
> Compare this to a default build of R on Linux that would have them:
> $ R -d 'gdb -q' -q
> (no debugging symbols found)...Using host libthread_db library
> "/lib/tls/libthread_db.so.1".
> (gdb) break main
> Breakpoint 1 at 0x805ceb6
> (gdb) run -q
> Starting program: /usr/lib/R/bin/exec/R -q
> (no debugging symbols found)...(no debugging symbols found)...
> Breakpoint 1, 0x0805ceb6 in main ()
> (gdb) break dlsym
> Breakpoint 2 at 0xf6f55de6
> (gdb) c
> Continuing.
> Breakpoint 2, 0xf6f55de6 in dlsym () from /lib/libdl.so.2
> (gdb)
> ______________________________________________
> R-devel at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
More information about the R-devel
mailing list