Dynamically loading shared objects compiled from Fortran may fail with an undefined symbol message. The symbol string returned by dlerror is garbage and this sometimes leads to a segmentation fault. This problem has been reported on the mailing lists of the R language (http://www.r-project.org). R has a facility for users to create dynamically loaded "packages" to extend the functionality of the language. Many of these packages contain Fortran code. The problem is specific to Red Hat 6.2 and has not been reproduced on other platforms. It only occurs with packages that contain Fortran code. Here is an example, which is reproducible. You can download an RPM of R from http://www.r-project.org/bin/linux/redhat/6.x/i386/R-base-1.1.0-2.i386.rpm The source for the tseries package can be downloaded from http://www.r-project.org/src/contrib/tseries_0.5-2.tar.gz To install the tseries package, type (as root) R CMD INSTALL tseries_0.5-2.tar.gz The launch R within gdb by typing "R -d gdb" and at the R prompt type "library(tseries)" to load the tseries package Here is a stack trace: $ R -d gdb ... (gdb) set args --vanilla (gdb) r Starting program: /usr/lib/R/bin/R.bin --vanilla ... > library(tseries) Program received signal SIGSEGV, Segmentation fault. _dl_lookup_symbol (undef_name=0x81f52f60 <Address 0x81f52f60 out of bounds>, ref=0xbfffaae0, symbol_scope=0x81edab4, reference_name=0x81ea018 "/home/martyn/Rlibs/tseries/libs/tseries.so", reloc_type=18) at ../sysdeps/generic/dl-hash.h:31 31 ../sysdeps/generic/dl-hash.h: No such file or directory. (gdb) bt #0 _dl_lookup_symbol ( undef_name=0x81f52f60 <Address 0x81f52f60 out of bounds>, ref=0xbfffaae0, symbol_scope=0x81edab4, reference_name=0x81ea018 "/home/martyn/Rlibs/tseries/libs/tseries.so", reloc_type=18) at ../sysdeps/generic/dl-hash.h:31 #1 0x400096ad in _dl_relocate_object (l=0x81ed8b0, scope=0x81edab4, lazy=0, consider_profiling=0) at ../sysdeps/i386/dl-machine.h:326 #2 0x40191be4 in dl_open_worker (a=0xbfffac4c) at dl-open.c:182 #3 0x4000ac3b in _dl_catch_error (errstring=0xbfffac48, operate=0x40191990 <dl_open_worker>, args=0xbfffac4c) at dl-error.c:141 #4 0x40191d3d in _dl_open ( file=0xbfffbdec "/home/martyn/Rlibs/tseries/libs/tseries.so", mode=2, caller=0xbfffac48) at dl-open.c:232 #5 0x400503d3 in dlopen_doit (a=0xbfffad5c) at dlopen.c:41 #6 0x4000ac3b in _dl_catch_error (errstring=0x40052080, operate=0x400503a8 <dlopen_doit>, args=0xbfffad5c) at dl-error.c:141 #7 0x400508b9 in _dlerror_run (operate=0x400503a8 <dlopen_doit>, args=0xbfffad5c) at dlerror.c:125 #8 0x40050393 in __dlopen_check ( file=0xbfffbdec "/home/martyn/Rlibs/tseries/libs/tseries.so", mode=2) at dlopen.c:53 #9 0x80e4b3a in AddDLL ( path=0xbfffbdec "/home/martyn/Rlibs/tseries/libs/tseries.so", asLocal=1, now=1) at dynload.c:207
This bug also happens when loading dynamic modules into ROOT system (see http://root.cern.ch/). If we compile an link a dynamic FORTRAN module with a RedHat 6.0 system, the resulting bynary could be dynamically loaded into ROOT on a RH6.2 system. But if we link the module on RH6.2 it will fail. Note that probably the linking process of the dynamic module is the problem point, as module compile under RH6.0 but linked on RH6.2 fails, but a module compiled under RH6.2 but linked under RH6.0 works! Please increase the priority of this bug, as we urgently need this functionality in RH 6.2
We did further investigation in this case. A downgrade to binutils-2.9.1.0.23-6.i386 from Redhat-6.1 did solve our problem. So the problem is related to binutils. We also tried the following versions of binutils: binutils-2.9.5.0.22-6.i386 built from RH 6.2 ssrc.rpm without the ldsymver path, which fails too. Also binutils-2.10.1 from gnu.org fails. So there must be some change between 2.9.1.0.23 and 2.9.5.0.22 which triggers the problem. We can work around now with the downgraded binutils, but as we do not know which others side effects we will encounter, as well as we are afraid that this bug will hit us again with RH-7.x please consider fixing it properly. Sincerly, Klaus Steinberger
If you can see the problem with contemporary gcc/binutils, please reopen.