Dirk Mittler

Hooray! I was able to solve my problem!

When I go to the download page for Houdini Apprentice, I overlook the 32-bit Red Hat Edition, because Debian, 32-bit is only listed as a second compatibility. And so I sell myself short by selecting on the last item of the list, the gcc 3.3 version.

I downloaded the Red Hat 32-bit version, because that one is also Debian-compatible, specifically listed with “Etch” (which is what I happen to be running. This is version 10.0.595 , gcc 3.4 ! And it works, where the other one did not.

I can finally create an RBD object without problems, and my earlier, saved volume fluid still animates properly.

Isn't it silly how I just overlooked that choice?

Thank you for giving me the hint about gcc versions!

Dirk

(Bump)

I think that one fact which I should mention, is that my Debian/Etch is based on glibc 2.2 , while your Houdini software seems to ask for glibc 2.3.4 .

I've vaguely remember having noticed the difference over a year ago, but taking my chances with it back then. In recent months and years, I've completely forgotten about this detail, because my experiments with Houdini mainly work.

Wouldn't it be odd though, if the glibc version of my computer, should affect the Python import of exactly one module? In general, the application seems stable enough. It's just this one module, that seems to create problems.

*** What the GUI error box seems to tell me, is that odesolver has additional parameters, which the calling context doesn't know how to handle. And yet within the GUI, I can create a rigibodysolver, dimiss a brief warning message, and then switch this solver back and forth between RBD and ODE. Either way, one of the tabs will show me settings which I can change through the GUI. So it appears that the message I get is merely a warning. ***

However, it seems that when trying to connect its AutoDOPNetwork, the GUI takes this warning to be an error. If it simply let the ?strange? ODE object stay in the DOP network, I suspect the former would actually work. In any case, if the node was still there, I'd be able to switch off its ODE option, and switch it to the RDB solver.

Dirk

I'm using an old version of “Kanotix”, which was based on Debian/Etch, kernel version 2.6.24 , 32-bit. Even though your download is labeled as being compatible with gcc 3.3 , I have installed on this box, gcc 4.1 . I have 2GB of RAM, and a dual-core AMD processor running at 2.6GHz.

I wouldn't want to install the Ubuntu download, because Ubuntu isn't Debian, and because Ubuntu is based on GNOME, which I don't have installed. Kanotix is based on KDE.

Also, today's Kanotix builds are based on Debian/Lenny , with a 64-bit as well as a 32-bit version available. However, I only have this Debian/Lenny build installed on a computer with limited hard drive capacity, and with absolutely no hardware-3D. Therefore, even though Houdini uses software rendering for its main output, Houdini still uses HW-3D for its GUI (which is normal by today's standards). And yet, the Debian/Lenny box isn't suitable for Houdini to be installed on it.

I once tried to launch Houdini with schroot, and yet having forgotten to overlay the directory /dev via ‘mount –bind’ , during that one session Houdini didn't detect HW-3D either, and was not able to display its GUI properly.

Which it does fine with the directory /dev remounted in my fashion.

Dirk

BTW, this is how I constructed my ‘fake root’:


#!/bin/bash

# This script will bind the root directory to
# /media/localbind
# including explicitly /home .

# It will next bind /empty to /media/localbind/usr/local/lib ,
# hoping that this does not affect /usr/local/lib .

# Then, houdini can be run within the schroot environment.

if
then
exit
fi

sudo mount –bind / /media/localbind
# DO NOT USE rbind !

sudo mount –bind /home /media/localbind/home

# Objective – remove:
sudo mount –bind /temp_usr_lib /media/localbind/usr/lib
sudo mount –bind /empty /media/localbind/usr/local/lib
sudo mount –bind /empty /media/localbind/usr/lib/python2.3/site-packages
sudo mount –bind /empty /media/localbind/usr/lib/python2.4/site-packages
sudo mount –bind /empty /media/localbind/usr/lib/python2.5/site-packages

sudo mount –bind /dev /media/localbind/dev
sudo mount –bind /proc /media/localbind/proc
sudo mount –bind /sys /media/localbind/sys


Obviously, each and every one of these mounts must be unmounted later, before which my scripts execute ‘sudo /sbin/ldconfig’ . As all of my scripts are still only experiments, I've been running them in a console window, and not getting error messages (only time delays). Also, I've gone to /media/localbind/usr/lib and verified via ‘ls -l libode*’ that the offending libs are gone, which are still present in /usr/lib …

And I'm sure that Houdini is running in its chroot, which is /media/localbind . Further, I've used the GUI of Houdini to visit such directories as /usr/local/lib, which the app sees, which would normally have subdirectories, but which are completely empty as seen from the app, when run in the chroot, just for further verification.