Mailing List Archive

On Sun, Apr 25, 1999 at 07:19:47PM +0000, kelvin_chu@my-dejanews.com wrote:
>
> Hi all;
>
> I've had great success with EZplot and now want to move my code to Linux-
> based platforms in my lab. I am having significant difficulties building
> the Graphics portion of NumPy.
>
> 0. I am running RedHat linux 5.2
> 1. I have installed Yorick in the cannonical place.
> 2. Instead of libX11.a, I have a shared-object library, locatedin
> /usr/X11R6/lib
>
> When I do the build (python makethis.py), I receive the following error:
>
> gcc -fpic -I/usr/local/lib/yorick/1.4/h -g -O2
> -I/usr/local/include/python1.5 -I/usr/local/include/python1.5
> -DHAVE_CONFIG_H -c ./Gist/Src/gistCmodule.c
> ./Gist/Src/gistCmodule.c:75: arrayobject.h: No such file or directory
> ./Gist/Src/gistCmodule.c:88: warning: `PyFPE_END_PROTECT' redefined
> /usr/local/include/python1.5/pyfpe.h:169: warning: this is the location of
> the previous definition
> make: *** [gistCmodule.o] Error 1
>
>
> I suspect that I am going to run into multiple problems. There is a cryptic
> statement in the README that indicates that I should do import_arrays() before
> doing the build...where do I implement this? How much of this problem is
> related to the shared object X libs?
>
> Thanks, I appreciate any light you can shed on this matter!
>
> Cheers,
>
> Kelvin
>

greetings,

the error you posted doesn't appear to have anything to do with libX11.. it
points to the location of (at least) this error.. the compiler is unable to
find 'arrayobject.h', which is part of the python distribution. if you
installed from rpms, did you remember to also install the 'python-devel'
package?

hope that helps.. please let us know! ;)

Regards,
J
--
|| visit gfd <http://quark.newimage.com:8080/>
|| psa member #293 <http://www.python.org/>
|| New Image Systems & Services, Inc. <http://www.newimage.com/>

On Sun, Apr 25, 1999 at 05:56:44PM -0400, Kelvin Chu wrote:
>
> Dear J;
>
> Thanks for your quick response. I didn't install RPMS, I built the
> source. Should I go back and get the RPMs instead? -k
>


greetings,

in general, I install rpms when I can find them from 'trusted' sources
(check <http://andrich.net/python/> for latest python rpms).. they have
already been compiled, and generally whatever headaches required to fix
compilation problems have already been ironed out.. go for it.. it can't
hurt.. if it *still* doesn't work, then let me know, and we can work from
there... also, before you install the rpms, I would suggest removing old
versions of the interpreter that may have been installed in /usr/local/...
it "shouldn't" hurt anything to leave them around, but just to be on the
safe side, that's what I would do.

let me know if that helps.

regards,
J
--
|| visit gfd <http://quark.newimage.com:8080/>
|| psa member #293 <http://www.python.org/>
|| New Image Systems & Services, Inc. <http://www.newimage.com/>

Glad to hear that you are using NumPy on Linux.

I've been putting together the RPM's for NumPy and would definitely
suggest you go that route initially. If you want to compile the packages
yourself you can get the source RPM for Numpy from andrich.net or from my
site at http://oliphant.netpedia.net and it will build 3 binary packages:
NumPy, Gist (EzPlot), and RNG (random number generators). The packages
come with quite a bit of documentation (all I could find).

Installing a source RPM and then compiling amounts to:

rpm -i package-name.src.rpm
rpm -ba /usr/src/redhat/SPECS/package.spec

This will build a binary package compiled on your system and place it in
/usr/src/redhat/RPMS/i386

You can then install it like any other package.

I would highly encourage learning to build from RPM sources. Grabbing a
spec file is usually all you need to start building any package you want.
If you stick with Oliver's RPM's you should be fine. I've had trouble in
the past however with compiling my own RPM's (using gcc) and trying to
import them into a python interpreter installed from Oliver's RPMS
(compiled with pgcc). I get strange segfaults. I haven't tried for
awhile so I don't know if the problem is still there but you might keep
that in mind if you are mixing and matching compilers for different python
packages.

After that bit of rambling... The problem you are having is due to the
fact that the gist module now looks for the arrayobject.h file in
numerical/arrayobject.h which is not where your arrayobject.h header file
likely is. So, change that #include line in the C-code and it should
work. I had to do this to get the RPM's to work.

Best,

Travis

kelvin_chu@my-dejanews.com wrote:
: Hi all;

Hi, Kelvin.

: I've had great success with EZplot and now want to move my code to Linux-
: based platforms in my lab. I am having significant difficulties building
: the Graphics portion of NumPy.

: 0. I am running RedHat linux 5.2
: 1. I have installed Yorick in the cannonical place.
: 2. Instead of libX11.a, I have a shared-object library, locatedin
: /usr/X11R6/lib

: When I do the build (python makethis.py), I receive the following error:

: gcc -fpic -I/usr/local/lib/yorick/1.4/h -g -O2
: -I/usr/local/include/python1.5 -I/usr/local/include/python1.5
: -DHAVE_CONFIG_H -c ./Gist/Src/gistCmodule.c
: ./Gist/Src/gistCmodule.c:75: arrayobject.h: No such file or directory
: ./Gist/Src/gistCmodule.c:88: warning: `PyFPE_END_PROTECT' redefined
: /usr/local/include/python1.5/pyfpe.h:169: warning: this is the location of
: the previous definition
: make: *** [gistCmodule.o] Error 1

This is a matter of gcc not finding arrayobject.h which is in
../Numerical/Include/

To uglily bypass this, try *after the failure* to do a

make CC='gcc -I../Numerical/Include/'

in the LLNL/Graphics/ directory

This should override the CC variable of the Makefile written by makethis.py,
so the make-generated command does find the .h

: I suspect that I am going to run into multiple problems. There is a cryptic
: statement in the README that indicates that I should do import_arrays() before
: doing the build...where do I implement this? How much of this problem is
: related to the shared object X libs?

Up to now, unrelated. Look for trouble of the same kind in linking the final .so.
IIRC, the only problem I had compiling this myself was the broken include.

: Kelvin

HTH, Daniel.