visualpython-users

[Visualpython-users] Still no progress with the Beta version of visual python

[David H. <dha...@ta...>]

At Bruce's suggestion, I downloaded visual-4.beta15
and tried installing it on my AMD 64-bit machine
running RedHat Enterprise 4.  It uses numpy and
that is good.  But it now has a very major dependency
on GTK and its libraries.  I spent about 4 hours today
compiling an ever increasing number of dependent
libraries to try to get things going.  Just for grins,
take a look at what libraries are needed:

4 atk-1.19.3/     
4 gtk+-2.10.13/     
4 libsigc++-1.2.7/  
4 cairo-1.4.8/    
4 gtkglext-1.2.0/   
4 libsigc++-2.0.17/
4 cairomm-1.2.4/  
4 gtkglextmm-1.2.0/   
4 gtkmm-2.10.10/    
4 numpy-1.0.3/     
4 glib-2.12.9/    
4 gtkmm-2.2.12/     
4 pango-1.17.3/     
4 visual-4.beta15/
4 glibmm-2.12.10/ 
4 libglademm-2.4.2/ 
4 Python-2.5.1/

Many of these are tricky to install because they are either
not very friendly to 64-bit or to installs in non-standard
locations.  After a fair bit of hacking, I managed to get
all of these installed (watch out for gtkglextmm -- it has some
sort of wild problem attempting to link against libGL -- libtool
for it had to be seriously hacked).

After everything was installed, visual-4.beta15 finally stopped
complaining about dependent libraries and compiled.  But
it looks like it has a problem:

steiner.visual-4.beta15: make
Making all in site-packages/visual
make[1]: Entering directory 
`/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/site-packages/visual'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory 
`/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/site-packages/visual'
Making all in src
make[1]: Entering directory 
`/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/src'
This is a quiet Makefile. If make exits with an error, check 
src/build.log to see the complete error message(s). In the event of an 
error that you cannot debug, please send a message to 
vis...@li..., including the files config.log 
and src/build.log, requesting assistance.
Compiling ./core/arrow.cpp ...
Compiling ./core/axial.cpp ...
Compiling ./core/box.cpp ...
Compiling ./core/cone.cpp ...
Compiling ./core/cylinder.cpp ...
Compiling ./core/display_kernel.cpp ...
Compiling ./core/ellipsoid.cpp ...
Compiling ./core/frame.cpp ...
Compiling ./core/label.cpp ...
Compiling ./core/mouseobject.cpp ...
Compiling ./core/primitive.cpp ...
Compiling ./core/pyramid.cpp ...
Compiling ./core/rectangular.cpp ...
Compiling ./core/renderable.cpp ...
Compiling ./core/ring.cpp ...
Compiling ./core/sphere.cpp ...
Compiling ./python/convex.cpp ...
Compiling ./python/curve.cpp ...
Compiling ./python/cvisualmodule.cpp ...
Compiling ./python/faces.cpp ...
Compiling ./python/num_util.cpp ...
make[1]: *** [num_util.lo] Error 1
make[1]: Leaving directory 
`/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/src'
make: *** [all-recursive] Error 1

I looked at the build log and here is what it says:

 g++ -I/home/dharrison/wares/rhe4_a64/include/python2.5 
-I/home/dharrison/wares/rhe4_a64/lib/python2.5/site-packages/numpy/core/include 
-DHAVE_CONFIG_H -I../include -I../include 
-I/home/dharrison/wares/rhe4_a64/include/gtkglextmm-1.2 
-I/home/dharrison/wares/rhe4_a64/lib/gtkglextmm-1.2/include 
-I/home/dharrison/wares/rhe4_a64/include/gtkglext-1.0 
-I/home/dharrison/wares/rhe4_a64/include/gtkmm-2.4 
-I/home/dharrison/wares/rhe4_a64/lib/gtkmm-2.4/include 
-I/home/dharrison/wares/rhe4_a64/lib/gtkglext-1.0/include 
-I/usr/X11R6/include -I/home/dharrison/wares/rhe4_a64/include/gdkmm-2.4 
-I/home/dharrison/wares/rhe4_a64/lib/gdkmm-2.4/include 
-I/home/dharrison/wares/rhe4_a64/include/pangomm-1.4 
-I/home/dharrison/wares/rhe4_a64/include/gtk-2.0 
-I/home/dharrison/wares/rhe4_a64/lib/gtk-2.0/include 
-I/home/dharrison/wares/rhe4_a64/include/pango-1.0 
-I/home/dharrison/wares/rhe4_a64/include/glib-2.0 
-I/home/dharrison/wares/rhe4_a64/lib/glib-2.0/include 
-I/home/dharrison/wares/rhe4_a64/include/cairo 
-I/home/dharrison/wares/rhe4_a64/include/glibmm-2.4 
-I/home/dharrison/wares/rhe4_a64/lib/glibmm-2.4/include 
-I/home/dharrison/wares/rhe4_a64/include/cairomm-1.0 
-I/home/dharrison/wares/rhe4_a64/include/sigc++-2.0 
-I/home/dharrison/wares/rhe4_a64/lib/sigc++-2.0/include 
-I/home/dharrison/wares/rhe4_a64/include/atk-1.0 
-I/home/dharrison/wares/rhe4_a64/include/atkmm-1.6 
-I/usr/include/freetype2 
-I/home/dharrison/wares/rhe4_a64/include/libglademm-2.4 
-I/home/dharrison/wares/rhe4_a64/lib/libglademm-2.4/include 
-I/usr/include/libpng12 -I/usr/include/libglade-2.0 
-I/usr/include/libxml2 -I../include/gtk2 -pthread 
-I/home/dharrison/wares/rhe4_a64/include/glib-2.0 
-I/home/dharrison/wares/rhe4_a64/lib/glib-2.0/include 
-I/home/dharrison/wares/rhe4_a64/include/python2.5 
-I/home/dharrison/wares/rhe4_a64/lib/python2.5/site-packages/numpy/core/include 
-fpic -DPIC -g -O2 -ftemplate-depth-120 -MMD -MF num_util.d -MT 
"num_util.d num_util.lo" -c ./python/num_util.cpp  -fPIC -DPIC -o 
.libs/num_util.o
./python/num_util.cpp: In function `std::vector<npy_intp, 
std::allocator<npy_intp> > 
cvisual::python::shape(boost::python::numeric::array)':
./python/num_util.cpp:234: error: cannot convert `npy_intp*' to `int*' 
in initialization

I will take a look see and see if this is something that can be fixed. 
Has anyone else
managed to get the beta to compile from ground zero on 64-bit linux?  So 
far,
I think I have spent about 1.5 days just on the installation.  I hope
this is not typical.

       David

Re: [Visualpython-users] Still no progress with the Beta version of visual python

[Bruce S. <Bru...@nc...>]

Alas, I have no experience with nor access to a 64-bit environment, and 
it does sound like that's the issue. I'm surprised that there aren't 
standard 64-bit packages for GTK, which after all is a pretty standard 
library. Is there anyone reading this list with 64-bit experience?

Bruce Sherwood

