Jump to content

Custom Sop That Generates Ribs Fails When Gzipping


Recommended Posts

i don't know if anyone else has had experience with this, but i have a sop that generates a rib that i recently updated to the Ri Spec so that binary ribs can be generated, which works great.

The next step for me, which i thought would have been trivial is to get the SOP to also gzip the rib as well.

my changes pretty much consist of adding

RtString compression = "gzip";

RiOption("rib", "format", &format, RI_NULL);

before my RiBegin

but whenever i try to use this i end up getting houdini to crash.

this is what my crashlog gives me

Crash report from jeff; FUSE Version 7.0.427

Traceback from Tue Mar 7 14:08:19 2006

Caught signal 11

UT_StackTrace::doTracebackIntoBuffer(UT_WorkBuffer &, UTsignalHandlerArg *, char const *) (??:0)

UT_StackTrace::doTraceback(UTsignalHandlerArg, char const *) (??:0)

createCrashLog(UTsignalHandlerArg, char const *) (??:0)

AP_Interface::coredumpHandler(UTsignalHandlerArg) (??:0)

UT_Signal::processSignal(int, siginfo *, void *) (??:0)

pthread_sighandler_rt (signals.c:121)

<unknown>

z_deflate+0x189

z_gzwrite+0x9e

TgFlsBuf+0xa8

<unknown>

<unknown>

RIPRequest1+0xed

ribRiProcedural+0x6c

RiProcedural+0x25

...

i have the all the necessary renderman libraries included when i build, but it seems as though maybe houdini is conflicting its zip libraries with mine, but really i don't know!!

help!!

Link to comment
Share on other sites

Yes, that's a known problem with conflicting zlib's. It will be fixed in the next major release of Houdini. As a workaround, you'll have to statically link your own version of zlib as well as making sure that you're using the correct zlib header.

Link to comment
Share on other sites

Yes, that's a known problem with conflicting zlib's. It will be fixed in the next major release of Houdini. As a workaround, you'll have to statically link your own version of zlib as well as making sure that you're using the correct zlib header.

25474[/snapback]

hey edward,

i'm having trouble getting your workaround to work.

if i statically link in the prman zip lib and include all of the right headers then my sop will load in houdini, but crash when i try to turn on the gzip compression as in my first post.

if i downlad the latest version of zlib and build it, compile it using those zlib libraries instead of the prman ones then my custom sop fails to load do to

undefined symbol: z_gzclose

which is defined in the prman headers, but not in the latest zlib.

what am i missing!

thanks for the info :)

jeff

Link to comment
Share on other sites

Hi Jeff,

if i statically link in the prman zip lib and include all of the right headers then my sop will load in houdini, but crash when i try to turn on the gzip compression as in my first post.

Is your custom SOP using any other libraries that could possibly link to zlib? One way to find out is to see if your lib is still linking to libz.so (Linux) or zlib1.dll (Windows) after you've applied Edward's suggestions.

If you do have other libraries linking to zlib, then you need to rebuild those libs and have them statically link to zlib.

if i downlad the latest version of zlib and build it, compile it using those zlib libraries instead of the prman ones then my custom sop fails to load do to

undefined symbol: z_gzclose

which is defined in the prman headers, but not in the latest zlib.

Yeah, you definitely don't want to exclude prman's version of zlib from your project. It seems like they've mangled the original zlib symbols with a "z_" prefix, so having only the original zlib would not work.

Regards,

Rob

Link to comment
Share on other sites

Hi Jeff,

Is your custom SOP using any other libraries that could possibly link to zlib?  One way to find out is to see if your lib is still linking to libz.so (Linux) or zlib1.dll (Windows) after you've applied Edward's suggestions.

If you do have other libraries linking to zlib, then you need to rebuild those libs and have them statically link to zlib.

Yeah, you definitely don't want to exclude prman's version of zlib from your project.  It seems like they've mangled the original zlib symbols with a "z_" prefix, so having only the original zlib would not work.

Regards,

Rob

25512[/snapback]

no, i'm not using that in any of my custom code, other than linking against prman's libzip.a

i think whats happening is that one of houdini's libs is using another version of zlib and its conflicting with prman's zip lib, but i don't see a way to get around this.

i'm hoping i can get edwards workaround to work though, but i'm haven't been successfull yet!

otherwise i'll have to wait for houdini 9 :)

thanks for your help rob.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...