[PYTHON MATRIX-SIG] Just checking in
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,
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,
> 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: firstname.lastname@example.org
> administrivia to: email@example.com
Jim Fulton Digital Creations
## Python is my favorite language ##
## http://www.python.org/ ##
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: firstname.lastname@example.org
administrivia to: email@example.com