Jump to content

VC8 Win32 Houdini 9.5.379 compile error (blitz)


melazoma

Recommended Posts

Hi all,

I'm running VC8 Win32 Houdini 9.5.379. My VS.NET 2005 installation is setup to compile with hcustom. (have succeeded in compile Mark Story's RF4 plugins)

I keep running into this syntax error in the blitz library's memblock.h while compiling the ocean sop and vex ocean.

3rdparty/win32\blitz/memblock.h(193) : error C2146: syntax error : missing ';' before identifier 'mutex'
3rdparty/win32\blitz/memblock.h(195) : see reference to class template instantiation 'blitz::MemoryBlock<P_type>' being compiled
3rdparty/win32\blitz/memblock.h(193) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
3rdparty/win32\blitz/memblock.h(193) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
3rdparty/win32\blitz/memblock.h(193) : error C2146: syntax error : missing ';' before identifier 'mutex'

I'm compiling from a cygwin bash shell sourced with H9.5.379's environment per the HOT website's instructions.

The entire compile output is attached. Any hint is appreciated.

compile.zip

Link to comment
Share on other sites

Hi Melazoma,

Could you try commenting out the "#define BZ_THREADSAFE" line in Ocean.h. Or better replace it with

#ifndef WIN32

#define BZ_THREADSAFE

#endif

Blitz doesn't support multithreading for windows, however there is a pretty good chance this won't break things. Tell me if this works. In the long term it might be a good idea to me to switch from Blitz to another more modern equivalent (any suggestions people ?). These problems are only going to get worse as multicore architectures become more prominent.

I assume you are using a win32 version of houdini ? There is a known undiagnosed problem with the Win64.

Finally, thanks for the good bug report.

-Drew

Hi all,

I'm running VC8 Win32 Houdini 9.5.379. My VS.NET 2005 installation is setup to compile with hcustom. (have succeeded in compile Mark Story's RF4 plugins)

I keep running into this syntax error in the blitz library's memblock.h while compiling the ocean sop and vex ocean.

3rdparty/win32\blitz/memblock.h(193) : error C2146: syntax error : missing ';' before identifier 'mutex'
3rdparty/win32\blitz/memblock.h(195) : see reference to class template instantiation 'blitz::MemoryBlock<P_type>' being compiled
3rdparty/win32\blitz/memblock.h(193) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
3rdparty/win32\blitz/memblock.h(193) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
3rdparty/win32\blitz/memblock.h(193) : error C2146: syntax error : missing ';' before identifier 'mutex'

I'm compiling from a cygwin bash shell sourced with H9.5.379's environment per the HOT website's instructions.

The entire compile output is attached. Any hint is appreciated.

Link to comment
Share on other sites

Blitz doesn't support multithreading for windows, however there is a pretty good chance this won't break things. Tell me if this works. In the long term it might be a good idea to me to switch from Blitz to another more modern equivalent (any suggestions people ?). These problems are only going to get worse as multicore architectures become more prominent.

Really, Blitz++ supports multithreading for non-Windows? I'd like to know the answer to your question too. :) Offhand, uBlas is part of Boost now so hopefully it will be getting somewhat active development. Then there is nVidia's CUBLAS library which may or may not be usable in practice. MTL seems to be focusing on the multicore problem in their '07 paper but it looks like they're still working on it. Finally, there's FreePOOMA but that doesn't seem to be actively developed anymore.

DISCLAIMER: I have not tried ANY of the above mentioned libraries.

Link to comment
Share on other sites

Hi Edward,

I should have stated it more accurately, it supports re-entrancy so that it can be used for multi-threading. With the new mantra9 threading these things have all become more important.

Re replacing blitz++ I've looked into most of the ones you mention. My problem with most of the existing array libs are that they are either old, huge or platform specific, most often all three at once. I picked blitz++ because it seemed to be the best compromise.

