Mario Marengo Posted September 10, 2004 Share Posted September 10, 2004 Hi all, We just installed the HDK here at work, and naturally, the first thing I did was try to compile one of the examples.... and it failed The problem was easy to fix, and it's specific to using multiple compilers, but I just thought I'd mention it in case someone else runs into it. Our license server (where the HDK was installed) is RedHat7.3 with gcc 2.96, and our workstations (where I do my development) are SuSE9.1 with gcc 3.3.3 -- much has changed between those two versions of gcc. Now; I don't know if hdkinstall has the smarts to expand a different set of headers for each Linux flavour (haven't tried since the hfs7.0.185 we downloaded had to be the one for RH7.3), but it means that I have to live (for now) in an environment with mixed compilers/OSs. (blame it on JC! ) What failed was the class UT_OStrStream in the header UT/UT_NTStreamUtil.h. And the reason for the failure is that this class inherits from std::strstream, which is deprecated (!) and so not visible in the standard include paths for gcc3. Problem #1 is that the old strstream cannot be blindly replaced with the new stringstream (from the header <sstream>) -- not only do they work differently, but the constructors have different signatures. And problem #2 is that none of the calls to the parent constructors are qualified with the std:: namespace (ok for gcc2.X, not ok for gcc3.X). My quick workaround was to change lines 34 and 35 (in UT/UT_NTStreamUtil.h), which read: #else include <strstream.h> to: #elif defined(GCC3) #include <backward/strstream> using std::ostrstream; #else #include <strstream.h> Another bit that gcc3.X couldn't grok was lne 171 in the file UT/UT_CPIO.h, which reads "istream *myis;", and should read "std::istream *myis;". At least those are the ones I've found so far... ....OK. Now I can start playing with my new toy!... "Hello World" here we come! Cheers! P.S: @Edward: Maybe the HDK should include a frozen version of <strstream>, since I think those backward-compatibility headers may disappear altogether for gcc4.0 (?) Quote Link to comment Share on other sites More sharing options...
edward Posted September 11, 2004 Share Posted September 11, 2004 i'm not sure if gcc 3.3.3 is not supported yet ... ... actually, wouldn't you run into problems with compiling your HDK stuff in gcc 3.3.3 and then telling a Houdini which was compiled with gcc 2.96 to load it? Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted September 11, 2004 Author Share Posted September 11, 2004 ... actually, wouldn't you run into problems with compiling your HDK stuff in gcc 3.3.3 and then telling a Houdini which was compiled with gcc 2.96 to load it? 13737[/snapback] Hey Edward, No, I don't run into problems because I'm building for a RH9 installation. So, with the fixes I mentioned in the post, all sample dso's compile and load just fine in our SuSE9.1 machines (which have a RH9 Houdini installation). For the license server machine and the other ones running RH7.3 (a RH7.3 Houdini installation, and gcc2.96) I have to do a separate compilation, for which I can use the original headers unchanged. Our problem is/was that hdkinstall insists on installing only on the machine serving the licenses (RH7.3/gcc2.96 in our case), and we couldn't get it to install in any of the other ones. So I was stuck trying to compile in a gcc3 environment, using headers targeted at a gcc2.96 installation, wich worked fine for the RH7.3 machines, but failed for the SuSE9.1 machines... As it turns out though, JC dug a little deeper and, a little after posting that message, we found out that hdkinstall was simply not working as intended: it is supposed to be able to install in any machine. So it's a bug in the end. I believe someone's looking into it. Cheers! Quote Link to comment Share on other sites More sharing options...
bensimons Posted February 7, 2007 Share Posted February 7, 2007 Heya, It seems like this is still an issue? Is it 2007 already? :-) I know they're mostly WARNINGS, not ERRORS, but I thought I'd raise the topic.. I'm using a RH installation (2.6.11-1.1369_FC4smp) with g++ version 4.0.0 and Houdini 8.1.655. While trying to compile the RealFlow Exporter SOP from sources (ie. the "SOP: Realflow" inside Houdini.RealFlow_v1.0.0.src.tar.gz) from sourceforge (http://sourceforge.net/projects/odforceplugins) I'm getting an error on UT_NTStreamUtil.h $ make/usr/bin/g++ -DVERSION=\"8.1.655\" -DDLLEXPORT="" -DMAKING_DSO -D_GNU_SOURCE -DLINUX -DI386 -DSESI_LITTLE_ENDIAN -DENABLE_THREADS -DUSE_PTHREADS -DOFSTREAM_PERMISSIONS=", 0666" -DGCC4 -I/X/tools/binlinux/sesi/hfs8.1.655/toolkit/include -Wall -W -Wno-parentheses -Wno-sign-compare -Wno-reorder -Wno-uninitialized -Wunused -O2 SOP_RF_Export.CIn file included from /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/backward/iostream.h:31, from /X/tools/binlinux/sesi/hfs8.1.655/toolkit/include/SYS/fpreal16.h:93, from /X/tools/binlinux/sesi/hfs8.1.655/toolkit/include/SYS/SYS_Types.h:65, from /X/tools/binlinux/sesi/hfs8.1.655/toolkit/include/UT/UT_EnvControl.h:29, from SOP_RF_Export.C:31:/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <iostream> instead of the deprecated header <iostream.h>. To disable this warning use -Wno-deprecated./X/tools/binlinux/sesi/hfs8.1.655/toolkit/include/OP/OP_Node.h:1134: warning: unused parameter Quote Link to comment Share on other sites More sharing options...
rjpieke Posted February 8, 2007 Share Posted February 8, 2007 Have you guys tried using both -DGCC3 and -DGCC4 as command-line options to the compiler? We're compiling using GCC4.0.2 without any problems. Quote Link to comment Share on other sites More sharing options...
bensimons Posted February 8, 2007 Share Posted February 8, 2007 Have you guys tried using both -DGCC3 and -DGCC4 as command-line options to the compiler? We're compiling using GCC4.0.2 without any problems. ha ha!! yeah, using BOTH works.. :-) that's a better workaround. thx 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.