CMake project doesn't compile in Linux any more!

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Checkout the svn latest version, try to build from cmake project
2.
3.

What is the expected output? What do you see instead?
Problem 1:
.../opencollada-read-only/common/libBuffer/include/CommonBuffer.h:25:3: error: 
‘size_t’ does not name a type
Solution: add #include <stdlib.h> to the CommonBuffer.h

Problem 2:
/opencollada-read-only/common/libBuffer/src/CommonCharacterBuffer.cpp:18:24: 
fatal error: ConvertUTF.h: No such file or directory

Solution: add include path to UTF cmake
 - open ./Externals/UTF/CMakeLists.txt
 - add ${libUTF_include_dirs} global variable to INCLUDE_DIRECTORIES
 - open main CMakeLists.txt
 - change the order of subproject compilation, UTF should be before libBuffer. correct order: ADD_SUBDIRECTORY(${EXTERNAL_LIBRARIES}/UTF)
ADD_SUBDIRECTORY(${EXTERNAL_LIBRARIES}/MathMLSolver)
ADD_SUBDIRECTORY(common/libftoa)
ADD_SUBDIRECTORY(common/libBuffer)  

Problem 3:
In file included from 
/opencollada-read-only/common/libBuffer/src/CommonFWriteBufferFlusher.cpp:11:0:
/opencollada-read-only/common/libBuffer/include/CommonFWriteBufferFlusher.h:28:1
1: error: ‘__int64’ does not name a type

Solution:

add following string to the header:
#if (defined(__GNUC__) && !defined(__STRICT_ANSI__)) || (__STDC_VERSION__ >= 
199901L)
typedef int64_t __int64;
#endif

Problem 4:

/opencollada-read-only/common/libBuffer/include/CommonFWriteBufferFlusher.h:43:3
: error: ‘FILE’ does not name a type

Solution: add to the header #include <stdio.h>

Problem 5:

/opencollada-read-only/common/libBuffer/src/CommonFWriteBufferFlusher.cpp:24:27:
 error: ‘errno’ was not declared in this scope

Solution: add to cpp file #include <cerrno> 

Unresolved problems:

./opencollada-read-only/common/libBuffer/src/CommonFWriteBufferFlusher.cpp: In 
constructor ‘Common::FWriteBufferFlusher::FWriteBufferFlusher(const wchar_t*, 
size_t, const wchar_t*)’:
./opencollada-read-only/common/libBuffer/src/CommonFWriteBufferFlusher.cpp:41:37
: error: ‘_wfopen’ was not declared in this scope
./opencollada-read-only/common/libBuffer/src/CommonFWriteBufferFlusher.cpp: In 
member function ‘virtual void Common::FWriteBufferFlusher::startMark()’:
./opencollada-read-only/common/libBuffer/src/CommonFWriteBufferFlusher.cpp:86:42
: error: ‘_ftelli64’ was not declared in this scope
./opencollada-read-only/common/libBuffer/src/CommonFWriteBufferFlusher.cpp: In 
member function ‘virtual bool 
Common::FWriteBufferFlusher::jumpToMark(Common::IBufferFlusher::MarkId, 
bool)’:
./opencollada-read-only/common/libBuffer/src/CommonFWriteBufferFlusher.cpp:103:4
2: error: ‘_fseeki64’ was not declared in this scope
./opencollada-read-only/common/libBuffer/src/CommonFWriteBufferFlusher.cpp:115:5
3: error: ‘_fseeki64’ was not declared in this scope

What version of the product are you using? On what operating system?
The latest checkout. Ubuntu 11.04 32bits version

Original issue reported on code.google.com by Alexey.Z...@gmail.com on 8 Sep 2011 at 12:28

[GoogleCodeExporter]

As I just have read _wfopen is not supported in linux. So the quick and dirty 
solution could be to exclude this method if compiling in unix like systems.