David Harrison wrote:
> At Bruce's suggestion, I downloaded visual-4.beta15
> and tried installing it on my AMD 64-bit machine
> running RedHat Enterprise 4.  It uses numpy and
> that is good.  But it now has a very major dependency
> on GTK and its libraries.  I spent about 4 hours today
> compiling an ever increasing number of dependent
> libraries to try to get things going.  Just for grins,
> take a look at what libraries are needed:
> 
> 4 atk-1.19.3/     
> 4 gtk+-2.10.13/     
> 4 libsigc++-1.2.7/  
> 4 cairo-1.4.8/    
> 4 gtkglext-1.2.0/   
> 4 libsigc++-2.0.17/
> 4 cairomm-1.2.4/  
> 4 gtkglextmm-1.2.0/   
> 4 gtkmm-2.10.10/    
> 4 numpy-1.0.3/     
> 4 glib-2.12.9/    
> 4 gtkmm-2.2.12/     
> 4 pango-1.17.3/     
> 4 visual-4.beta15/
> 4 glibmm-2.12.10/ 
> 4 libglademm-2.4.2/ 
> 4 Python-2.5.1/
> 
> Many of these are tricky to install because they are either
> not very friendly to 64-bit or to installs in non-standard
> locations.  After a fair bit of hacking, I managed to get
> all of these installed (watch out for gtkglextmm -- it has some
> sort of wild problem attempting to link against libGL -- libtool
> for it had to be seriously hacked).
> 
> After everything was installed, visual-4.beta15 finally stopped
> complaining about dependent libraries and compiled.  But
> it looks like it has a problem:
> 
> steiner.visual-4.beta15: make
> Making all in site-packages/visual
> make[1]: Entering directory 
> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/site-packages/visual'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory 
> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/site-packages/visual'
> Making all in src
> make[1]: Entering directory 
> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/src'
> This is a quiet Makefile. If make exits with an error, check 
> src/build.log to see the complete error message(s). In the event of an 
> error that you cannot debug, please send a message to 
> vis...@li..., including the files config.log 
> and src/build.log, requesting assistance.
> Compiling ./core/arrow.cpp ...
> Compiling ./core/axial.cpp ...
> Compiling ./core/box.cpp ...
> Compiling ./core/cone.cpp ...
> Compiling ./core/cylinder.cpp ...
> Compiling ./core/display_kernel.cpp ...
> Compiling ./core/ellipsoid.cpp ...
> Compiling ./core/frame.cpp ...
> Compiling ./core/label.cpp ...
> Compiling ./core/mouseobject.cpp ...
> Compiling ./core/primitive.cpp ...
> Compiling ./core/pyramid.cpp ...
> Compiling ./core/rectangular.cpp ...
> Compiling ./core/renderable.cpp ...
> Compiling ./core/ring.cpp ...
> Compiling ./core/sphere.cpp ...
> Compiling ./python/convex.cpp ...
> Compiling ./python/curve.cpp ...
> Compiling ./python/cvisualmodule.cpp ...
> Compiling ./python/faces.cpp ...
> Compiling ./python/num_util.cpp ...
> make[1]: *** [num_util.lo] Error 1
> make[1]: Leaving directory 
> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/src'
> make: *** [all-recursive] Error 1
> 
> I looked at the build log and here is what it says:
> 
>  g++ -I/home/dharrison/wares/rhe4_a64/include/python2.5 
> -I/home/dharrison/wares/rhe4_a64/lib/python2.5/site-packages/numpy/core/include 
> -DHAVE_CONFIG_H -I../include -I../include 
> -I/home/dharrison/wares/rhe4_a64/include/gtkglextmm-1.2 
> -I/home/dharrison/wares/rhe4_a64/lib/gtkglextmm-1.2/include 
> -I/home/dharrison/wares/rhe4_a64/include/gtkglext-1.0 
> -I/home/dharrison/wares/rhe4_a64/include/gtkmm-2.4 
> -I/home/dharrison/wares/rhe4_a64/lib/gtkmm-2.4/include 
> -I/home/dharrison/wares/rhe4_a64/lib/gtkglext-1.0/include 
> -I/usr/X11R6/include -I/home/dharrison/wares/rhe4_a64/include/gdkmm-2.4 
> -I/home/dharrison/wares/rhe4_a64/lib/gdkmm-2.4/include 
> -I/home/dharrison/wares/rhe4_a64/include/pangomm-1.4 
> -I/home/dharrison/wares/rhe4_a64/include/gtk-2.0 
> -I/home/dharrison/wares/rhe4_a64/lib/gtk-2.0/include 
> -I/home/dharrison/wares/rhe4_a64/include/pango-1.0 
> -I/home/dharrison/wares/rhe4_a64/include/glib-2.0 
> -I/home/dharrison/wares/rhe4_a64/lib/glib-2.0/include 
> -I/home/dharrison/wares/rhe4_a64/include/cairo 
> -I/home/dharrison/wares/rhe4_a64/include/glibmm-2.4 
> -I/home/dharrison/wares/rhe4_a64/lib/glibmm-2.4/include 
> -I/home/dharrison/wares/rhe4_a64/include/cairomm-1.0 
> -I/home/dharrison/wares/rhe4_a64/include/sigc++-2.0 
> -I/home/dharrison/wares/rhe4_a64/lib/sigc++-2.0/include 
> -I/home/dharrison/wares/rhe4_a64/include/atk-1.0 
> -I/home/dharrison/wares/rhe4_a64/include/atkmm-1.6 
> -I/usr/include/freetype2 
> -I/home/dharrison/wares/rhe4_a64/include/libglademm-2.4 
> -I/home/dharrison/wares/rhe4_a64/lib/libglademm-2.4/include 
> -I/usr/include/libpng12 -I/usr/include/libglade-2.0 
> -I/usr/include/libxml2 -I../include/gtk2 -pthread 
> -I/home/dharrison/wares/rhe4_a64/include/glib-2.0 
> -I/home/dharrison/wares/rhe4_a64/lib/glib-2.0/include 
> -I/home/dharrison/wares/rhe4_a64/include/python2.5 
> -I/home/dharrison/wares/rhe4_a64/lib/python2.5/site-packages/numpy/core/include 
> -fpic -DPIC -g -O2 -ftemplate-depth-120 -MMD -MF num_util.d -MT 
> "num_util.d num_util.lo" -c ./python/num_util.cpp  -fPIC -DPIC -o 
> .libs/num_util.o
> ./python/num_util.cpp: In function `std::vector<npy_intp, 
> std::allocator<npy_intp> > 
> cvisual::python::shape(boost::python::numeric::array)':
> ./python/num_util.cpp:234: error: cannot convert `npy_intp*' to `int*' 
> in initialization
> 
> I will take a look see and see if this is something that can be fixed. 
> Has anyone else
> managed to get the beta to compile from ground zero on 64-bit linux?  So 
> far,
> I think I have spent about 1.5 days just on the installation.  I hope
> this is not typical.
> 
>        David
> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Still no progress with the Beta version of visual python

[David H. <dha...@ta...>]

I got past the problem in num_util.cpp: it looks like a simple typo.
Line 234 in that file should read:

  npy_intp* dims_ptr = PyArray_DIMS(arr.ptr());

I then found that visual inherits the linking problem from
gtkglextmm-1.2.0.  It tries to link against libGL twice: once
in the right place /usr/lib64/libGL.so and once in the wrong
place: /usr/lib/libGL.so.  A hack to its generated libtool
script gets around that problem.

But then it finally threw me a very significant curve:

