1.5.2 broke IRIX module loading

[Andrew Dalke]

Randall Hopper <aa8vb at vislab.epa.gov> said:
>  I built and tried 1.5.2 this morning, and it failed to load a module
> that worked fine on 1.5.1. 

  We had the same problem on our SGIs.  In our case, our vendors
accidentally shipped .a files with functions which reference other
functions of theirs which they didn't ship.

  We used SWIG to create a .so files from the .a, and with the
removal of RTLD_GLOBAL, this means we can no longer import our
module with 1.5.2 .

  This change was discuessed on the newsgroup some months back (sorry,
don't have a DejaNews reference handy) and the outcome was that
libraries shipped in this form are broken, and it must be done this
way so different shared libraries don't get namespace collisions.

  For us there were two ways around it:
 1) upgrade to our vendor's newest libraries
 2) create dummmy C functions which resolve the functions

> "currstep" is the internal FORTRAN routine which has been zeroed-out.

  But I don't know what zeroed-out means in this context.  For me
I found which were missing with "nm library.so | grep UNDEFINED"


  I mentioned this problem to Guido when I tested 1.5.2c1 on our
SGIs; not that it had to be changed back but that people were going
to find this change unexpected.  Here are his comments:

Guido said:
| Unfortunately the conclusion of the debate about this was unanimously
| that using RTLD_GLOBAL is evil; even though it solves some real
| practical problems in some cases (like yours), it can break other
| things for which the only fix is to remove RTLD_GLOBAL.  The cases
| where it is needed are always caused by bad programming (e.g. your
| vendor's).  Sorry.
|
| [....]
|
| > And, if not, I'll just put "| RTLD_GLOBAL" into my dlopen.
| 
| That would be the easiest solution for you, as long as you don't run
| into the other problem (conflicting externals defined in two
| libraries).

						Andrew Dalke
						dalke at bioreason.com