reported at -> http://answers.ros.org/question/222892/collada-dom24-sp-dev-causes-dist-upgrade-to-fail-on-ubuntu-1404/

The following NEW packages will be installed:
  collada-dom-dev collada-dom2.4-sp-dev ros-indigo-collada-parser
  ros-indigo-collada-urdf ros-indigo-desktop ros-indigo-desktop-full
  ros-indigo-robot ros-indigo-robot-model ros-indigo-simulators


Unpacking collada-dom2.4-sp-dev (2.4.4.1-ubuntu1~trusty1) ...  dpkg:
error processing archive
/var/cache/apt/archives/collada-dom2.4-sp-dev_2.4.4.1-ubuntu1~trusty1_amd64.deb
(--unpack): trying to overwrite
'/usr/lib/cmake/collada_dom-2.4/collada_dom-config.cmake', which is also
in package collada-dom2.4-dp-dev 2.4.4.0-ubuntu1~trusty1 dpkg-deb:
error: subprocess paste was killed by signal (Broken pipe)

Following the instructions given, the "make" stage fails when building on Mac: functions such as fopen64 fail to compile.

The terminal output is:

/Development/Collada/collada-dom/dom/external-libs/minizip-1.1/ioapi.c:115:16: error: use of undeclared identifier 'Dfseeko64'; did you mean 'fseeko'?
file = fopen64((const char*)filename, mode_fopen);
^
:2:24: note: expanded from here

define fopen64 fopen -Dfseeko64=fseeko -Dfseek64=fseek -Dftell64=ftell -Dftello64=ftello

                   ^

/usr/include/stdio.h:418:6: note: 'fseeko' declared here
int fseeko(FILE , off_t, int);
^
/Development/Collada/collada-dom/dom/external-libs/minizip-1.1/ioapi.c:115:16: error: 'FILE *()(const char restrict, const char *restrict)' and
'int ()(FILE , off_t, int)' are not pointers to compatible types
file = fopen64((const char)filename, mode_fopen);
^~~~~~~
:2:23: note: expanded from here

define fopen64 fopen -Dfseeko64=fseeko -Dfseek64=fseek -Dftell64=ftell -Dftello64=ftello

            ~~~~~ ^~~~~~~~~~

/Development/Collada/collada-dom/dom/external-libs/minizip-1.1/ioapi.c:115:16: error: use of undeclared identifier 'Dfseek64'
:2:42: note: expanded from here

define fopen64 fopen -Dfseeko64=fseeko -Dfseek64=fseek -Dftell64=ftell -Dftello64=ftello

                                     ^

/Development/Collada/collada-dom/dom/external-libs/minizip-1.1/ioapi.c:115:16: error: use of undeclared identifier 'Dftell64'
:2:58: note: expanded from here

define fopen64 fopen -Dfseeko64=fseeko -Dfseek64=fseek -Dftell64=ftell -Dftello64=ftello

                                                     ^

/Development/Collada/collada-dom/dom/external-libs/minizip-1.1/ioapi.c:115:16: error: use of undeclared identifier 'Dftello64'; did you mean 'ftello'?
:2:74: note: expanded from here

define fopen64 fopen -Dfseeko64=fseeko -Dfseek64=fseek -Dftell64=ftell -Dftello64=ftello

                                                                     ^

/usr/include/stdio.h:419:8: note: 'ftello' declared here
off_t ftello(FILE );
^
/Development/Collada/collada-dom/dom/external-libs/minizip-1.1/ioapi.c:115:16: error: 'long ()(FILE )' and 'off_t ()(FILE )' are not pointers to
compatible types
file = fopen64((const char)filename, mode_fopen);
^~~~~~~
:2:73: note: expanded from here

define fopen64 fopen -Dfseeko64=fseeko -Dfseek64=fseek -Dftell64=ftell -Dftello64=ftello

                                                              ~~~~~ ^~~~~~~~~~

