jhiggins Posted March 7, 2006 Share Posted March 7, 2006 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!! Quote Link to comment Share on other sites More sharing options...
edward Posted March 8, 2006 Share Posted March 8, 2006 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. Quote Link to comment Share on other sites More sharing options...
jhiggins Posted March 9, 2006 Author Share Posted March 9, 2006 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 Quote Link to comment Share on other sites More sharing options...
rvinluan Posted March 9, 2006 Share Posted March 9, 2006 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 toundefined 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 Quote Link to comment Share on other sites More sharing options...
jhiggins Posted March 9, 2006 Author Share Posted March 9, 2006 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.