Skip to content

modules with libtool and -dlpreopen

5 messages · Brian Ripley, Marcus G. Daniels, Kurt Hornik

Original
Marcus G. Daniels
# 
Has anyone looked at setting up R to build its modules with libtool's 
dlpreopen?

[libtool -dlpreopen is a facility that allows one to simulate dynamic 
linking on platforms that lack it.  However, it requires collecting all 
of the component `shared' objects into one and linking them (and a 
metadata structure) into a single executable.]

Thanks.
Brian Ripley
# 
Yes.
Some of them use Fortran, please note, and libtool is none too good at that.

Not sure why this merited sending twice ....
On Wed, 2 Feb 2005, Marcus G. Daniels wrote:

            

      
      
      
    

        
No current R platform does.

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Marcus G. Daniels
    

    

      
      #
    

  


  

      
Prof Brian Ripley wrote:

        

            

      
      
      
    

        
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).  

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)

  
  


  


      

    

    

      
      

        


  

        

      Marcus G. Daniels
    

    

      
      #
    

  


  

      
Prof Brian Ripley wrote:

        

            

      
      
      
    

        
The static linking workarounds are for a Cray MTA/2, a multithreaded 
supercomputer.   Although having a rather primitive runtime environment 
(e.g. no dynamic linker), it does have an advanced parallelizing 
compiler.   (The practical usage is kind of fly-by-wire setup using a 
front-end workstation.)  The MTA/2 is fast architecture for 
memory-intensive applications.

  
  


  


      

    

    
3 days later

    

      
      

        


  

        

      Kurt Hornik
    

    

      
      #
    

  


  

          

      
      
      
    

        
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