/Development/Collada/collada-dom/dom/external-libs/minizip-1.1/ioapi.c:115:47: error: too many arguments to function call, expected 1, have 2
file = fopen64((const char_)filename, mode_fopen);
~~~~~~~ ^~~~~~~~~~
/usr/include/stdio.h:419:1: note: 'ftello' declared here
off_t ftello(FILE *);
^
/Development/Collada/collada-dom/dom/external-libs/minizip-1.1/ioapi.c:145:11: warning: implicit declaration of function 'ftello64' is invalid in C99
[-Wimplicit-function-declaration]
ret = ftello64((FILE *)stream);
^
/Development/Collada/collada-dom/dom/external-libs/minizip-1.1/ioapi.c:191:8: warning: implicit declaration of function 'fseeko64' is invalid in C99
[-Wimplicit-function-declaration]
if(fseeko64((FILE *)stream, offset, fseek_origin) != 0)
^
2 warnings and 7 errors generated.
make[2]: *_* [dom/external-libs/minizip-1.1/CMakeFiles/minizip.dir/ioapi.c.o] Error 1
make[1]: *** [dom/external-libs/minizip-1.1/CMakeFiles/minizip.dir/all] Error 2
make: *** [all] Error 2

Note: the workaround I found is to add the following line at the top of ioapi.h:

define USE_FILE32API

With that workaround, I get many annoying macro redefined warnings, but no error.

The cmake instructions don't work on my Windows XP/Visual Studio 2008 VM. AS I am not a Windows programmer, I'm really at loss about what is going wrong and how I can fix it.

Here is the output of "cmake ..":

C:\Documents and Settings\Administrateur\Mes documents\Downloads\collada-dom-mas
ter\build>cmake ..
-- Compiling Collada DOM Version 2.4.1
-- Using cmake version 2.8
-- installing to C:/Program Files/collada-dom
-- compiling with double float precision
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
CMake Error at C:/Program Files/CMake 2.8/share/cmake-.8/Modules/FindBoost.cmake:1106 (message):
Unable to find the requested Boost libraries.

Boost version: 1.53.0

Boost include path:
C:/Dev/Safari/KleeCommerce50/Idc/Outils/boost/boost_current

The following Boost libraries could not be found:

      boost_filesystem
      boost_system

No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the
directory containing Boost libraries or BOOST_ROOT to the location of
Boost.
Call Stack (most recent call first):
CMakeLists.txt:155 (find_package)

-- found boost version: 105300
-- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
-- compiling zlib from souces and linking statically
-- Could NOT find LibXml2 (missing: LIBXML2_LIBRARIES LIBXML2_INCLUDE_DIR)
-- compiling minizip from sources and linking statically
-- System pcre not found, using local from sources
-- Could NOT find BZip2 (missing: BZIP2_LIBRARIES BZIP2_INCLUDE_DIR)
-- Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.5")
-- Could not find OPTIONAL package Readline
-- Configuring incomplete, errors occurred!

Which of those messages are actual errors? Is PkgConfig needed? I researched how to install it without CygWin of MingW, and found nothing.

Note also that it says that it found Boost 1.53 at the stated location. That's correct. However, at this point, I would rather it uses Boost 1.54 found at the more usual location in program files. Here is the env variable:

BOOST_ROOT=C:\Program Files\boost\boost_1_54_0

Then there are the missing stuff it complains about. How am I supposed to install those? Should I research them one by one?

Thanks for any suggestion. I feel lost.

Hi, I am using colladadom to read dae files, I have built it only with collada14dom option, and the environment is Visual Studio2015 under windows, I have used multithreads to read different files, while encounter "this-> _type is nullptr" at