/usr/bin/ld: 
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/libboost_python.a(numeric.o): 
relocation R_X86_64_32 against `a local symbol' can not be used when 
making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/libboost_python.a: 
could not read symbols: Bad value

It appears it is trying to link against a non-shared version of 
libboost_python.
I will try to hack around this one too (there appears to be a .so for
libboost_python) but I think I am going to have to edit the final link line.

       David

Bruce Sherwood wrote:
> Alas, I have no experience with nor access to a 64-bit environment, 
> and it does sound like that's the issue. I'm surprised that there 
> aren't standard 64-bit packages for GTK, which after all is a pretty 
> standard library. Is there anyone reading this list with 64-bit 
> experience?
>
> Bruce Sherwood
>
> David Harrison wrote:
>> At Bruce's suggestion, I downloaded visual-4.beta15
>> and tried installing it on my AMD 64-bit machine
>> running RedHat Enterprise 4.  It uses numpy and
>> that is good.  But it now has a very major dependency
>> on GTK and its libraries.  I spent about 4 hours today
>> compiling an ever increasing number of dependent
>> libraries to try to get things going.  Just for grins,
>> take a look at what libraries are needed:
>>
>> 4 atk-1.19.3/     4 gtk+-2.10.13/     4 libsigc++-1.2.7/  4 
>> cairo-1.4.8/    4 gtkglext-1.2.0/   4 libsigc++-2.0.17/
>> 4 cairomm-1.2.4/  4 gtkglextmm-1.2.0/   4 gtkmm-2.10.10/    4 
>> numpy-1.0.3/     4 glib-2.12.9/    4 gtkmm-2.2.12/     4 
>> pango-1.17.3/     4 visual-4.beta15/
>> 4 glibmm-2.12.10/ 4 libglademm-2.4.2/ 4 Python-2.5.1/
>>
>> Many of these are tricky to install because they are either
>> not very friendly to 64-bit or to installs in non-standard
>> locations.  After a fair bit of hacking, I managed to get
>> all of these installed (watch out for gtkglextmm -- it has some
>> sort of wild problem attempting to link against libGL -- libtool
>> for it had to be seriously hacked).
>>
>> After everything was installed, visual-4.beta15 finally stopped
>> complaining about dependent libraries and compiled.  But
>> it looks like it has a problem:
>>
>> steiner.visual-4.beta15: make
>> Making all in site-packages/visual
>> make[1]: Entering directory 
>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/site-packages/visual' 
>>
>> make[1]: Nothing to be done for `all'.
>> make[1]: Leaving directory 
>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/site-packages/visual' 
>>
>> Making all in src
>> make[1]: Entering directory 
>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/src'
>> This is a quiet Makefile. If make exits with an error, check 
>> src/build.log to see the complete error message(s). In the event of 
>> an error that you cannot debug, please send a message to 
>> vis...@li..., including the files 
>> config.log and src/build.log, requesting assistance.
>> Compiling ./core/arrow.cpp ...
>> Compiling ./core/axial.cpp ...
>> Compiling ./core/box.cpp ...
>> Compiling ./core/cone.cpp ...
>> Compiling ./core/cylinder.cpp ...
>> Compiling ./core/display_kernel.cpp ...
>> Compiling ./core/ellipsoid.cpp ...
>> Compiling ./core/frame.cpp ...
>> Compiling ./core/label.cpp ...
>> Compiling ./core/mouseobject.cpp ...
>> Compiling ./core/primitive.cpp ...
>> Compiling ./core/pyramid.cpp ...
>> Compiling ./core/rectangular.cpp ...
>> Compiling ./core/renderable.cpp ...
>> Compiling ./core/ring.cpp ...
>> Compiling ./core/sphere.cpp ...
>> Compiling ./python/convex.cpp ...
>> Compiling ./python/curve.cpp ...
>> Compiling ./python/cvisualmodule.cpp ...
>> Compiling ./python/faces.cpp ...
>> Compiling ./python/num_util.cpp ...
>> make[1]: *** [num_util.lo] Error 1
>> make[1]: Leaving directory 
>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/src'
>> make: *** [all-recursive] Error 1
>>
>> I looked at the build log and here is what it says:
>>
>>  g++ -I/home/dharrison/wares/rhe4_a64/include/python2.5 
>> -I/home/dharrison/wares/rhe4_a64/lib/python2.5/site-packages/numpy/core/include 
>> -DHAVE_CONFIG_H -I../include -I../include 
>> -I/home/dharrison/wares/rhe4_a64/include/gtkglextmm-1.2 
>> -I/home/dharrison/wares/rhe4_a64/lib/gtkglextmm-1.2/include 
>> -I/home/dharrison/wares/rhe4_a64/include/gtkglext-1.0 
>> -I/home/dharrison/wares/rhe4_a64/include/gtkmm-2.4 
>> -I/home/dharrison/wares/rhe4_a64/lib/gtkmm-2.4/include 
>> -I/home/dharrison/wares/rhe4_a64/lib/gtkglext-1.0/include 
>> -I/usr/X11R6/include 
>> -I/home/dharrison/wares/rhe4_a64/include/gdkmm-2.4 
>> -I/home/dharrison/wares/rhe4_a64/lib/gdkmm-2.4/include 
>> -I/home/dharrison/wares/rhe4_a64/include/pangomm-1.4 
>> -I/home/dharrison/wares/rhe4_a64/include/gtk-2.0 
>> -I/home/dharrison/wares/rhe4_a64/lib/gtk-2.0/include 
>> -I/home/dharrison/wares/rhe4_a64/include/pango-1.0 
>> -I/home/dharrison/wares/rhe4_a64/include/glib-2.0 
>> -I/home/dharrison/wares/rhe4_a64/lib/glib-2.0/include 
>> -I/home/dharrison/wares/rhe4_a64/include/cairo 
>> -I/home/dharrison/wares/rhe4_a64/include/glibmm-2.4 
>> -I/home/dharrison/wares/rhe4_a64/lib/glibmm-2.4/include 
>> -I/home/dharrison/wares/rhe4_a64/include/cairomm-1.0 
>> -I/home/dharrison/wares/rhe4_a64/include/sigc++-2.0 
>> -I/home/dharrison/wares/rhe4_a64/lib/sigc++-2.0/include 
>> -I/home/dharrison/wares/rhe4_a64/include/atk-1.0 
>> -I/home/dharrison/wares/rhe4_a64/include/atkmm-1.6 
>> -I/usr/include/freetype2 
>> -I/home/dharrison/wares/rhe4_a64/include/libglademm-2.4 
>> -I/home/dharrison/wares/rhe4_a64/lib/libglademm-2.4/include 
>> -I/usr/include/libpng12 -I/usr/include/libglade-2.0 
>> -I/usr/include/libxml2 -I../include/gtk2 -pthread 
>> -I/home/dharrison/wares/rhe4_a64/include/glib-2.0 
>> -I/home/dharrison/wares/rhe4_a64/lib/glib-2.0/include 
>> -I/home/dharrison/wares/rhe4_a64/include/python2.5 
>> -I/home/dharrison/wares/rhe4_a64/lib/python2.5/site-packages/numpy/core/include 
>> -fpic -DPIC -g -O2 -ftemplate-depth-120 -MMD -MF num_util.d -MT 
>> "num_util.d num_util.lo" -c ./python/num_util.cpp  -fPIC -DPIC -o 
>> .libs/num_util.o
>> ./python/num_util.cpp: In function `std::vector<npy_intp, 
>> std::allocator<npy_intp> > 
>> cvisual::python::shape(boost::python::numeric::array)':
>> ./python/num_util.cpp:234: error: cannot convert `npy_intp*' to 
>> `int*' in initialization
>>
>> I will take a look see and see if this is something that can be 
>> fixed. Has anyone else
>> managed to get the beta to compile from ground zero on 64-bit linux?  
>> So far,
>> I think I have spent about 1.5 days just on the installation.  I hope
>> this is not typical.
>>
>>        David
>>
>>
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] Still no progress with the Beta version of visual python

[David H. <dha...@ta...>]

Well, to get around the latest issue, I went ahead and downloaded
a modern libboost (1.34) and compiled it as well.  There are some issues
in getting visual to use this libboost.  It appears it now counts on
libboost being available from the compiler.  But the boost provided
for my compiler, g++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3),
doesn't appear to link.  I managed to force it to use a local libboost
by modifying the Makefiles.  After that, everything finally compiled,
linked, and installed.  However, a simple test program dies with
the following backtrace.  Any ideas?

       David

#0  0x0000002a9a3ae1b5 in cvisual::icososphere::subdivide (this=0x40a01090,
    span=Variable "span" is not available.
) at ./core/util/icososphere.cpp:137
#1  0x0000002a9a3aea0f in icososphere (this=0x40a01090, depth=Variable 
"depth" is not available.
)
    at 
/home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/shared_array.hpp:93
#2  0x0000002a9a2e685c in cvisual::sphere::create_cache ()
    at 
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_vector.h:557
#3  0x0000002a9a2e437e in cvisual::renderable::refresh_cache (this=0x8b0890,
    geometry=Variable "geometry" is not available.
) at ./core/renderable.cpp:122
#4  0x0000002a9a2cca96 in cvisual::display_kernel::draw (this=0x8ca6a0,
    scene_geometry=@0x40a01690, whicheye=Variable "whicheye" is not 
available.
)
    at 
/home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/iterator/iterator_facade.hpp:644
#5  0x0000002a9a2cfc04 in cvisual::display_kernel::render_scene 
(this=0x8ca6a0)
    at ./core/display_kernel.cpp:791
#6  0x0000002a9a3c1840 in cvisual::render_surface::on_expose_event 
(this=Variable "this" is not available.
)
    at ./gtk2/render_surface.cpp:237
#7  0x0000002a9b071e46 in Gtk::Widget_Class::expose_event_callback (
    self=0x8f4030, p0=0x40a01e50) at widget.cc:4494
#8  0x0000002a9bae3fa8 in _gtk_marshal_BOOLEAN__BOXED (closure=0x9316b0,
    return_value=0x40a01990, n_param_values=Variable "n_param_values" is 
not available.
) at gtkmarshalers.c:84
#9  0x0000002a9c5dbd39 in IA__g_closure_invoke (closure=0x9316b0,
    return_value=0x40a01990, n_param_values=2, param_values=0x40a01b20,
    invocation_hint=0x40a019c0) at gclosure.c:490
#10 0x0000002a9c5effcc in signal_emit_unlocked_R (node=0x931720, detail=0,
    instance=0x8f4030, emission_return=0x40a01aa0,
    instance_and_params=0x40a01b20) at gsignal.c:2478
#11 0x0000002a9c5f08fa in IA__g_signal_emit_valist (instance=0x8f4030,
    signal_id=Variable "signal_id" is not available.
) at gsignal.c:2209
#12 0x0000002a9c5f0f13 in IA__g_signal_emit (instance=Variable 
"instance" is not available.
) at gsignal.c:2243
#13 0x0000002a9bbebcc0 in gtk_widget_event_internal (widget=0x8f4030,
    event=0x40a01e50) at gtkwidget.c:3915
#14 0x0000002a9bae2821 in IA__gtk_main_do_event (event=0x40a01e50)
    at gtkmain.c:1537
#15 0x0000002a9be70712 in gdk_window_process_updates_internal 
(window=0x8fbe10)
    at gdkwindow.c:2338
#16 0x0000002a9be707db in IA__gdk_window_process_all_updates ()
    at gdkwindow.c:2401
#17 0x0000002a9be70848 in gdk_window_update_idle (data=Variable "data" 
is not available.
) at gdkwindow.c:2259
#18 0x0000002a9cb6f147 in IA__g_main_context_dispatch (context=0x8ff410)
    at gmain.c:2045
#19 0x0000002a9cb70b78 in g_main_context_iterate (context=0x8ff410,
    block=2037111104, dispatch=1, self=Variable "self" is not available.
) at gmain.c:2677
#20 0x0000002a9cb70eda in IA__g_main_loop_run (loop=0x92b5f0) at 
gmain.c:2881
#21 0x0000002a9bae1b81 in IA__gtk_main () at gtkmain.c:1154
#22 0x0000002a9a3c769d in cvisual::gui_main::run (this=0x8cf010)
    at ./gtk2/display.cpp:547
#23 0x0000002a9a3cad71 in cvisual::gui_main::thread_proc ()
    at ./gtk2/display.cpp:567
#24 0x0000002a9cd1c167 in boost::function0<void, 
std::allocator<boost::function_base> >::operator() ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#25 0x0000002a9ce37427 in boost::thread_group::join_all ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_thread-gcc34-mt-1_34.so.1.34.0



David Harrison wrote:
> I got past the problem in num_util.cpp: it looks like a simple typo.
> Line 234 in that file should read:
>
>   npy_intp* dims_ptr = PyArray_DIMS(arr.ptr());
>
> I then found that visual inherits the linking problem from
> gtkglextmm-1.2.0.  It tries to link against libGL twice: once
> in the right place /usr/lib64/libGL.so and once in the wrong
> place: /usr/lib/libGL.so.  A hack to its generated libtool
> script gets around that problem.
>
> But then it finally threw me a very significant curve:
>
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/libboost_python.a(numeric.o): 
> relocation R_X86_64_32 against `a local symbol' can not be used when 
> making a shared object; recompile with -fPIC
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/libboost_python.a: 
> could not read symbols: Bad value
>
> It appears it is trying to link against a non-shared version of 
> libboost_python.
> I will try to hack around this one too (there appears to be a .so for
> libboost_python) but I think I am going to have to edit the final link line.
>
>        David
>
> Bruce Sherwood wrote:
>   
>> Alas, I have no experience with nor access to a 64-bit environment, 
>> and it does sound like that's the issue. I'm surprised that there 
>> aren't standard 64-bit packages for GTK, which after all is a pretty 
>> standard library. Is there anyone reading this list with 64-bit 
>> experience?
>>
>> Bruce Sherwood
>>
>> David Harrison wrote:
>>     
>>> At Bruce's suggestion, I downloaded visual-4.beta15
>>> and tried installing it on my AMD 64-bit machine
>>> running RedHat Enterprise 4.  It uses numpy and
>>> that is good.  But it now has a very major dependency
>>> on GTK and its libraries.  I spent about 4 hours today
>>> compiling an ever increasing number of dependent
>>> libraries to try to get things going.  Just for grins,
>>> take a look at what libraries are needed:
>>>
>>> 4 atk-1.19.3/     4 gtk+-2.10.13/     4 libsigc++-1.2.7/  4 
>>> cairo-1.4.8/    4 gtkglext-1.2.0/   4 libsigc++-2.0.17/
>>> 4 cairomm-1.2.4/  4 gtkglextmm-1.2.0/   4 gtkmm-2.10.10/    4 
>>> numpy-1.0.3/     4 glib-2.12.9/    4 gtkmm-2.2.12/     4 
>>> pango-1.17.3/     4 visual-4.beta15/
>>> 4 glibmm-2.12.10/ 4 libglademm-2.4.2/ 4 Python-2.5.1/
>>>
>>> Many of these are tricky to install because they are either
>>> not very friendly to 64-bit or to installs in non-standard
>>> locations.  After a fair bit of hacking, I managed to get
>>> all of these installed (watch out for gtkglextmm -- it has some
>>> sort of wild problem attempting to link against libGL -- libtool
>>> for it had to be seriously hacked).
>>>
>>> After everything was installed, visual-4.beta15 finally stopped
>>> complaining about dependent libraries and compiled.  But
>>> it looks like it has a problem:
>>>
>>> steiner.visual-4.beta15: make
>>> Making all in site-packages/visual
>>> make[1]: Entering directory 
>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/site-packages/visual' 
>>>
>>> make[1]: Nothing to be done for `all'.
>>> make[1]: Leaving directory 
>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/site-packages/visual' 
>>>
>>> Making all in src
>>> make[1]: Entering directory 
>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/src'
>>> This is a quiet Makefile. If make exits with an error, check 
>>> src/build.log to see the complete error message(s). In the event of 
>>> an error that you cannot debug, please send a message to 
>>> vis...@li..., including the files 
>>> config.log and src/build.log, requesting assistance.
>>> Compiling ./core/arrow.cpp ...
>>> Compiling ./core/axial.cpp ...
>>> Compiling ./core/box.cpp ...
>>> Compiling ./core/cone.cpp ...
>>> Compiling ./core/cylinder.cpp ...
>>> Compiling ./core/display_kernel.cpp ...
>>> Compiling ./core/ellipsoid.cpp ...
>>> Compiling ./core/frame.cpp ...
>>> Compiling ./core/label.cpp ...
>>> Compiling ./core/mouseobject.cpp ...
>>> Compiling ./core/primitive.cpp ...
>>> Compiling ./core/pyramid.cpp ...
>>> Compiling ./core/rectangular.cpp ...
>>> Compiling ./core/renderable.cpp ...
>>> Compiling ./core/ring.cpp ...
>>> Compiling ./core/sphere.cpp ...
>>> Compiling ./python/convex.cpp ...
>>> Compiling ./python/curve.cpp ...
>>> Compiling ./python/cvisualmodule.cpp ...
>>> Compiling ./python/faces.cpp ...
>>> Compiling ./python/num_util.cpp ...
>>> make[1]: *** [num_util.lo] Error 1
>>> make[1]: Leaving directory 
>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/src'
>>> make: *** [all-recursive] Error 1
>>>
>>> I looked at the build log and here is what it says:
>>>
>>>  g++ -I/home/dharrison/wares/rhe4_a64/include/python2.5 
>>> -I/home/dharrison/wares/rhe4_a64/lib/python2.5/site-packages/numpy/core/include 
>>> -DHAVE_CONFIG_H -I../include -I../include 
>>> -I/home/dharrison/wares/rhe4_a64/include/gtkglextmm-1.2 
>>> -I/home/dharrison/wares/rhe4_a64/lib/gtkglextmm-1.2/include 
>>> -I/home/dharrison/wares/rhe4_a64/include/gtkglext-1.0 
>>> -I/home/dharrison/wares/rhe4_a64/include/gtkmm-2.4 
>>> -I/home/dharrison/wares/rhe4_a64/lib/gtkmm-2.4/include 
>>> -I/home/dharrison/wares/rhe4_a64/lib/gtkglext-1.0/include 
>>> -I/usr/X11R6/include 
>>> -I/home/dharrison/wares/rhe4_a64/include/gdkmm-2.4 
>>> -I/home/dharrison/wares/rhe4_a64/lib/gdkmm-2.4/include 
>>> -I/home/dharrison/wares/rhe4_a64/include/pangomm-1.4 
>>> -I/home/dharrison/wares/rhe4_a64/include/gtk-2.0 
>>> -I/home/dharrison/wares/rhe4_a64/lib/gtk-2.0/include 
>>> -I/home/dharrison/wares/rhe4_a64/include/pango-1.0 
>>> -I/home/dharrison/wares/rhe4_a64/include/glib-2.0 
>>> -I/home/dharrison/wares/rhe4_a64/lib/glib-2.0/include 
>>> -I/home/dharrison/wares/rhe4_a64/include/cairo 
>>> -I/home/dharrison/wares/rhe4_a64/include/glibmm-2.4 
>>> -I/home/dharrison/wares/rhe4_a64/lib/glibmm-2.4/include 
>>> -I/home/dharrison/wares/rhe4_a64/include/cairomm-1.0 
>>> -I/home/dharrison/wares/rhe4_a64/include/sigc++-2.0 
>>> -I/home/dharrison/wares/rhe4_a64/lib/sigc++-2.0/include 
>>> -I/home/dharrison/wares/rhe4_a64/include/atk-1.0 
>>> -I/home/dharrison/wares/rhe4_a64/include/atkmm-1.6 
>>> -I/usr/include/freetype2 
>>> -I/home/dharrison/wares/rhe4_a64/include/libglademm-2.4 
>>> -I/home/dharrison/wares/rhe4_a64/lib/libglademm-2.4/include 
>>> -I/usr/include/libpng12 -I/usr/include/libglade-2.0 
>>> -I/usr/include/libxml2 -I../include/gtk2 -pthread 
>>> -I/home/dharrison/wares/rhe4_a64/include/glib-2.0 
>>> -I/home/dharrison/wares/rhe4_a64/lib/glib-2.0/include 
>>> -I/home/dharrison/wares/rhe4_a64/include/python2.5 
>>> -I/home/dharrison/wares/rhe4_a64/lib/python2.5/site-packages/numpy/core/include 
>>> -fpic -DPIC -g -O2 -ftemplate-depth-120 -MMD -MF num_util.d -MT 
>>> "num_util.d num_util.lo" -c ./python/num_util.cpp  -fPIC -DPIC -o 
>>> .libs/num_util.o
>>> ./python/num_util.cpp: In function `std::vector<npy_intp, 
>>> std::allocator<npy_intp> > 
>>> cvisual::python::shape(boost::python::numeric::array)':
>>> ./python/num_util.cpp:234: error: cannot convert `npy_intp*' to 
>>> `int*' in initialization
>>>
>>> I will take a look see and see if this is something that can be 
>>> fixed. Has anyone else
>>> managed to get the beta to compile from ground zero on 64-bit linux?  
>>> So far,
>>> I think I have spent about 1.5 days just on the installation.  I hope
>>> this is not typical.
>>>
>>>        David
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.net email is sponsored by DB2 Express
>>> Download DB2 Express C - the FREE version of DB2 express and take
>>> control of your XML. No limits. Just data. Click to get it now.
>>> http://sourceforge.net/powerbar/db2/
>>> _______________________________________________
>>> Visualpython-users mailing list
>>> Vis...@li...
>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>       
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>   

