[PYTHON MATRIX-SIG] Just checking in

Jim Fulton jim.fulton@digicool.com
Thu, 29 Aug 1996 12:20:48 -0400

Guido van Rossum wrote:
> > As for HP systems, I am reasonably convinced that the problem with
> > NumPy alpha2 is the fake module "libnumpy". After a careful study of
> > the HP documentation, I conclude that there are two ways to use
> > shared libraries:
> >
> > 1) Explicit loading, which is what Python does when importing
> >    a module.
> >
> > 2) Linking with a shared library, which is then loaded as soon as
> >    one of its functions is called. This works only if the shared
> >    library is in the same place as it was during linking. (Other
> >    systems, e.g. SGI, let the user specify a search path for this
> >    case.)
> >
> > NumPy uses the second method for libnumpy (which contains
> > arrayobject.o and ofuncobject.o), but after installation it must fail.
> This makes sense after all.  Unless libNumPy.sl is placed in one of
> the standard places where the linker looks for shared libraries, it
> will need some strong hints.  It could be that this problem doesn't
> occur on Solaris because the linker will look in the same directory
> where the referring shared library is coming from.
> However, if I read the "ld" man page right for HP-UX, the "+b" option
> should let you specify a list of directories to search for shared
> libraries at run-time.  It may be that this information only gets used
> when building the main executable, in which case you can specify a
> SHLIB_PATH environment variable pointing to the directory containing
> libNumPy.sl (see the +s option).

But all of this is alot of work.  What's worse, it's work
for the user, rather than the author of a module.  The user has to 
remember to set some goofy environment variable because of some
arcane detail of how a program was built. Yuck.

> > A possible solution would be to make libnumpy a real importable
> > module and import it from the modules that need it.
> Yes, that's another approach.  The Object/cobject.c file contains a
> little-known trick to make this easier.  However I'm not sure it's
> worth it, assuming this problem is HP specific.

No, the problem occurs on DG and DEC too, but the details vary from
to system, just to make things interesting. 8-[ It's a real hassle,
which is
why I came up with the cobject type.  I'll admit, that for a large
C API, cobject could be quite a hassle.  I'd hoped to put something
for the numerics stuff, but haven't had time, and with my current job,
less motivation.

> The environment
> variable trick seems okay.  (Note that in 1.4b3 you can use
> os.putenv() to modify the real environment of the current process, so
> you could even hide this in a wrapper written in Python!)

putenv helps, but tha hack will have to be system dependent.

I think it would be much better to "import" the interface.  I'm sorry
I can't help out more.

One more point, I suspect that in many cases, it might be just as easy
to use the Python Numeric API from C.  I hope to do this for FIDL.


> =================
> MATRIX-SIG  - SIG on Matrix Math for Python
> send messages to: matrix-sig@python.org
> administrivia to: matrix-sig-request@python.org
> =================

Jim Fulton         Digital Creations
jim@digicool.com   540.371.6909
## Python is my favorite language ##
##     http://www.python.org/     ##

MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org