#ifndef __unix__
    FWriteBufferFlusher::FWriteBufferFlusher( const wchar_t* fileName, size_t bufferSize, const wchar_t* mode/*=L"wb"*/ )
{
....
..
..
}
#endif

Original comment by Alexey.Z...@gmail.com on 8 Sep 2011 at 9:20

[GoogleCodeExporter]

_fseeki64
_ftelli64

could be replaced by fseek and ftell.

#ifdef __unix__
#define _FILE_OFFSET_BITS 64
#define _ftelli64 ftell
#define _fseeki64 fseek
typedef long off_t;
#endif

Original comment by Alexey.Z...@gmail.com on 8 Sep 2011 at 9:22

[GoogleCodeExporter]

after all these fixes the library finally has compiled. The question is how to 
check if it still works correct?

My code seems to work fine so far... 

Original comment by Alexey.Z...@gmail.com on 8 Sep 2011 at 9:24

[GoogleCodeExporter]

Looks like a good set of changes. I suggest you create a patch out of those and 
attach it to the issue. The CMake patch is necessary for all platforms.

Original comment by nathan.letwory on 9 Sep 2011 at 6:34

[GoogleCodeExporter]

ok. I will in a couple of days. 

Original comment by Alexey.Z...@gmail.com on 9 Sep 2011 at 6:37

[GoogleCodeExporter]

Here is my patch to fix CMake project. I checked it in Ubuntu 32,64, Mac 64 and 
Win 32.

Original comment by Alexey.Z...@gmail.com on 15 Sep 2011 at 9:06

Attachments:

• cross_compiling.patch

[GoogleCodeExporter]

Hi Alexey,
Just tried your patch here (debian64), it still gives me this error when 
compiling:
/home/yorik/Sources/collada/common/libBuffer/src/CommonCharacterBuffer.cpp:18:24
: fatal error: ConvertUTF.h: No such file or directory
Although both the Externals/UTF CMakeFile.txt and the main CMakeFile.txt 
contain the modifications listed in your first post... Not sure of the way to 
solve this... Any idea?
Thanks
Yorik

Original comment by yorik.va...@gmail.com on 16 Sep 2011 at 4:43

[GoogleCodeExporter]

probably I forgot something, let me check

Original comment by Alexey.Z...@gmail.com on 16 Sep 2011 at 5:26

[GoogleCodeExporter]

Dear Yorik,

Could you try this one? 
Everything should be fine this time.

Alexey

Original comment by Alexey.Z...@gmail.com on 16 Sep 2011 at 6:41

Attachments:

• cross_compiling_v2.patch

[GoogleCodeExporter]

V2 worked 100% perfect!  Thanks a lot!

Original comment by yorik.va...@gmail.com on 16 Sep 2011 at 8:14

[GoogleCodeExporter]

You are welcome! I hope it will be added to the new revision.

Original comment by Alexey.Z...@gmail.com on 16 Sep 2011 at 8:44

[GoogleCodeExporter]

testing now

Original comment by opencollada on 19 Sep 2011 at 7:00

• Changed state: Accepted

[GoogleCodeExporter]

How is testing going on? Are their any problems with the patch?

Original comment by Alexey.Z...@gmail.com on 2 Oct 2011 at 4:47

[GoogleCodeExporter]

Hi I got opencollada building before reading this, but think we found most of 
the same issues - try building r860.

The one remaining problem is "_wfopen", I read up on this and from what I can 
tell unix systems just don't use wchar_t for open commands, though if its 
important we could have our own _wfopen implimentation. For now I commented 
this function.

Original comment by ideasma...@gmail.com on 14 Oct 2011 at 12:05

• Changed state: Fixed

[GoogleCodeExporter]

That's correct there is no _wfopen for w_char.

In the patch above I used narrow to convert w_char to char in a controllable 
way. 

It compiles, thanks.

Original comment by Alexey.Z...@gmail.com on 14 Oct 2011 at 7:05