Re: [Visualpython-users] Still no progress with the Beta version of visual python

[David H. <dha...@ta...>]

It appears that other standard examples (like stonehenge) don't
work either.  Is it possible that boost 1.34 is not compatible
with visual-beta15?  The backtrace from stonehenge is:

#0  PyDict_GetItem (op=0xd122f0, key=0x0) at Objects/dictobject.c:569
#1  0x0000002a9c8b777a in boost::python::objects::function::call ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#2  0x0000002a9c8bb305 in 
boost::detail::function::void_function_ref_invoker0<boost::python::objects::(anonymous 
namespace)::bind_return, void>::invoke ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#3  0x0000002a9c8c2167 in boost::function0<void, 
std::allocator<boost::function_base> >::operator() ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#4  0x0000002a9c8c1c58 in 
boost::python::detail::exception_handler::operator()
    ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#5  0x0000002a99b90dbf in 
boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, 
boost::python::detail::translate_exception<std::runtime_error, void 
(*)(std::runtime_error)>, boost::_bi::list3<boost::arg<1> (*)(), 
boost::arg<2> (*)(), boost::_bi::value<void (*)(std::runtime_error)> > 
 >, bool, boost::python::detail::exception_handler const&, 
boost::function0<void, std::allocator<boost::function_base> > 
const&>::invoke (function_obj_ptr=Variable "function_obj_ptr" is not 
available.
)
    at 