I am interested in using boost and I'd looked into it for another hdk project. Unfortunately the boost functionality I was interested in was in a version newer than that included with the HDK which from memory is about five releases behind. I think that mixing two versions would have been asking for trouble... The boost option is a possibility for the HOT now that it's included in the HDK, last time I looked at it for the HOT it went into the "huge" basket. It's hard enough getting non developers up and running with hcustom on win32, bjam etc would have been a real nightmare. I can report that the HOT compiled and ran first go under OSX with H10, and I expect linux will be the same.

The reason I use blitz++ is as much about code readability as performance, raw BLAS doesn't help there. A CUDA fft may be useful for the HOT but I've been in the high performance computing game for long enough to know that the whole specialist hardware solution could easily be steamrolled by newer Intel hardware, so I won't rush into it.

-Drew

Really, Blitz++ supports multithreading for non-Windows? I'd like to know the answer to your question too. :) Offhand, uBlas is part of Boost now so hopefully it will be getting somewhat active development. Then there is nVidia's CUBLAS library which may or may not be usable in practice. MTL seems to be focusing on the multicore problem in their '07 paper but it looks like they're still working on it. Finally, there's FreePOOMA but that doesn't seem to be actively developed anymore.

DISCLAIMER: I have not tried ANY of the above mentioned libraries.

Link to comment
Share on other sites

I assume you are using a win32 version of houdini ? There is a known undiagnosed problem with the Win64.

Finally, thanks for the good bug report.

-Drew

First of all, Drew, a big thank you for the suggestion, I will try it out when I get back to my compile workstation.

I'm currently compiling on win32 right now, but I will move to win64(xp) soon.

Can you please tell me more about this issue with win64?

Link to comment
Share on other sites

The problem is undiagnosed, last time I looked it compiled ok but was giving bad numbers. Since then the fftw version has been upgraded which may make a difference, but at the moment I don't know. Debugging will involve stepping through in a debugger and finding out where the bad numbers are coming from, could be blitz++ or fftw, or the HOT code itself although it works fine under 64 bit linux.

-Drew

First of all, Drew, a big thank you for the suggestion, I will try it out when I get back to my compile workstation.

I'm currently compiling on win32 right now, but I will move to win64(xp) soon.

Can you please tell me more about this issue with win64?

Link to comment
Share on other sites

The problem is undiagnosed, last time I looked it compiled ok but was giving bad numbers. Since then the fftw version has been upgraded which may make a difference, but at the moment I don't know. Debugging will involve stepping through in a debugger and finding out where the bad numbers are coming from, could be blitz++ or fftw, or the HOT code itself although it works fine under 64 bit linux.

-Drew

Bad numbers as in bad point positions and/or attributes?

I'll definitely try to look at it when I get access to a 64-bit compile environment.

Also, this is sort of off-topic, but is it necessary to install VS.NET on 64-bit Windows in order to compile 64-bit binary? If possible, I actually want to keep my win32 setup...

Link to comment
Share on other sites

Bad points, so attributes are probably wrong as well.

On Win64 you install the 64 bit compilers at the same time as the 32 bit ones by selecting an extra option on the install wizard. I'm not sure if you can cross compile for 64 bit on win32 but I'm guessing you can, you probably didn't get it if you did a default install. From memory there are .bat files included in VS.NET that can be run to setup each environment, named something like VSVARS32.BAT. What I do is make two copies of the cygwin.bat script, eg cyg32.bat and cyg64.bat, then dump the commands from the relevant VS.NET script into the start of each of these cygwin scripts so I can easily double click on an icon and get a terminal setup for each environment.

-Drew

Bad numbers as in bad point positions and/or attributes?

I'll definitely try to look at it when I get access to a 64-bit compile environment.

Also, this is sort of off-topic, but is it necessary to install VS.NET on 64-bit Windows in order to compile 64-bit binary? If possible, I actually want to keep my win32 setup...

Edited by eloop
Link to comment
Share on other sites

it worked!

Thanks so much for the vc8 x64 tips.

VS 2005 on Win32 does seem to be able to compile x64 binaries with the optional x64 components installed.

However I still need the win64 libs from Houdini.

I think I'll try to get it to work on a win64 machine before I start ripping libs from a win64 houdini installation...

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...