Howdi,
.
First, does the Apprentice Edition support VEX DSOs as described in,
$HFS/houdini/vex/dso/VEX_VexOp.html
.
Second, it says that only g++ is needed on Linux but the HDK is needed on windows. I'm curious as to why.
Would a cygwin port of g++ work on windows? Or are there other factors?
.
Third, if the Apprentice Edition does allow VEX DSOs then what is the proper installation?

.
myVexOp.dso in $JOB/houdini/dso/vex?
This will work because $JOB is in my $HOUDINI_PATH and $HOUDINI_DSO_PATH checks in the dso directories of $HOUDINI_PATH?
(hconfig -ap is your best friend)
.
Once the myVexOp.dso is in the correct place you need to add it to the library
echo vex/myVexOp.dso > $JOB/houdini/vex/VEXdso
.
Am I understanding all this correctly?
.
.
Thanks,
jim.
.
(sorry about the .'s, lynx doesn't like double new lines)

Wolfwood
Howdi,
.
First, does the Apprentice Edition support VEX DSOs as described in,
$HFS/houdini/vex/dso/VEX_VexOp.html

dunno, sorry

Woolfwood
.
Second, it says that only g++ is needed on Linux but the HDK is needed on windows. I'm curious as to why.
Would a cygwin port of g++ work on windows? Or are there other factors?

Good question – and you're not the first to ask it. Unfortunately, I've never heard an answer to that one

Woolfwood
Third, if the Apprentice Edition does allow VEX DSOs then what is the proper installation?

.
myVexOp.dso in $JOB/houdini/dso/vex?
This will work because $JOB is in my $HOUDINI_PATH and $HOUDINI_DSO_PATH checks in the dso directories of $HOUDINI_PATH?
(hconfig -ap is your best friend)
.
Once the myVexOp.dso is in the correct place you need to add it to the library
echo vex/myVexOp.dso > $JOB/houdini/vex/VEXdso
.
Am I understanding all this correctly?

This one I can answer

The mechanism is this: Houdini looks through the HOUDINI_PATH and also checks some “pre-determined” subdirectories thereof. Specifically (for DSOs) , it looks inside $HOUDINI_PATH/vex and if it exists, will look for the file “VEXdso” inside there. If *it* exists, it will go through each entry inside it, and *prepend* the HOUDINI_DSO_PATH to it to finally get at each *VEX* dso (I'm stressing VEX because things are different if you're talking about custom-pluggin dso's – the ones you'd make using the HDK).

So. Say your *vex* dso is in “/a/b/c/d/myVexDso.so”; and let's say $JOB is among the members of HOUDINI_PATH. To get houdini to find your dso you would:

1. Make sure the directory $JOB/houdini/vex exists.

2. Make sure HOUDINI_DSO_PATH contains (among others) the “a/b/c” entry:
“<…>a/b/c:<…>:&”

2. In there, create a file called VEXdso (who's full path would then be “$JOB/houdini/vex/VEXdso”

3. Edit this file, and add the single line:
d/myVexDso.so

Now Houdini finds it because:
1. it checks $HOUDINI_PATH, and among the things there it finds ‘$JOB’, so it tries $JOB/houdini/vex and in there finds the file VEXdso.
2. It then comes across the “d/myVexDso.so” entry in this file, and prepends each one of the $HOUDINI_DSO_PATH entries to it in turn, until it gets to “/a/b/c” which then expands to “/a/b/c/d/myVexDso.so” which is the full path to your dso.

The confusing bit about the “standard” way described in the docs is that parts of the final chain are implicit, because houdini doesn't just strictly check $HOUDINI_PATH, but also $HOUDINI_PATH/houdini, ($HP)/houdini/dso, ($HP)/houdini/vex, etc.

Confused yet?

Thanks Mario for the in-depth explanation.

As it turns out I have everything setup correctly. And after setting HOUDINI_DSO_ERROR Houdini was nice enough to tell me that my .so has a “undefined symbol: _ZN9VEX_VexOpC1EPKc..gibberish..” error.
.
Which is kinda odd since I copied and compiled the example verbatim in the VEX_VexOp.html.
.
.
Hmmmm problem solving, funnnn.

Thanks again,

jim.

Wolfwood
And after setting HOUDINI_DSO_ERROR Houdini was nice enough to tell me that my .so has a “undefined symbol: _ZN9VEX_VexOpC1EPKc..gibberish..” error.

Hmmmm - smells like different mangling between your dso and the Houdini libs….

Which compiler are you using?
If it's g++, is it 2.96? – I believe that from g++ version 3.1 and above (I think), the mangling was changed… not sure, but worth mentioning just in case. I use g++ 2.96 and all seems OK.

Also – and I'm sure you've done this already, but just in case – make sure to link against -ldl and -ldb1

cheers,

I'm using 3.2.2, thats what I get for keeping current.
*grumble* Name mangling should be standardized.

jim.

Wolfwood
I'm using 3.2.2, thats what I get for keeping current.
*grumble* Name mangling should be standardized.

It's not standard because they're desperately trying to catch up to the standard, lol.
Although I have a suspicion that most changes come from trying to get it to compile the stuff Alexandrescu publishes – all of them “standard” C++, and all of them *way* kewl, but AFAIK, just one compiler that can grok them straight from the page

Oh well…

Hmmmm - smells like different mangling between your dso and the Houdini libs….

Since its “Houdini for Linux RedHat 7” does that mean 2.96 is the recommended compiler?
.
After googling a bit it seems that the mangling changed during the 2.95.3 to 3.x jump. And 2.96 seems to be some sort of island inbetween. I'll try some different compilers and see how much damage I can cause.
.
Thanks again for the insight.
.
.
jim.