my test codes are simple:
`#include "stdafx.h"

include thread

include "dae.h"

include vector

static void test(int i)
{
if (0==i)
{
DAE dae; dae.open("a.dae");
}
else
{
DAE dae1; dae1.open("b.dae");
}
}

using namespace std;
int main()
{
vector tests;
for (int i=0;i<2;i++)
{
tests.push_back(thread(test,i));
}

for (auto & k:tests)
{
    k.join();
}
return 0;

}`
Could you give me some advises about how could I properly use colladadom in multithreads ?

Till now, the debian package is built using libpcre3-dev. There's a mass bug about dropping that package because of several reasons.

Checking the CMakeLists I have found that collada-dom can be built with liburiparser. I have built it with the last one and pcre2.

Has Upstream any preference of the library to use?

Build of daeElements.cpp crashes due to lack of "#include <algorithm>".
The build didn't crash before because this include was indirectly included through boost, using this path:
src/dae/daeElement.cpp
include/dae/daeDatabase.h
include/dae.h
boost/filesystem/convenience.hpp
boost/filesystem/operations.hpp
boost/filesystem/path.hpp
algorithm
Problem is that between boost 1.76 and 1.77 this include in path.hpp has been suppressed. Adding it in daeElements.cpp corrects the problem.

I'm trying to build collada-dom current git, and I specify the following two options:

 OPT_COLLADA14                    OFF                                                                                                                                                                        
 OPT_COLLADA15                    ON

However, it seems it always looks for COLLADA_DOM_USING_141, which is really out of my expectation.... I obtained the following error messages:

.../openrave/collada-dom/dom/include/dae/daeTypes.h:64:17: error: ‘ColladaDOM141’ is not a namespace-name
 using namespace ColladaDOM141;

and the piece of code is :

#if defined(COLLADA_DOM_SUPPORT150)
namespace ColladaDOM150 {}
#endif
#if defined(COLLADA_DOM_SUPPORT141)
namespace ColladaDOM141 {}
#endif

Can't I undef "COLLADA_DOM_SUPPORT141" in CMakeLists.txt?

I tried to add
set(COLLADA_DOM_USING_141 false)
in CMakeListst.txt, but still got the same error message...

It looks thie ONLY way is to add
#undef COLLADA_DOM_USING_141
in all header files???

Unbelievable...

Cheers
Pei

Hi,

I'm using collada-dom based application on 12.04 and 13.04. but only 13.04 fails with Trying to load an invalid COLLADA version for this DOM build Do you have any thought on this?

here is how you reproduce this.

$ rosparam set /robot_description -t `rospack find nextage_description`/models/main.dae # https://github.com/tork-a/rtmros_nextage/tree/hydro-devel/nextage_description/models

$ rosrun robot_state_publisher state_publisher
[ERROR] [1405529535.299984046]: COLLADA error: Trying to load an invalid COLLADA version for this DOM build!
[ERROR] [1405529535.343770418]: COLLADA error: Failed to load XML document from memory
[ERROR] [1405529535.356754079]: Could not generate robot model
[ERROR] [1405529535.360128130]: Failed to extract kdl tree from xml robot description

but on 12.04, state_publisher works

but collada_to_urdf works and this is also uses openFromMemory function https://github.com/ros/robot_model/blob/indigo-devel/collada_parser/src/collada_parser.cpp#L444 via
https://github.com/ros/robot_model/blob/indigo-devel/collada_urdf/src/collada_to_urdf.cpp#L674

$ rosrun collada_urdf collada_to_urdf main.dae 
;; Input file is: main.dae
[ WARN] [1405531921.704972653]: COLLADA warning: The DOM was unable to create an element named copyright at line 10. Probably a schema violation.
[ERROR] [1405531921.906564327]: Target Node visual1/node_joint0_axis0 NOT found!!!
[ WARN] [1405531921.922642311]: could not find binding for axis: kmodel1/jointsid1000/axis0, axis0
[ WARN] [1405531921.927932124]: could not find binding for axis: kmodel1/jointsid1000/axis0, axis0

Build with Boost 1.85.0 fails and outputs errors like:

In file included from /tmp/collada-dom-20240425-5735-4akd4c/collada-dom-2.5.0/dom/src/1.5/dom/domAnimation.cpp:1:
/tmp/collada-dom-20240425-5735-4akd4c/collada-dom-2.5.0/dom/include/dae.h:28:10: fatal error: 'boost/filesystem/convenience.hpp' file not found
#include <boost/filesystem/convenience.hpp>
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is due to removal of convenience.hpp (https://www.boost.org/doc/libs/1_85_0/libs/filesystem/doc/deprecated.html). The includes need to be updated depending on what functions/etc are needed.

EDIT: Also need to update some removed APIs, e.g.

/tmp/collada-dom-20240425-12463-zjold7/collada-dom-2.5.0/dom/src/dae/daeZAEUncompressHandler.cpp:274:35: error: no member named 'branch_path' in 'boost::filesystem::path'
    std::string dir = archivePath.branch_path().string();
                      ~~~~~~~~~~~ ^
1 error generated.

Seen while updating Boost in Homebrew - Homebrew/homebrew-core#169237

So it seems like 2.5 is already released but not tagged as a release, as already mentioned in rdiankov/openrave#428.

Can you please add a tag? This allows me to update the Fedora package without modifying the release scripts, which expect properly tagged releases.

Also, I get automatic notifications for tagged releases, so even if it looks like a technical detail, they are actually very useful for downstream packaging.

Thanks!

The releases page for this project shows releases for 2.4.2, 2.4.3, and 2.4.4. But these versions aren't present on the SourceForge page. Are these official releases of the project suitable for production use?

And is this project here on GitHub a fork of the original SourceForge project, or is this where new development on the same project is happening? I'm not sure what "very lightweight version" (in the README) means.

(See ros/robot_model#203)

During ROS install, Ubuntu reported a system problem:

Package: libcollida-dom2.4-do0 2.4.4+ds1-1.
collida-dom
"An Ubuntu package has a file conflict with a package that is not a genuine Ubuntu package".

At the end of the ROS install, that install reported:

Errors were encountered while processing:
/var/cache/apt/archives/libcollada-dom2.4-dp0_2.4.4+ds1-1_amd64.deb
/var/cache/apt/archives/libcollada-dom2.4-dp-dev_2.4.4+ds1-1_amd64.deb

That bug was in ROS-Indigo for Ubuntu 14.04. It was fixed there. Looks like it's been broken again.
See robot-model Issue 118 from 2015, where this issue appeared with Ubuntu 14.04: ros/robot_model#118

See also: http://answers.ros.org/question/222892/collada-dom24-sp-dev-causes-dist-upgrade-to-fail-on-ubuntu-1404/

See also: http://answers.ros.org/question/222892/collada-dom24-sp-dev-causes-dist-upgrade-to-fail-on-ubuntu-1404/

The source for this software has a large number of files which have mixed dos and unix linefeeds, which whilst mostly harmless is definitely wrong. Most of the problem is that the licence header has DOS lineends, whilst the rest of the file is unix (although not in every file for some reason). But there are also files when edits such as new functions or lines have been added with DOS lineends, presumably by someone using an editor too stupid to get it right.

Attached is a patch to fix them all up.

There are also some files which are entirely DOS lineends, which is OK, but it might make sense to make the whole codebase consistent, which is a trivial matter of running
find . -type f | xargs dos2unix
It is possible that there is a good reason for some of the test xml files to have DOS lineends(?), in which case leave them alone.

Hmm. this issue tracker doesn't allow attaching patches. The file is here: http://anonscm.debian.org/cgit/debian-science/packages/collada-dom.git/diff/debian/patches/linefeed-fixup.patch?id=9652330772f7e441b423a41d88f52c245569c049

This is a duplicate of https://sourceforge.net/p/collada-dom/bugs/160/

domNode->getAttribute returns strings cut by the first whitespace, this prevents naming bones with whitespaces, e.g name="Left Hand" will be returned only as "Left".

This happens when using OpenSceneGraph, the code calling domNode is at https://github.com/openscenegraph/OpenSceneGraph/blob/OpenSceneGraph-3.6/src/osgPlugins/dae/daeRSkinning.cpp#L258 .

I also filed a bug against OSG, but I believe the issue currently lies at ColladaDOM. openscenegraph/OpenSceneGraph#1016

Due to stricter type checking, collada-dom fails to build with GCC 6.0:

/builddir/build/BUILD/collada-dom-2.4.4/dom/src/dae/daeMetaGroup.cpp:29:10: error: cannot convert 'bool' to 'daeElement*' in return
   return false;
          ^~~~~

It looks like the new GCC release does not allow implicit type conversions of this kind anymore.

The bug was found during a Fedora mass rebuild for Fedora 24. See RedHat Bugzilla and the Full build log for details.

Almost all the test files are under a non-free licence (Creative Commons Attribution Noncommercial Share Alike) and so cannot be shipped in distributions such as Debian. (It's the 'NonCommercial' that makes it non-free). I don't know how useful these test files are, but if they are useful it would be good to ask upstream if they could re-licence them under a properly free licence. I can't believe that avoiding non-commercial use of these files is very important to the originators anymore. I have a contact at Sony if you don't know who to ask.

Currently the only files we can ship are duck.cstm and duck.dae.gz. Maybe texture.bmp - the licence of that is unclear. Do we know where it came from? Is it actually part of one of the other testcases?

I finally built Collada-DOM successfully on Windows (Windows XP using Visual Studio 2008). The only caveat was that there is no "make" under Windows. I had to open the Visual Studio project and build it.

Now I create a new VC++ 2008 project, with the trivial program:

#include <iostream>
#include <dae.h>
#include <dom/domCOLLADA.h>
int main()
{
std::cout << "Hellow World" << std::endl;

DAE* dae = new DAE; // no issue without this line.
}

And I get R6034 runtime error. I google for that, which suggested an error about some manifest, but I checked the manifest settings which conform to what I found on the net.

The loading process produces the following output, which may or may not be useful:

'DOMtest.exe': Loaded 'C:\Documents and Settings\Administrateur\Mes documents\Visual Studio 2008\Projects\DOMtest\Debug\DOMtest.exe', Symbols loaded.
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll'
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll'
'DOMtest.exe': Loaded 'C:\Documents and Settings\Administrateur\Mes documents\Visual Studio 2008\Projects\DOMtest\Debug\collada-dom2.4-dp-vc90-mt.dll', Symbols loaded.
'DOMtest.exe': Loaded 'C:\Documents and Settings\Administrateur\Mes documents\Visual Studio 2008\Projects\DOMtest\Debug\boost_filesystem-vc90-mt-gd-1_53.dll'
'DOMtest.exe': Loaded 'C:\Documents and Settings\Administrateur\Mes documents\Visual Studio 2008\Projects\DOMtest\Debug\boost_system-vc90-mt-gd-1_53.dll'
'DOMtest.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.6161_x-ww_ba947f24\msvcp90d.dll', Symbols loaded.
'DOMtest.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.6161_x-ww_ba947f24\msvcr90d.dll', Symbols loaded.
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll'
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll'
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\secur32.dll'
'DOMtest.exe': Loaded 'C:\Documents and Settings\Administrateur\Mes documents\Visual Studio 2008\Projects\DOMtest\Debug\libxml2-vc90-mt.dll', Binary was not built with debug information.
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\wsock32.dll'
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\ws2_32.dll'
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll'
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\ws2help.dll'
'DOMtest.exe': Loaded 'C:\Program Files\CMake 2.8\bin\msvcr90.dll'
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\user32.dll'
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll'
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\imm32.dll'
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\MSCTF.dll'
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\MSCTFIME.IME'
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\ole32.dll'
'DOMtest.exe': Loaded 'C:\WINDOWS\system32\version.dll'
'DOMtest.exe': Unloaded 'C:\WINDOWS\system32\version.dll'
First-chance exception at 0x7c9773be in DOMtest.exe: 0xC0000142: DLL Initialization Failed.
Unhandled exception at 0x7c9773be in DOMtest.exe: 0xC0000142: DLL Initialization Failed.
The program '[3916] DOMtest.exe: Native' has exited with code 0 (0x0).

I also copied whatever DLL Visual Studio complained about at launch time. The app directory (set to be the current directory), contains:

/tmp/VMwareDnD/c0f75fe3/DOMtest.exe
/tmp/VMwareDnD/c0f75fe3/DOMtest.ilk
/tmp/VMwareDnD/c0f75fe3/DOMtest.pdb
/tmp/VMwareDnD/c0f75fe3/collada-dom2.4-dp-vc90-mt.dll
/tmp/VMwareDnD/c0f75fe3/boost_filesystem-vc90-mt-gd-1_53.dll
/tmp/VMwareDnD/c0f75fe3/boost_system-vc90-mt-gd-1_53.dll
/tmp/VMwareDnD/c0f75fe3/libxml2-vc90-mt.dll

Perhaps I did something stupid which could explain that. I am a Windows noob.

Thanks if you have an idea.

Attempting to port my code to collada-dom 2.4.2, I discovered that dae.open now always returns NULL.

Looking at the code, it appears the issue happens here:

domCOLLADAProxy* DAE::openCommon(const string& path, daeString buffer) {
close(path);
string uri = makeFullUri(path);
plugin->setDatabase(database);
if (plugin->read(daeURI(*this, uri.c_str()), buffer) != DAE_OK)
return NULL;
return getRoot(uri);
}

the return NULL in the if statement is being triggered. That appears to come from here:

daeInt daeIOPluginCommon::read(const daeURI& uri, daeString docBuffer)
{
// Make sure topMeta has been set before proceeding
if (topMeta == NULL)
{
return DAE_ERR_BACKEND_IO;
}

snip

The topMeta variable should be populated by the owning DAE object at DAE::setIOPlugin on this line:

int res = plugin->setMeta(getMeta(getDomCOLLADAID()));

The nested getDomCOLLADAID call is to this code:

daeInt getDomCOLLADAID(const char* specversion)
{

ifdef COLLADA_DOM_SUPPORT150

if( specversion == NULL || strcmp(specversion,"1.5.0") == 0 ) {
    return ColladaDOM150::domCOLLADA::ID();
}

endif

ifdef COLLADA_DOM_SUPPORT141

if( specversion == NULL || strcmp(specversion,"1.4.1") == 0 ) {
    return ColladaDOM141::domCOLLADA::ID();
}

endif

return NULL;

}

You'll note we expect a specversion argument but have none passed, so we'll always return the version 150 ID it seems.

I'm having problems using this library with C++20. It seems to use std::auto_ptr which to my knowledge isn't available in C++17 or 20. Am I missing something or is this library only designed for use with C++14 or older?

I have after quite much effort managed to build the Openrave github master branch - linking the collada-dom github build on a Windows 7 64 bit machine under Visual Studio 2010.

When running the tutorial_ik5d example, I get the following output and python crashes:

openrave.py --example tutorial_ik5d

[colladareader.cpp:110 OpenRAVE::ColladaReader::daeOpenRAVEURIResolver::resolveElement] daeOpenRAVEURIResolver::resolveElement() - Failed to resolve C:\Users\pshustad\AppData\Local\Temp\087e-e302-2a3f-ddd7\./neuronics-katana.dae#vscene 
[colladareader.cpp:3385 OpenRAVE::ColladaReader::handleError] COLLADA error: daeStandardURIResolver::resolveElement() - Failed to resolve C:\Users\pshustad\AppData\Local\Temp\087e-e302-2a3f-ddd7\./neuronics-katana.dae#vscene
DOC: C:\Users\pshustad\AppData\Local\Temp\087e-e302-2a3f-ddd7\./neuronics-katana.daescheme openrave
[colladareader.cpp:110 OpenRAVE::ColladaReader::daeOpenRAVEURIResolver::resolveElement] daeOpenRAVEURIResolver::resolveElement() - Failed to resolve C:\Users\pshustad\AppData\Local\Temp\087e-e302-2a3f-ddd7\./neuronics-katana.dae#kscene 
[colladareader.cpp:3385 OpenRAVE::ColladaReader::handleError] COLLADA error: daeStandardURIResolver::resolveElement() - Failed to resolve C:\Users\pshustad\AppData\Local\Temp\087e-e302-2a3f-ddd7\./neuronics-katana.dae#kscene
[environment-core.h:475 Environment::Load] load failed on file data/katanatable.env.xml
...

Note the strange looking URI, i.e. the \./neuronics-katana.dae#vscene fragment.

I tried to ask cmake to generate an Xcode project. Everything went fine:

cmake -G Xcode ..
-- The C compiler identification is Clang 5.0.0
-- The CXX compiler identification is Clang 5.0.0
-- Check for working C compiler using: Xcode
-- Check for working C compiler using: Xcode -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Xcode
-- Check for working CXX compiler using: Xcode -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Compiling Collada DOM Version 2.4.1
-- Using cmake version 2.8
-- installing to /usr/local
-- compiling with double float precision
-- Found PkgConfig: /usr/local/bin/pkg-config (found version "0.28")
-- Boost version: 1.54.0
-- Found the following Boost libraries:
-- filesystem
-- system
-- found boost version: 105400
-- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.5")
-- Found LibXml2: /usr/lib/libxml2.dylib (found version "2.7.8")
-- libxml2 found
-- checking for module 'minizip'
-- package 'minizip' not found
-- compiling minizip from sources and linking statically
-- checking for module 'libpcrecpp'
-- found libpcrecpp, version 8.32
-- Looking for C++ include pcrecpp.h
-- Looking for C++ include pcrecpp.h - found
-- Configuring done
-- Generating done
-- Build files have been written to: /Development/Collada/collada-dom/buildx

However, the resulting Xcode project really fails to build (as opposed to the generic "make" based output of cmake).

The failure happens at link time when building the collada-dom target:

Undefined symbols for architecture x86_64:
"pcrecpp::RE::Init(std::__1::basic_string<char, std::__1::char_traits, std::1::allocator > const&, pcrecpp::RE_Options const)", referenced from:
pcrecpp::RE::RE(char const) in daeURI.o

I tried to build this in visual studio 2017. The FindBoost.Cmake module can't seem to find boost properly. By default it is searching:

Searching for FILESYSTEM_LIBRARY_RELEASE: boost_filesystem-mgw-mt-;boost_filesystem-mgw-mt;boost_filesystem-mt-;boost_filesystem-mt;boost_filesystem
Searching for FILESYSTEM_LIBRARY_DEBUG: boost_filesystem-mgw-mt-d-;boost_filesystem-mgw-mt-d;boost_filesystem-mt-d-;boost_filesystem-mt-d;boost_filesystem-mt;boost_filesystem
Searching for SYSTEM_LIBRARY_RELEASE: boost_system-mgw-mt-;boost_system-mgw-mt;boost_system-mt-;boost_system-mt;boost_system
Searching for SYSTEM_LIBRARY_DEBUG: boost_system-mgw-mt-d-;boost_system-mgw-mt-d;boost_system-mt-d-;boost_system-mt-d;boost_system-mt;boost_system

It's a bit sad that all previous history was lost in the fork process.

What about using git svn in order to populate you github fork with the svn history. I did it in the past and it worked surprisingly well (see https://github.com/sbarthelemy/collada-dom).

Please tell me if I can be of any help.

Regards