prefer to use COLLADA DOM in Code::Blocks

Hi everyone,

I prefer to use COLLADA DOM in Code::Blocks/MingW as IDE and compliers. (my current project using it). the problem is I just download the source files and can build COLLADA DOM by using VC2005 but the product from VC2005 can’t use in MingW, so I try to import the project to Code::Blocks but it’s can’t build the project (as dynamic link)

anyone know the solution to solve this problem. or anyone has successful using COLLADA DOM in other IDE on Window

please give me some advice

Best Regards,
Chet Chetchaiyan

Hi Chet. Unfortunately I haven’t tried getting the DOM compiling under MinGW so I’m not sure what would need to be done to make that work. I wanted to do that for the 2.0 release but I just didn’t have time.

kwizatz said he wanted to work on MinGW support and contribute a patch for it, but I’m not sure if he’s made progress on that.

Steve

Hi Chet, Steve,

I am glad to inform you that I made a lot of progress, but there are still some issues, which is why I haven’t provided you (Steve) with the patch.

The first minor issue is regarding PCRE, when I create a static library of it for some reason its symbols are labeled in some weird way, which makes either the DOM not find them or the C++ PCRE wrapper around the C PCRE library not find them either, so I have to link against the dll version, which is not optimal since I believe we want a monolithic DOM right?

The second issue I have is rather with the Test program, it requires the filesystem Boost library, but only the headers are provided for it in the DOM, I downloaded the latest Boost distribution but then I get a lot of missing symbols as well, so I needed to ask you which boost version are you using, or if you could provide its source package to me.

By the time I got to the Boost issue, I was to tired to continue figuring out everything by myself :D.

Anyway, I am working against a SVN Copy, so hopefully once it works you can just merge the patch into it.

Oh! and one more thing if you want to provide a copy of Mingw’s Make 3.81, I think you may also want to add either the latest coreutils or fmt.exe by itself since its required but not part of the stable MSYS installer.

Cheers!

You may find the page for building the third party libs on the wiki helpful. It documents how exactly we build all the libs, what versions we build against, etc.

It could be a version mismatch. The PCRE headers/libs included with the DOM are for PCRE 7.4, which was the latest version at the time I built it. The newest version is 7.6. If you built a PCRE 7.6 lib and dropped it in with the PCRE 7.4 headers used by the DOM, that could cause problems. You’d want to either build PCRE 7.4 or use 7.6 but also update the headers. In that case we’d want to update the PCRE libs for all platforms to 7.6, which I could do.

The second issue I have is rather with the Test program, it requires the filesystem Boost library, but only the headers are provided for it in the DOM, I downloaded the latest Boost distribution but then I get a lot of missing symbols as well, so I needed to ask you which boost version are you using, or if you could provide its source package to me.
We’re currently on version 1.34.1, which was the latest at the time I built. They’re now on 1.35 I believe. Instructions for how we build Boost are on the page I linked earlier.

By the time I got to the Boost issue, I was to tired to continue figuring out everything by myself.
Hah, totally understandable! Don’t feel like you need to work through all the problems yourself though. Feel free to post if you get stuck or you want me to try some stuff. Also feel free to email me at x@y [x = steven_thomas, y = playstation.sony.com]. Thanks so much for your work on this!

Oh! and one more thing if you want to provide a copy of Mingw’s Make 3.81, I think you may also want to add either the latest coreutils or fmt.exe by itself since its required but not part of the stable MSYS installer.
Thanks for the tip. I don’t really intend to provide MinGW with the DOM though. I just want to provide the stuff you need to build with MinGW, and I’d expect someone to obtain MinGW from mingw.org.

Steve

Yes, I found that out the hard way :smiley: it took me compiling 7.6 and 7.5 before realizing the version was listed in the headers.

I think this is more of a decspec() issue though, I will try using CMake rather than autotools and see if that yields better results (or at least figure out which exact flags do I need to pass)

There is no need to upgrade the header versions yet, but if you do, let me know.

Alright, thanks, I may contact you later regarding Boost because I am getting some odd undefined references to “boost::system::get_system_category()” among others, I think this is due to header mismatch though, I was using 1.35 after all.

No problem :smiley:

