Re: shared libraries: namespace problem / an unmoveable object meets an irresistable force / Java bindings for PARI

[Andy Stubbs <agstubbs@liverpool.ac.uk>]

> I've been experiencing a rather intractible problem that I hope someone
> can explain. I'm surprised nobody has had this problem before (unless I'm
> being really dense): when both libpari.so and libc.so are in memory as
> shared libraries, _any_ reference to pari's err() function (including
> references made internally by libpari.so) is passed to libc's err() 
> function...

Problem solved. Sort of. It appears to be a problem with glibc2. 
Possibly. Or at least some interaction between glibc2 and libpari. I now
have a short piece of code that I can demonstrate behaves differently when
compiled against libc5 and libc6. i.e., it works with libc5... 

However, pari may still be implicated, because I've only been able to
reproduce the problem with libpari, and not any of my own mock-up shared
libs.

So I've downgraded my java distribution to one linked against libc5, and I
can now quite happily catch errors and throw a corresponding java
exception to the JVM with a vanilla libpari.so. (it took me a while to
work out that longjmp thing though!) 

Has anybody got gp/pari working on a linux/glibc2 box? The problem only
seems to manifest itself when the executable uses dlopen() to open the
library and is not itself linked against libpari at compile time... 

However, my problem's solved. At least until glibc2 becomes the
standard primary library anyway...

Thanks,

Andy