/home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/python/detail/translate_exception.hpp:45
#6  0x0000002a9c8c1fe7 in boost::function2<bool, 
boost::python::detail::exception_handler const&, boost::function0<void, 
std::allocator<boost::function_base> >const&, 
std::allocator<boost::function_base> >::operator() ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#7  0x0000002a9c8c1c48 in 
boost::python::detail::exception_handler::operator()
    ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#8  0x0000002a99b90ccf in 
boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, 
boost::python::detail::translate_exception<std::invalid_argument, void 
(*)(std::invalid_argument)>, boost::_bi::list3<boost::arg<1> (*)(), 
boost::arg<2> (*)(), boost::_bi::value<void (*)(std::invalid_argument)> 
 > >, bool,boost::python::detail::exception_handler const&, 
boost::function0<void, std::allocator<boost::function_base> > 
const&>::invoke (function_obj_ptr=Variable "function_obj_ptr" is not 
available.
)
    at 
/home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/python/detail/translate_exception.hpp:45
#9  0x0000002a9c8c1fe7 in boost::function2<bool, 
boost::python::detail::exception_handler const&, boost::function0<void, 
std::allocator<boost::function_base> >const&, 
std::allocator<boost::function_base> >::operator() ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#10 0x0000002a9c8c1c48 in 
boost::python::detail::exception_handler::operator()
    ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#11 0x0000002a99b90baf in 
boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, 
boost::python::detail::translate_exception<std::out_of_range,void 
(*)(std::out_of_range)>, boost::_bi::list3<boost::arg<1> (*)(), 
boost::arg<2> (*)(), boost::_bi::value<void (*)(std::out_of_range)> > >, 
bool, boost::python::detail::exception_handler const&, 
boost::function0<void, std::allocator<boost::function_base> > 
const&>::invoke (function_obj_ptr=Variable "function_obj_ptr" is not 
available.
)
    at 
/home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/python/detail/translate_exception.hpp:45
#12 0x0000002a9c8c1fe7 in boost::function2<bool, 
boost::python::detail::exception_handler const&, boost::function0<void, 
std::allocator<boost::function_base> >const&, 
std::allocator<boost::function_base> >::operator() ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#13 0x0000002a9c8c1c7b in boost::python::handle_exception_impl ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#14 0x0000002a9c8bb219 in 
boost::python::handle_exception<boost::python::objects::(anonymous 
namespace)::bind_return> ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#15 0x0000002a9c8b9a1e in 
boost::python::objects::function::add_to_namespace ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#16 0x00000000004194c3 in PyObject_Call (func=Variable "func" is not 
available.
) at Objects/abstract.c:1860


