Issue 172 in opencollada: CMake project doesn't compile in Linux any more!
openc...@googlecode.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 172 by Alexey.Z...@gmail.com: CMake project doesn't compile in
Linux any more!
http://code.google.com/p/opencollada/issues/detail?id=172
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:11:
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:42:
error:
‘_fseeki64’ was not declared in this scope
./opencollada-read-only/common/libBuffer/src/CommonFWriteBufferFlusher.cpp:115:53:
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
openc...@googlecode.com
Comment #1 on issue 172 by Alexey.Z...@gmail.com: CMake project doesn't
http://code.google.com/p/opencollada/issues/detail?id=172
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
openc...@googlecode.com
Comment #2 on issue 172 by Alexey.Z...@gmail.com: CMake project doesn't
http://code.google.com/p/opencollada/issues/detail?id=172
_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
openc...@googlecode.com
Comment #3 on issue 172 by Alexey.Z...@gmail.com: CMake project doesn't
http://code.google.com/p/opencollada/issues/detail?id=172
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...
openc...@googlecode.com
Comment #4 on issue 172 by nathan.letwory: CMake project doesn't compile in
http://code.google.com/p/opencollada/issues/detail?id=172
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.
openc...@googlecode.com
Comment #5 on issue 172 by Alexey.Z...@gmail.com: CMake project doesn't
http://code.google.com/p/opencollada/issues/detail?id=172
ok. I will in a couple of days.
openc...@googlecode.com
Comment #6 on issue 172 by Alexey.Z...@gmail.com: CMake project doesn't
http://code.google.com/p/opencollada/issues/detail?id=172
Here is my patch to fix CMake project. I checked it in Ubuntu 32,64, Mac 64
and Win 32.
Attachments:
cross_compiling.patch 8.5 KB
openc...@googlecode.com
Comment #7 on issue 172 by yorik.va...@gmail.com: CMake project doesn't
http://code.google.com/p/opencollada/issues/detail?id=172
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
openc...@googlecode.com
Comment #8 on issue 172 by Alexey.Z...@gmail.com: CMake project doesn't
http://code.google.com/p/opencollada/issues/detail?id=172
probably I forgot something, let me check
openc...@googlecode.com
Comment #9 on issue 172 by Alexey.Z...@gmail.com: CMake project doesn't
http://code.google.com/p/opencollada/issues/detail?id=172
Dear Yorik,
Could you try this one?
Everything should be fine this time.
Alexey
Attachments:
cross_compiling_v2.patch 12.4 KB
openc...@googlecode.com
Comment #10 on issue 172 by yorik.va...@gmail.com: CMake project doesn't
http://code.google.com/p/opencollada/issues/detail?id=172
V2 worked 100% perfect! Thanks a lot!
openc...@googlecode.com
Comment #11 on issue 172 by Alexey.Z...@gmail.com: CMake project doesn't
http://code.google.com/p/opencollada/issues/detail?id=172
You are welcome! I hope it will be added to the new revision.
openc...@googlecode.com
Status: Accepted
Owner: opencollada
Comment #12 on issue 172 by opencollada: CMake project doesn't compile in
Linux any more!
http://code.google.com/p/opencollada/issues/detail?id=172
testing now
openc...@googlecode.com
Comment #13 on issue 172 by Alexey.Z...@gmail.com: CMake project doesn't
http://code.google.com/p/opencollada/issues/detail?id=172
How is testing going on? Are their any problems with the patch?
openc...@googlecode.com
Status: Fixed
Comment #14 on issue 172 by ideasma...@gmail.com: CMake project doesn't
compile in Linux any more!
http://code.google.com/p/opencollada/issues/detail?id=172
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.
openc...@googlecode.com
Comment #15 on issue 172 by Alexey.Z...@gmail.com: CMake project doesn't
http://code.google.com/p/opencollada/issues/detail?id=172
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.