Oh well, I can add to the wiki regarding the steps to build using MSYS, so far it takes building and Installing Make 3.81 and grabbing the preview version of coreutils for fmt.

Cheers!.

Oh well, I can add to the wiki regarding the steps to build using MSYS, so far it takes building and Installing Make 3.81 and grabbing the preview version of coreutils for fmt.
Isn’t there just an installer or a zip file containing MinGW make 3.81? I’m confused about why you need preview versions or why you need to build make.

Indeed there is :D.

I tend to download source packages and manually build them.

As for why you need preview versions: for as much as I am grateful to and respect the MinGW developers, they have been dragging their “behinds” regarding a proper release for years now, the automated installer for both MinGW and MSYS installs rather old versions of the software, so you have to upgrade the packages manually, you have to start guessing what to get and where to decompress, a total nightmare specially when there can be 3 versions of the same package for MinGW, MSYS or mingwPORT.

they have been dragging their “behinds” regarding a proper release for years now
Heh, sounds like the same problem I’ve had getting DOM 2.0 done.

I understand the difficulties but I still feel like doing a special MinGW package just for the DOM would be overkill. If you think it’s necessary I don’t mind having documentation about our recommended way to set up MinGW on the wiki, but in general I think it’s the user’s responsibility to get a proper build environment set up. We should definitely include appropriate builds of the third party libs though.

I agree with you 100%, you mentioned adding a Make 3.81 binary and ditch the Visual Studio projects, thats why I mentioned fmt being missing from the “Current” MSYS distribution as well (“Current” MinGW Make is 3.79), I never intended to create a special MinGW package, though I do think the requirements and maybe some hints as to how to set them up should be on the Wiki.

I agree with you 100%, you mentioned adding a Make 3.81 binary and ditch the Visual Studio projects, thats why I mentioned fmt being missing from the “Current” MSYS distribution as well (“Current” MinGW Make is 3.79), I never intended to create a special MinGW package, though I do think the requirements and maybe some hints as to how to set them up should be on the Wiki.
Agreed on all counts.

I have to redo the DOM 2.0 packages because of problems with our Visual Studio libs (and a nasty crash discovered by a colleague at Intel). Maybe if we have MinGW support done in time we can include it with the DOM 2.0 re-release.

Steve

I think we can make it, right now I managed to get everything to compile and link, there is still the PCRE Issue, but it is a minor one.

I ran into this Boost bug, so we may want to upgrade to 1_35_0 after all, in any case I patched the header and its going to be on the patch I send you (I’ll provide you with binary libs as well in a separate package).

Other things to note:

1- There were a couple of classes missing their DLLSPEC tag, daeIDRefResolverList for instance, thats been corrected.

2- All tests pass except for rawSupport which crashes before completing, perhaps this is the bug you mentioned?

3- I haven’t build against tinyxml, but that one should be very easy.

The raw support test should pass unless you’re using the TinyXML plugin. I can look into it when I get the patch.

Alright, it works! :smiley:

I posted the patch at SourceForge,

You can get the external libs package from my website at http://www.aeongames.com/external-libs.tar.gz

I’m sure there will be questions, you can email me at x@y [x = kwizatz, y = aeongames.com] which is also my googletalk id if you need faster answers :).

Now I am off to bed.

Cheers!

Awesome news! I’m heading out now but I’ll definitely take a look tomorrow.

The trunk now has MinGW support. If you have a proper MinGW setup you should be able to check out the code and build the same way you would on Linux or Mac: just run ‘make’ in the DOM directory. See the make readme for more info about our make build.

To come back to the original poster’s question, you should now be able to use the DOM with Code::Blocks via MinGW just fine. I tested this myself last night by installing Code::Blocks and creating a simple app using the DOM. Everything worked fine. The only issue I had was that I could debug into DOM headers, but not into the DOM cpp files for some reason. I don’t think this is an issue with the DOM’s MinGW build though. Using gdb from the command line I could debug into the DOM just fine. I think I just don’t have Code::Blocks setup properly to find the DOM source files for debugging or something. I’ve never used Code::Blocks before so I really don’t know what I’m doing.

Special shout out to kwizatz for contributing the patch for MinGW support and offering tons of help getting some kinks worked out.

Steve