David Harrison wrote:
>
> Well, to get around the latest issue, I went ahead and downloaded
> a modern libboost (1.34) and compiled it as well.  There are some issues
> in getting visual to use this libboost.  It appears it now counts on
> libboost being available from the compiler.  But the boost provided
> for my compiler, g++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3),
> doesn't appear to link.  I managed to force it to use a local libboost
> by modifying the Makefiles.  After that, everything finally compiled,
> linked, and installed.  However, a simple test program dies with
> the following backtrace.  Any ideas?
>
>       David
>
> #0  0x0000002a9a3ae1b5 in cvisual::icososphere::subdivide 
> (this=0x40a01090,
>    span=Variable "span" is not available.
> ) at ./core/util/icososphere.cpp:137
> #1  0x0000002a9a3aea0f in icososphere (this=0x40a01090, depth=Variable 
> "depth" is not available.
> )
>    at 
> /home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/shared_array.hpp:93 
>
> #2  0x0000002a9a2e685c in cvisual::sphere::create_cache ()
>    at 
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_vector.h:557 
>
> #3  0x0000002a9a2e437e in cvisual::renderable::refresh_cache 
> (this=0x8b0890,
>    geometry=Variable "geometry" is not available.
> ) at ./core/renderable.cpp:122
> #4  0x0000002a9a2cca96 in cvisual::display_kernel::draw (this=0x8ca6a0,
>    scene_geometry=@0x40a01690, whicheye=Variable "whicheye" is not 
> available.
> )
>    at 
> /home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/iterator/iterator_facade.hpp:644 
>
> #5  0x0000002a9a2cfc04 in cvisual::display_kernel::render_scene 
> (this=0x8ca6a0)
>    at ./core/display_kernel.cpp:791
> #6  0x0000002a9a3c1840 in cvisual::render_surface::on_expose_event 
> (this=Variable "this" is not available.
> )
>    at ./gtk2/render_surface.cpp:237
> #7  0x0000002a9b071e46 in Gtk::Widget_Class::expose_event_callback (
>    self=0x8f4030, p0=0x40a01e50) at widget.cc:4494
> #8  0x0000002a9bae3fa8 in _gtk_marshal_BOOLEAN__BOXED (closure=0x9316b0,
>    return_value=0x40a01990, n_param_values=Variable "n_param_values" 
> is not available.
> ) at gtkmarshalers.c:84
> #9  0x0000002a9c5dbd39 in IA__g_closure_invoke (closure=0x9316b0,
>    return_value=0x40a01990, n_param_values=2, param_values=0x40a01b20,
>    invocation_hint=0x40a019c0) at gclosure.c:490
> #10 0x0000002a9c5effcc in signal_emit_unlocked_R (node=0x931720, 
> detail=0,
>    instance=0x8f4030, emission_return=0x40a01aa0,
>    instance_and_params=0x40a01b20) at gsignal.c:2478
> #11 0x0000002a9c5f08fa in IA__g_signal_emit_valist (instance=0x8f4030,
>    signal_id=Variable "signal_id" is not available.
> ) at gsignal.c:2209
> #12 0x0000002a9c5f0f13 in IA__g_signal_emit (instance=Variable 
> "instance" is not available.
> ) at gsignal.c:2243
> #13 0x0000002a9bbebcc0 in gtk_widget_event_internal (widget=0x8f4030,
>    event=0x40a01e50) at gtkwidget.c:3915
> #14 0x0000002a9bae2821 in IA__gtk_main_do_event (event=0x40a01e50)
>    at gtkmain.c:1537
> #15 0x0000002a9be70712 in gdk_window_process_updates_internal 
> (window=0x8fbe10)
>    at gdkwindow.c:2338
> #16 0x0000002a9be707db in IA__gdk_window_process_all_updates ()
>    at gdkwindow.c:2401
> #17 0x0000002a9be70848 in gdk_window_update_idle (data=Variable "data" 
> is not available.
> ) at gdkwindow.c:2259
> #18 0x0000002a9cb6f147 in IA__g_main_context_dispatch (context=0x8ff410)
>    at gmain.c:2045
> #19 0x0000002a9cb70b78 in g_main_context_iterate (context=0x8ff410,
>    block=2037111104, dispatch=1, self=Variable "self" is not available.
> ) at gmain.c:2677
> #20 0x0000002a9cb70eda in IA__g_main_loop_run (loop=0x92b5f0) at 
> gmain.c:2881
> #21 0x0000002a9bae1b81 in IA__gtk_main () at gtkmain.c:1154
> #22 0x0000002a9a3c769d in cvisual::gui_main::run (this=0x8cf010)
>    at ./gtk2/display.cpp:547
> #23 0x0000002a9a3cad71 in cvisual::gui_main::thread_proc ()
>    at ./gtk2/display.cpp:567
> #24 0x0000002a9cd1c167 in boost::function0<void, 
> std::allocator<boost::function_base> >::operator() ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
> #25 0x0000002a9ce37427 in boost::thread_group::join_all ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_thread-gcc34-mt-1_34.so.1.34.0 
>
>
>
>
> David Harrison wrote:
>> I got past the problem in num_util.cpp: it looks like a simple typo.
>> Line 234 in that file should read:
>>
>>   npy_intp* dims_ptr = PyArray_DIMS(arr.ptr());
>>
>> I then found that visual inherits the linking problem from
>> gtkglextmm-1.2.0.  It tries to link against libGL twice: once
>> in the right place /usr/lib64/libGL.so and once in the wrong
>> place: /usr/lib/libGL.so.  A hack to its generated libtool
>> script gets around that problem.
>>
>> But then it finally threw me a very significant curve:
>>
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/libboost_python.a(numeric.o): 
>> relocation R_X86_64_32 against `a local symbol' can not be used when 
>> making a shared object; recompile with -fPIC
>> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/libboost_python.a: 
>> could not read symbols: Bad value
>>
>> It appears it is trying to link against a non-shared version of 
>> libboost_python.
>> I will try to hack around this one too (there appears to be a .so for
>> libboost_python) but I think I am going to have to edit the final 
>> link line.
>>
>>        David
>>
>> Bruce Sherwood wrote:
>>  
>>> Alas, I have no experience with nor access to a 64-bit environment, 
>>> and it does sound like that's the issue. I'm surprised that there 
>>> aren't standard 64-bit packages for GTK, which after all is a pretty 
>>> standard library. Is there anyone reading this list with 64-bit 
>>> experience?
>>>
>>> Bruce Sherwood
>>>
>>> David Harrison wrote:
>>>    
>>>> At Bruce's suggestion, I downloaded visual-4.beta15
>>>> and tried installing it on my AMD 64-bit machine
>>>> running RedHat Enterprise 4.  It uses numpy and
>>>> that is good.  But it now has a very major dependency
>>>> on GTK and its libraries.  I spent about 4 hours today
>>>> compiling an ever increasing number of dependent
>>>> libraries to try to get things going.  Just for grins,
>>>> take a look at what libraries are needed:
>>>>
>>>> 4 atk-1.19.3/     4 gtk+-2.10.13/     4 libsigc++-1.2.7/  4 
>>>> cairo-1.4.8/    4 gtkglext-1.2.0/   4 libsigc++-2.0.17/
>>>> 4 cairomm-1.2.4/  4 gtkglextmm-1.2.0/   4 gtkmm-2.10.10/    4 
>>>> numpy-1.0.3/     4 glib-2.12.9/    4 gtkmm-2.2.12/     4 
>>>> pango-1.17.3/     4 visual-4.beta15/
>>>> 4 glibmm-2.12.10/ 4 libglademm-2.4.2/ 4 Python-2.5.1/
>>>>
>>>> Many of these are tricky to install because they are either
>>>> not very friendly to 64-bit or to installs in non-standard
>>>> locations.  After a fair bit of hacking, I managed to get
>>>> all of these installed (watch out for gtkglextmm -- it has some
>>>> sort of wild problem attempting to link against libGL -- libtool
>>>> for it had to be seriously hacked).
>>>>
>>>> After everything was installed, visual-4.beta15 finally stopped
>>>> complaining about dependent libraries and compiled.  But
>>>> it looks like it has a problem:
>>>>
>>>> steiner.visual-4.beta15: make
>>>> Making all in site-packages/visual
>>>> make[1]: Entering directory 
>>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/site-packages/visual' 
>>>>
>>>> make[1]: Nothing to be done for `all'.
>>>> make[1]: Leaving directory 
>>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/site-packages/visual' 
>>>>
>>>> Making all in src
>>>> make[1]: Entering directory 
>>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/src'
>>>> This is a quiet Makefile. If make exits with an error, check 
>>>> src/build.log to see the complete error message(s). In the event of 
>>>> an error that you cannot debug, please send a message to 
>>>> vis...@li..., including the files 
>>>> config.log and src/build.log, requesting assistance.
>>>> Compiling ./core/arrow.cpp ...
>>>> Compiling ./core/axial.cpp ...
>>>> Compiling ./core/box.cpp ...
>>>> Compiling ./core/cone.cpp ...
>>>> Compiling ./core/cylinder.cpp ...
>>>> Compiling ./core/display_kernel.cpp ...
>>>> Compiling ./core/ellipsoid.cpp ...
>>>> Compiling ./core/frame.cpp ...
>>>> Compiling ./core/label.cpp ...
>>>> Compiling ./core/mouseobject.cpp ...
>>>> Compiling ./core/primitive.cpp ...
>>>> Compiling ./core/pyramid.cpp ...
>>>> Compiling ./core/rectangular.cpp ...
>>>> Compiling ./core/renderable.cpp ...
>>>> Compiling ./core/ring.cpp ...
>>>> Compiling ./core/sphere.cpp ...
>>>> Compiling ./python/convex.cpp ...
>>>> Compiling ./python/curve.cpp ...
>>>> Compiling ./python/cvisualmodule.cpp ...
>>>> Compiling ./python/faces.cpp ...
>>>> Compiling ./python/num_util.cpp ...
>>>> make[1]: *** [num_util.lo] Error 1
>>>> make[1]: Leaving directory 
>>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/src'
>>>> make: *** [all-recursive] Error 1
>>>>
>>>> I looked at the build log and here is what it says:
>>>>
>>>>  g++ -I/home/dharrison/wares/rhe4_a64/include/python2.5 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/python2.5/site-packages/numpy/core/include 
>>>> -DHAVE_CONFIG_H -I../include -I../include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/gtkglextmm-1.2 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/gtkglextmm-1.2/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/gtkglext-1.0 
>>>> -I/home/dharrison/wares/rhe4_a64/include/gtkmm-2.4 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/gtkmm-2.4/include 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/gtkglext-1.0/include 
>>>> -I/usr/X11R6/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/gdkmm-2.4 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/gdkmm-2.4/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/pangomm-1.4 
>>>> -I/home/dharrison/wares/rhe4_a64/include/gtk-2.0 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/gtk-2.0/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/pango-1.0 
>>>> -I/home/dharrison/wares/rhe4_a64/include/glib-2.0 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/glib-2.0/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/cairo 
>>>> -I/home/dharrison/wares/rhe4_a64/include/glibmm-2.4 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/glibmm-2.4/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/cairomm-1.0 
>>>> -I/home/dharrison/wares/rhe4_a64/include/sigc++-2.0 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/sigc++-2.0/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/atk-1.0 
>>>> -I/home/dharrison/wares/rhe4_a64/include/atkmm-1.6 
>>>> -I/usr/include/freetype2 
>>>> -I/home/dharrison/wares/rhe4_a64/include/libglademm-2.4 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/libglademm-2.4/include 
>>>> -I/usr/include/libpng12 -I/usr/include/libglade-2.0 
>>>> -I/usr/include/libxml2 -I../include/gtk2 -pthread 
>>>> -I/home/dharrison/wares/rhe4_a64/include/glib-2.0 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/glib-2.0/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/python2.5 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/python2.5/site-packages/numpy/core/include 
>>>> -fpic -DPIC -g -O2 -ftemplate-depth-120 -MMD -MF num_util.d -MT 
>>>> "num_util.d num_util.lo" -c ./python/num_util.cpp  -fPIC -DPIC -o 
>>>> .libs/num_util.o
>>>> ./python/num_util.cpp: In function `std::vector<npy_intp, 
>>>> std::allocator<npy_intp> > 
>>>> cvisual::python::shape(boost::python::numeric::array)':
>>>> ./python/num_util.cpp:234: error: cannot convert `npy_intp*' to 
>>>> `int*' in initialization
>>>>
>>>> I will take a look see and see if this is something that can be 
>>>> fixed. Has anyone else
>>>> managed to get the beta to compile from ground zero on 64-bit 
>>>> linux?  So far,
>>>> I think I have spent about 1.5 days just on the installation.  I hope
>>>> this is not typical.
>>>>
>>>>        David
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------- 
>>>>
>>>> This SF.net email is sponsored by DB2 Express
>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>> control of your XML. No limits. Just data. Click to get it now.
>>>> http://sourceforge.net/powerbar/db2/
>>>> _______________________________________________
>>>> Visualpython-users mailing list
>>>> Vis...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>>       
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>
>>   
>
>

Re: [Visualpython-users] Still no progress with the Beta version of visual python

[David H. <dha...@ta...>]

I have done some further testing.  Here are the example
scripts that successfully run (all of the others are failing):

convex.py
doublependulum.py
faces_cone.py
faces_heightfield.py
glinfo.py
gyro.py
gyro2.py
hanoi.py
labels.py
lathe.py
lorenz.py
texttest.py
texturetest.py (although I see no
  patterned textures -- transparency seems to work.  It
  also seems to hang on exit).
toroid_drag.py
toroid.py
wave.py

Most of the ones that fail take seg-faults.  A few hang with
no redisplay.  Almost all of them produce lots of warnings
to standard output like this:

(<unknown>:25310): Gtk-WARNING **: Mixing deprecated and non-deprecated 
GtkToolbar API is not allowed
(<unknown>:25310): Gtk-WARNING **: Mixing deprecated and non-deprecated 
GtkToolbar API is not allowed
(<unknown>:25310): Gtk-WARNING **: Mixing deprecated and non-deprecated 
GtkToolbar API is not allowed
(<unknown>:25310): Gtk-WARNING **: Mixing deprecated and non-deprecated 
GtkToolbar API is not allowed

So it is not completely DOA.  There are 36 examples in the
examples directory and 16 of them are passing.  Of course, my
particular program is one of the ones that is failing :-(

David Harrison wrote:
>
> It appears that other standard examples (like stonehenge) don't
> work either.  Is it possible that boost 1.34 is not compatible
> with visual-beta15?  The backtrace from stonehenge is:
>
> #0  PyDict_GetItem (op=0xd122f0, key=0x0) at Objects/dictobject.c:569
> #1  0x0000002a9c8b777a in boost::python::objects::function::call ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
> #2  0x0000002a9c8bb305 in 
> boost::detail::function::void_function_ref_invoker0<boost::python::objects::(anonymous 
> namespace)::bind_return, void>::invoke ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
> #3  0x0000002a9c8c2167 in boost::function0<void, 
> std::allocator<boost::function_base> >::operator() ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
> #4  0x0000002a9c8c1c58 in 
> boost::python::detail::exception_handler::operator()
>    ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
> #5  0x0000002a99b90dbf in 
> boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, 
> boost::python::detail::translate_exception<std::runtime_error, void 
> (*)(std::runtime_error)>, boost::_bi::list3<boost::arg<1> (*)(), 
> boost::arg<2> (*)(), boost::_bi::value<void (*)(std::runtime_error)> > 
> >, bool, boost::python::detail::exception_handler const&, 
> boost::function0<void, std::allocator<boost::function_base> > 
> const&>::invoke (function_obj_ptr=Variable "function_obj_ptr" is not 
> available.
> )
>    at 
> /home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/python/detail/translate_exception.hpp:45 
>
> #6  0x0000002a9c8c1fe7 in boost::function2<bool, 
> boost::python::detail::exception_handler const&, 
> boost::function0<void, std::allocator<boost::function_base> >const&, 
> std::allocator<boost::function_base> >::operator() ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
> #7  0x0000002a9c8c1c48 in 
> boost::python::detail::exception_handler::operator()
>    ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
> #8  0x0000002a99b90ccf in 
> boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, 
> boost::python::detail::translate_exception<std::invalid_argument, void 
> (*)(std::invalid_argument)>, boost::_bi::list3<boost::arg<1> (*)(), 
> boost::arg<2> (*)(), boost::_bi::value<void 
> (*)(std::invalid_argument)> > >, 
> bool,boost::python::detail::exception_handler const&, 
> boost::function0<void, std::allocator<boost::function_base> > 
> const&>::invoke (function_obj_ptr=Variable "function_obj_ptr" is not 
> available.
> )
>    at 
> /home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/python/detail/translate_exception.hpp:45 
>
> #9  0x0000002a9c8c1fe7 in boost::function2<bool, 
> boost::python::detail::exception_handler const&, 
> boost::function0<void, std::allocator<boost::function_base> >const&, 
> std::allocator<boost::function_base> >::operator() ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
> #10 0x0000002a9c8c1c48 in 
> boost::python::detail::exception_handler::operator()
>    ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
> #11 0x0000002a99b90baf in 
> boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, 
> boost::python::detail::translate_exception<std::out_of_range,void 
> (*)(std::out_of_range)>, boost::_bi::list3<boost::arg<1> (*)(), 
> boost::arg<2> (*)(), boost::_bi::value<void (*)(std::out_of_range)> > 
> >, bool, boost::python::detail::exception_handler const&, 
> boost::function0<void, std::allocator<boost::function_base> > 
> const&>::invoke (function_obj_ptr=Variable "function_obj_ptr" is not 
> available.
> )
>    at 
> /home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/python/detail/translate_exception.hpp:45 
>
> #12 0x0000002a9c8c1fe7 in boost::function2<bool, 
> boost::python::detail::exception_handler const&, 
> boost::function0<void, std::allocator<boost::function_base> >const&, 
> std::allocator<boost::function_base> >::operator() ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
> #13 0x0000002a9c8c1c7b in boost::python::handle_exception_impl ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
> #14 0x0000002a9c8bb219 in 
> boost::python::handle_exception<boost::python::objects::(anonymous 
> namespace)::bind_return> ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
> #15 0x0000002a9c8b9a1e in 
> boost::python::objects::function::add_to_namespace ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
> #16 0x00000000004194c3 in PyObject_Call (func=Variable "func" is not 
> available.
> ) at Objects/abstract.c:1860
>
>
> David Harrison wrote:
>>
>> Well, to get around the latest issue, I went ahead and downloaded
>> a modern libboost (1.34) and compiled it as well.  There are some issues
>> in getting visual to use this libboost.  It appears it now counts on
>> libboost being available from the compiler.  But the boost provided
>> for my compiler, g++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3),
>> doesn't appear to link.  I managed to force it to use a local libboost
>> by modifying the Makefiles.  After that, everything finally compiled,
>> linked, and installed.  However, a simple test program dies with
>> the following backtrace.  Any ideas?
>>
>>       David
>>
>> #0  0x0000002a9a3ae1b5 in cvisual::icososphere::subdivide 
>> (this=0x40a01090,
>>    span=Variable "span" is not available.
>> ) at ./core/util/icososphere.cpp:137
>> #1  0x0000002a9a3aea0f in icososphere (this=0x40a01090, 
>> depth=Variable "depth" is not available.
>> )
>>    at 
>> /home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/shared_array.hpp:93 
>>
>> #2  0x0000002a9a2e685c in cvisual::sphere::create_cache ()
>>    at 
>> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_vector.h:557 
>>
>> #3  0x0000002a9a2e437e in cvisual::renderable::refresh_cache 
>> (this=0x8b0890,
>>    geometry=Variable "geometry" is not available.
>> ) at ./core/renderable.cpp:122
>> #4  0x0000002a9a2cca96 in cvisual::display_kernel::draw (this=0x8ca6a0,
>>    scene_geometry=@0x40a01690, whicheye=Variable "whicheye" is not 
>> available.
>> )
>>    at 
>> /home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/iterator/iterator_facade.hpp:644 
>>
>> #5  0x0000002a9a2cfc04 in cvisual::display_kernel::render_scene 
>> (this=0x8ca6a0)
>>    at ./core/display_kernel.cpp:791
>> #6  0x0000002a9a3c1840 in cvisual::render_surface::on_expose_event 
>> (this=Variable "this" is not available.
>> )
>>    at ./gtk2/render_surface.cpp:237
>> #7  0x0000002a9b071e46 in Gtk::Widget_Class::expose_event_callback (
>>    self=0x8f4030, p0=0x40a01e50) at widget.cc:4494
>> #8  0x0000002a9bae3fa8 in _gtk_marshal_BOOLEAN__BOXED (closure=0x9316b0,
>>    return_value=0x40a01990, n_param_values=Variable "n_param_values" 
>> is not available.
>> ) at gtkmarshalers.c:84
>> #9  0x0000002a9c5dbd39 in IA__g_closure_invoke (closure=0x9316b0,
>>    return_value=0x40a01990, n_param_values=2, param_values=0x40a01b20,
>>    invocation_hint=0x40a019c0) at gclosure.c:490
>> #10 0x0000002a9c5effcc in signal_emit_unlocked_R (node=0x931720, 
>> detail=0,
>>    instance=0x8f4030, emission_return=0x40a01aa0,
>>    instance_and_params=0x40a01b20) at gsignal.c:2478
>> #11 0x0000002a9c5f08fa in IA__g_signal_emit_valist (instance=0x8f4030,
>>    signal_id=Variable "signal_id" is not available.
>> ) at gsignal.c:2209
>> #12 0x0000002a9c5f0f13 in IA__g_signal_emit (instance=Variable 
>> "instance" is not available.
>> ) at gsignal.c:2243
>> #13 0x0000002a9bbebcc0 in gtk_widget_event_internal (widget=0x8f4030,
>>    event=0x40a01e50) at gtkwidget.c:3915
>> #14 0x0000002a9bae2821 in IA__gtk_main_do_event (event=0x40a01e50)
>>    at gtkmain.c:1537
>> #15 0x0000002a9be70712 in gdk_window_process_updates_internal 
>> (window=0x8fbe10)
>>    at gdkwindow.c:2338
>> #16 0x0000002a9be707db in IA__gdk_window_process_all_updates ()
>>    at gdkwindow.c:2401
>> #17 0x0000002a9be70848 in gdk_window_update_idle (data=Variable 
>> "data" is not available.
>> ) at gdkwindow.c:2259
>> #18 0x0000002a9cb6f147 in IA__g_main_context_dispatch (context=0x8ff410)
>>    at gmain.c:2045
>> #19 0x0000002a9cb70b78 in g_main_context_iterate (context=0x8ff410,
>>    block=2037111104, dispatch=1, self=Variable "self" is not available.
>> ) at gmain.c:2677
>> #20 0x0000002a9cb70eda in IA__g_main_loop_run (loop=0x92b5f0) at 
>> gmain.c:2881
>> #21 0x0000002a9bae1b81 in IA__gtk_main () at gtkmain.c:1154
>> #22 0x0000002a9a3c769d in cvisual::gui_main::run (this=0x8cf010)
>>    at ./gtk2/display.cpp:547
>> #23 0x0000002a9a3cad71 in cvisual::gui_main::thread_proc ()
>>    at ./gtk2/display.cpp:567
>> #24 0x0000002a9cd1c167 in boost::function0<void, 
>> std::allocator<boost::function_base> >::operator() ()
>>   from 
>> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
>> #25 0x0000002a9ce37427 in boost::thread_group::join_all ()
>>   from 
>> /home/dharrison/wares/rhe4_a64/lib/libboost_thread-gcc34-mt-1_34.so.1.34.0 
>>
>>
>>
>>
>> David Harrison wrote:
>>> I got past the problem in num_util.cpp: it looks like a simple typo.
>>> Line 234 in that file should read:
>>>
>>>   npy_intp* dims_ptr = PyArray_DIMS(arr.ptr());
>>>
>>> I then found that visual inherits the linking problem from
>>> gtkglextmm-1.2.0.  It tries to link against libGL twice: once
>>> in the right place /usr/lib64/libGL.so and once in the wrong
>>> place: /usr/lib/libGL.so.  A hack to its generated libtool
>>> script gets around that problem.
>>>
>>> But then it finally threw me a very significant curve:
>>>
>>> /usr/bin/ld: 
>>> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/libboost_python.a(numeric.o): 
>>> relocation R_X86_64_32 against `a local symbol' can not be used when 
>>> making a shared object; recompile with -fPIC
>>> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/libboost_python.a: 
>>> could not read symbols: Bad value
>>>
>>> It appears it is trying to link against a non-shared version of 
>>> libboost_python.
>>> I will try to hack around this one too (there appears to be a .so for
>>> libboost_python) but I think I am going to have to edit the final 
>>> link line.
>>>
>>>        David
>>>
>>> Bruce Sherwood wrote:
>>>  
>>>> Alas, I have no experience with nor access to a 64-bit environment, 
>>>> and it does sound like that's the issue. I'm surprised that there 
>>>> aren't standard 64-bit packages for GTK, which after all is a 
>>>> pretty standard library. Is there anyone reading this list with 
>>>> 64-bit experience?
>>>>
>>>> Bruce Sherwood
>>>>
>>>> David Harrison wrote:
>>>>   
>>>>> At Bruce's suggestion, I downloaded visual-4.beta15
>>>>> and tried installing it on my AMD 64-bit machine
>>>>> running RedHat Enterprise 4.  It uses numpy and
>>>>> that is good.  But it now has a very major dependency
>>>>> on GTK and its libraries.  I spent about 4 hours today
>>>>> compiling an ever increasing number of dependent
>>>>> libraries to try to get things going.  Just for grins,
>>>>> take a look at what libraries are needed:
>>>>>
>>>>> 4 atk-1.19.3/     4 gtk+-2.10.13/     4 libsigc++-1.2.7/  4 
>>>>> cairo-1.4.8/    4 gtkglext-1.2.0/   4 libsigc++-2.0.17/
>>>>> 4 cairomm-1.2.4/  4 gtkglextmm-1.2.0/   4 gtkmm-2.10.10/    4 
>>>>> numpy-1.0.3/     4 glib-2.12.9/    4 gtkmm-2.2.12/     4 
>>>>> pango-1.17.3/     4 visual-4.beta15/
>>>>> 4 glibmm-2.12.10/ 4 libglademm-2.4.2/ 4 Python-2.5.1/
>>>>>
>>>>> Many of these are tricky to install because they are either
>>>>> not very friendly to 64-bit or to installs in non-standard
>>>>> locations.  After a fair bit of hacking, I managed to get
>>>>> all of these installed (watch out for gtkglextmm -- it has some
>>>>> sort of wild problem attempting to link against libGL -- libtool
>>>>> for it had to be seriously hacked).
>>>>>
>>>>> After everything was installed, visual-4.beta15 finally stopped
>>>>> complaining about dependent libraries and compiled.  But
>>>>> it looks like it has a problem:
>>>>>
>>>>> steiner.visual-4.beta15: make
>>>>> Making all in site-packages/visual
>>>>> make[1]: Entering directory 
>>>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/site-packages/visual' 
>>>>>
>>>>> make[1]: Nothing to be done for `all'.
>>>>> make[1]: Leaving directory 
>>>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/site-packages/visual' 
>>>>>
>>>>> Making all in src
>>>>> make[1]: Entering directory 
>>>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/src'
>>>>> This is a quiet Makefile. If make exits with an error, check 
>>>>> src/build.log to see the complete error message(s). In the event 
>>>>> of an error that you cannot debug, please send a message to 
>>>>> vis...@li..., including the files 
>>>>> config.log and src/build.log, requesting assistance.
>>>>> Compiling ./core/arrow.cpp ...
>>>>> Compiling ./core/axial.cpp ...
>>>>> Compiling ./core/box.cpp ...
>>>>> Compiling ./core/cone.cpp ...
>>>>> Compiling ./core/cylinder.cpp ...
>>>>> Compiling ./core/display_kernel.cpp ...
>>>>> Compiling ./core/ellipsoid.cpp ...
>>>>> Compiling ./core/frame.cpp ...
>>>>> Compiling ./core/label.cpp ...
>>>>> Compiling ./core/mouseobject.cpp ...
>>>>> Compiling ./core/primitive.cpp ...
>>>>> Compiling ./core/pyramid.cpp ...
>>>>> Compiling ./core/rectangular.cpp ...
>>>>> Compiling ./core/renderable.cpp ...
>>>>> Compiling ./core/ring.cpp ...
>>>>> Compiling ./core/sphere.cpp ...
>>>>> Compiling ./python/convex.cpp ...
>>>>> Compiling ./python/curve.cpp ...
>>>>> Compiling ./python/cvisualmodule.cpp ...
>>>>> Compiling ./python/faces.cpp ...
>>>>> Compiling ./python/num_util.cpp ...
>>>>> make[1]: *** [num_util.lo] Error 1
>>>>> make[1]: Leaving directory 
>>>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/src'
>>>>> make: *** [all-recursive] Error 1
>>>>>
>>>>> I looked at the build log and here is what it says:
>>>>>
>>>>>  g++ -I/home/dharrison/wares/rhe4_a64/include/python2.5 
>>>>> -I/home/dharrison/wares/rhe4_a64/lib/python2.5/site-packages/numpy/core/include 
>>>>> -DHAVE_CONFIG_H -I../include -I../include 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/gtkglextmm-1.2 
>>>>> -I/home/dharrison/wares/rhe4_a64/lib/gtkglextmm-1.2/include 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/gtkglext-1.0 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/gtkmm-2.4 
>>>>> -I/home/dharrison/wares/rhe4_a64/lib/gtkmm-2.4/include 
>>>>> -I/home/dharrison/wares/rhe4_a64/lib/gtkglext-1.0/include 
>>>>> -I/usr/X11R6/include 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/gdkmm-2.4 
>>>>> -I/home/dharrison/wares/rhe4_a64/lib/gdkmm-2.4/include 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/pangomm-1.4 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/gtk-2.0 
>>>>> -I/home/dharrison/wares/rhe4_a64/lib/gtk-2.0/include 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/pango-1.0 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/glib-2.0 
>>>>> -I/home/dharrison/wares/rhe4_a64/lib/glib-2.0/include 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/cairo 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/glibmm-2.4 
>>>>> -I/home/dharrison/wares/rhe4_a64/lib/glibmm-2.4/include 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/cairomm-1.0 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/sigc++-2.0 
>>>>> -I/home/dharrison/wares/rhe4_a64/lib/sigc++-2.0/include 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/atk-1.0 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/atkmm-1.6 
>>>>> -I/usr/include/freetype2 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/libglademm-2.4 
>>>>> -I/home/dharrison/wares/rhe4_a64/lib/libglademm-2.4/include 
>>>>> -I/usr/include/libpng12 -I/usr/include/libglade-2.0 
>>>>> -I/usr/include/libxml2 -I../include/gtk2 -pthread 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/glib-2.0 
>>>>> -I/home/dharrison/wares/rhe4_a64/lib/glib-2.0/include 
>>>>> -I/home/dharrison/wares/rhe4_a64/include/python2.5 
>>>>> -I/home/dharrison/wares/rhe4_a64/lib/python2.5/site-packages/numpy/core/include 
>>>>> -fpic -DPIC -g -O2 -ftemplate-depth-120 -MMD -MF num_util.d -MT 
>>>>> "num_util.d num_util.lo" -c ./python/num_util.cpp  -fPIC -DPIC -o 
>>>>> .libs/num_util.o
>>>>> ./python/num_util.cpp: In function `std::vector<npy_intp, 
>>>>> std::allocator<npy_intp> > 
>>>>> cvisual::python::shape(boost::python::numeric::array)':
>>>>> ./python/num_util.cpp:234: error: cannot convert `npy_intp*' to 
>>>>> `int*' in initialization
>>>>>
>>>>> I will take a look see and see if this is something that can be 
>>>>> fixed. Has anyone else
>>>>> managed to get the beta to compile from ground zero on 64-bit 
>>>>> linux?  So far,
>>>>> I think I have spent about 1.5 days just on the installation.  I hope
>>>>> this is not typical.
>>>>>
>>>>>        David
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------- 
>>>>>
>>>>> This SF.net email is sponsored by DB2 Express
>>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>>> control of your XML. No limits. Just data. Click to get it now.
>>>>> http://sourceforge.net/powerbar/db2/
>>>>> _______________________________________________
>>>>> Visualpython-users mailing list
>>>>> Vis...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>>>       
>>>
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.net email is sponsored by DB2 Express
>>> Download DB2 Express C - the FREE version of DB2 express and take
>>> control of your XML. No limits. Just data. Click to get it now.
>>> http://sourceforge.net/powerbar/db2/
>>> _______________________________________________
>>> Visualpython-users mailing list
>>> Vis...@li...
>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>
>>>   
>>
>>
>
>