Re: [CMake] static libs and more

[David Cole]

On Thu, Jul 17, 2008 at 7:48 PM, Philip Lowman <[EMAIL PROTECTED]> wrote:

Does anyone know of any other platforms that share filename extensions for
> archive vs. shared libraries other than MSVC/Win32?
>

The .lib files associated with DLLs on Windows are not really "shared
libraries". The DLLs themselves are the shared libraries. The .lib files are
just directives to the linker that say how to resolve to the DLL. They are
sort of mini-archives with a bunch of "function pointers," if you will, in
them instead of object code. The object code is in the DLL and the .lib file
points to it.

The .lib tells the linker that when it links a program against any
"functions" in it, that the built executable must be able to load the
corresponding DLL when it loads to resolve those functions.

Having said all this, yeah, it's not pretty..., but it's the way it is
because of the way it was...

And I am not aware of any other platforms that share filename extensions for
archive vs. shared libraries.


;)
David
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] static libs and more

[Philip Lowman]

On Thu, Jul 17, 2008 at 6:25 PM, Alin M Elena <[EMAIL PROTECTED]> wrote:

>  Hi All,
>
> I do not really think is any need to test if the lib is static or dynamic.
> In real life you should already now that.
>
> Let us take as an example a package XXX we know from documentation that
> provides a static link libA.lib and a dynamic link libB.lib (windows case).
>
> i want to write a module findXXX.cmake that I can use in a find_package
> command,
>
> if I want a dynamic link i can use
>
> find_package(XXX)
>
> if I want static
>
> find_package(XXX USE_STATIC)
>
> somewhere inside I will have
>
> if (USE_STATIC)
>
> give me libA.lib
>
> else
>
> give me libB.lib
>
> endif
>
> So, in my line of thoughts there is no need to test the nature of the two
> libs. I assume their nature based on the documentation.
>

This is true, if you're willing to add the logic to every CMake module to
support this.

I think a better approach might be to start at the find_library() level and
add a USE_STATIC and USE_SHARED option to find_library() which would enforce
the selection of libraries.  This way you could list both the static and
shared form of the library name on the same FIND_LIBRARY() call and the user
would have ultimate control over which to pick without resorting to having
to add two FIND_LIBRARY calls in every module where there are now only one.

After this is done the FIND_PACKAGE interface could be modified probably
also with a USE_STATIC or USE_SHARED that would simply be passed to
FIND_LIBRARY.

Does anyone know of any other platforms that share filename extensions for
archive vs. shared libraries other than MSVC/Win32?

-- 
Philip Lowman
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] static libs and more

[clinton]

I also noticed that dumpbin /exports mylib.lib printed symbols out if it was 
an import library, but didn't if it was a static library.

Clint

On Thursday 17 July 2008 3:03:02 pm David Cole wrote:
> If you do...:
> dumpbin /symbols mylib.lib
>
> ...then:
> The output will contain "_IMPORT_DESCRIPTOR" if the .lib is an import
> library for a .dll file.
> It will (most likely) not contain this output if it is a static .lib file.
>
> It's a heuristic as I'm pretty sure the static .lib file will contain that
> output if you have, for example, a function named "PRINT_IMPORT_DESCRIPTOR"
> in your library... But the absence of that string tells you that it is
> *not* an import library for a .dll.
>
> You could easily write a CMake macro that calls dumpbin with
> EXECUTE_PROCESS and capture its output into a variable and analyze it.
>
> (dumpbin.exe is usually available in the "VC\bin" directory of a Visual
> Studio installation... easily accessible from a VC command prompt...)
>
>
> HTH,
> David
>
> On Thu, Jul 17, 2008 at 4:09 PM, Philip Lowman <[EMAIL PROTECTED]> wrote:
> > .. Original Message ...
> > On Thu, 17 Jul 2008 22:10:11 +0400 "Yuri Timenkov"
> >
> > <[EMAIL PROTECTED]> wrote:
> > >On Thursday 17 July 2008 23:00:15 Alin M Elena wrote:
> > >The main problem AFAIK for VS is that static and dynamic libraries are
> > >indistinguishable by extension. They both have a .lib one. And you don't
> >
> > know
> >
> > >in advance is some library is static one or just import library for some
> > >dynamic one.
> >
> > I would be quite frankly amazed if someone couldn't write a 10-line CMake
> > macro that can determine if a .LIB file is static or shared.  I wonder if
> > simply keying on certain ASCII keywords in the .LIB file wouldn't be good
> > enough (this would need some testing though, unless someone can find a
> > detailed .LIB file specification).
> >
> > --
> > Philip Lowman
> > ___
> > CMake mailing list
> > CMake@cmake.org
> > http://www.cmake.org/mailman/listinfo/cmake


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] static libs and more

[Alin M Elena]

Hi All,

I do not really think is any need to test if the lib is static or dynamic. In 
real life you should already now that.

Let us take as an example a package XXX we know from documentation that 
provides a static link libA.lib and a dynamic link libB.lib (windows case).

i want to write a module findXXX.cmake that I can use in a find_package command,

if I want a dynamic link i can use
find_package(XXX)
if I want static
find_package(XXX USE_STATIC)

somewhere inside I will have

if (USE_STATIC)
  give me libA.lib
else
 give me libB.lib
endif

So, in my line of thoughts there is no need to test the nature of the two 
libs. I assume their nature based on the documentation.

Alin

-- 
__ 
 "...if the universities will not study useless subjects, who will?" 
   G. F. Fitzgerald, Nature, 45/46, 392 (1892)
__
Mr. Alin M. ELENA
Atomistic Simulation Centre
School of Mathematics and Physics
Queen's University Belfast
Office: +44 (0)28 9097 1428
Fax: +44 (0)28 9097 5359
http://titus.phy.qub.ac.uk/group/Alin/
[EMAIL PROTECTED] 
[EMAIL PROTECTED]
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FindThreads and Fortran

[Alexander Neundorf]

On Thursday 17 July 2008, Alin M Elena wrote:
> Hi,
>
> I try to determine the correct -lpthread against which I link in a Fortran
> project. (http://code.google.com/p/tdtbuj)
> using only
> find_package(Threads)
> leads to an error
> -- Looking for include files CMAKE_HAVE_PTHREAD_H
> CMake Error: Unknown extension ".c" for file

FindThreads.cmake does the following:
 CHECK_INCLUDE_FILES("pthread.h" CMAKE_HAVE_PTHREAD_H)

This requires a working C compiler. I think most Find-modules for libraries 
expect to find the library for use with C/C++. How much trouble is it for you 
to require a C compiler on the machines where your app will be built ?
There is probably good reason why for the header is checked. Maybe not on all 
systems there is a separate libpthread.so, but the  header must be always 
there.
Ok, one could also do a FIND_FILE() for pthread.h. This wouldn't test whether 
it actually works. I don't know how important such a check actually is.
You could try it on your installation and let us know how it works.

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake works only with --debug-trycompile

[Alexander Neundorf]

On Thursday 17 July 2008, Alin M Elena wrote:
> Hi,
>
> I have a small project
> http://code.google.com/p/tdtbuj
>
> cmake is the build system.
>
> in linux
> if I do just cmake it fails to find the proper libs.

Please give more details so we can help.

> if I do cmake cmake --debug-trycompile will work (sometimes).

Don't do that. With debug-trycompile the temporary results from trycompiles 
are not deleted, so you may get weird results in the tests.

alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake distcc

[Alexander Neundorf]

On Thursday 17 July 2008, Vandenbroucke Sander wrote:
> Hi,
...
> Compiling is fine, distcc does it's job. Unfortunately my linker command
> is messed up. CMake used to generate something like this: nios2-elf-g++
> OBJECTS -lsystem ...
>
> With distcc this changes to: nios2-elf-g++  OBJECTS -lsystem.lib ...
> Ofcource there are no .lib libraries in my project...

You are using the native windows cmake, not the cygwin cmake, right ?
How do you add the "system" library ? Using TARGET_LINK_LIBRARIES() or via the 
link rule variable ?
Maybe cygwin distcc does something different which makes cmake think the 
current windows toolchain needs the ".lib" suffix ?

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] static libs and more

[David Cole]

If you do...:
dumpbin /symbols mylib.lib

...then:
The output will contain "_IMPORT_DESCRIPTOR" if the .lib is an import
library for a .dll file.
It will (most likely) not contain this output if it is a static .lib file.

It's a heuristic as I'm pretty sure the static .lib file will contain that
output if you have, for example, a function named "PRINT_IMPORT_DESCRIPTOR"
in your library... But the absence of that string tells you that it is *not*
an import library for a .dll.

You could easily write a CMake macro that calls dumpbin with EXECUTE_PROCESS
and capture its output into a variable and analyze it.

(dumpbin.exe is usually available in the "VC\bin" directory of a Visual
Studio installation... easily accessible from a VC command prompt...)


HTH,
David


On Thu, Jul 17, 2008 at 4:09 PM, Philip Lowman <[EMAIL PROTECTED]> wrote:

>
>
>
> .. Original Message ...
> On Thu, 17 Jul 2008 22:10:11 +0400 "Yuri Timenkov"
> <[EMAIL PROTECTED]> wrote:
> >On Thursday 17 July 2008 23:00:15 Alin M Elena wrote:
> >The main problem AFAIK for VS is that static and dynamic libraries are
> >indistinguishable by extension. They both have a .lib one. And you don't
> know
> >in advance is some library is static one or just import library for some
> >dynamic one.
>
> I would be quite frankly amazed if someone couldn't write a 10-line CMake
> macro that can determine if a .LIB file is static or shared.  I wonder if
> simply keying on certain ASCII keywords in the .LIB file wouldn't be good
> enough (this would need some testing though, unless someone can find a
> detailed .LIB file specification).
>
> --
> Philip Lowman
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] static libs and more

[David Cole]

If you do...:
dumpbin /symbols mylib.lib

...then:
The output will contain "_IMPORT_DESCRIPTOR" if the .lib is an import
library for a .dll file.
It will (most likely) not contain this output if it is a static .lib file.

It's a heuristic as I'm pretty sure the static .lib file will contain that
output if you have, for example, a function named "PRINT_IMPORT_DESCRIPTOR"
in your library... But the absence of that string tells you that it is *not*
an import library for a .dll.

You could easily write a CMake macro that calls dumpbin with EXECUTE_PROCESS
and capture its output into a variable and analyze it.

(dumpbin.exe is usually available in the "VC\bin" directory of a Visual
Studio installation... easily accessible from a VC command prompt...)


HTH,
David


On Thu, Jul 17, 2008 at 4:09 PM, Philip Lowman <[EMAIL PROTECTED]> wrote:

>
>
>
> .. Original Message ...
> On Thu, 17 Jul 2008 22:10:11 +0400 "Yuri Timenkov"
> <[EMAIL PROTECTED]> wrote:
> >On Thursday 17 July 2008 23:00:15 Alin M Elena wrote:
> >The main problem AFAIK for VS is that static and dynamic libraries are
> >indistinguishable by extension. They both have a .lib one. And you don't
> know
> >in advance is some library is static one or just import library for some
> >dynamic one.
>
> I would be quite frankly amazed if someone couldn't write a 10-line CMake
> macro that can determine if a .LIB file is static or shared.  I wonder if
> simply keying on certain ASCII keywords in the .LIB file wouldn't be good
> enough (this would need some testing though, unless someone can find a
> detailed .LIB file specification).
>
> --
> Philip Lowman
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] static libs and more

[Philip Lowman]

.. Original Message ...
On Thu, 17 Jul 2008 22:10:11 +0400 "Yuri Timenkov" 
<[EMAIL PROTECTED]> wrote:
>On Thursday 17 July 2008 23:00:15 Alin M Elena wrote:
>The main problem AFAIK for VS is that static and dynamic libraries are 
>indistinguishable by extension. They both have a .lib one. And you don't 
know 
>in advance is some library is static one or just import library for some 
>dynamic one.

I would be quite frankly amazed if someone couldn't write a 10-line CMake 
macro that can determine if a .LIB file is static or shared.  I wonder if 
simply keying on certain ASCII keywords in the .LIB file wouldn't be good 
enough (this would need some testing though, unless someone can find a 
detailed .LIB file specification).

-- 
Philip Lowman
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] static libs and more

[Alin M Elena]

Hi,


> The main problem AFAIK for VS is that static and dynamic libraries are
> indistinguishable by extension. They both have a .lib one. And you don't
> know in advance is some library is static one or just import library for
> some dynamic one.
>
> For cygwin/mingw things may be more similar to Unix.
I do not really see the problem. They will have the same extension (*.lib) but 
they will have different names. The FindXXX.cmake is written by hand with in 
advance knowledge about the structure of the libs.

Alin

-- 
__ 
 "...if the universities will not study useless subjects, who will?" 
   G. F. Fitzgerald, Nature, 45/46, 392 (1892)
__
Mr. Alin M. ELENA
Atomistic Simulation Centre
School of Mathematics and Physics
Queen's University Belfast
Office: +44 (0)28 9097 1428
Fax: +44 (0)28 9097 5359
http://titus.phy.qub.ac.uk/group/Alin/
[EMAIL PROTECTED] 
[EMAIL PROTECTED]
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] static libs and more

[Yuri Timenkov]

On Thursday 17 July 2008 23:00:15 Alin M Elena wrote:
> Hi,
>
> 1. Few days ago maybe weeks on the list I have seen a discussion about
> static/dynamic linking.
>
> One of the solution proposed there to achieve a static linking was
>
> if (UNIX)
>   set(CMAKE_FIND_LIBRARY_SUFFIXES ".a;.so")
> endif(UNIX)
> Something similar can be done for windows I suspect.
>
> Maybe you can add an extra argument to find_package(... USE_STATIC)
> and internally in FindXXX.cmake to use it to find the correct linkage. Just
> an idea.
The main problem AFAIK for VS is that static and dynamic libraries are 
indistinguishable by extension. They both have a .lib one. And you don't know 
in advance is some library is static one or just import library for some 
dynamic one.

For cygwin/mingw things may be more similar to Unix.

>
> 2. I read in one post that intel was interested in cmake, fortran and
> Visual Studio.
> Having the connections with them you could ask them if they may be
> interested in cmake and MKL. Just a thought as linking against mkl (pure
> layered versions) may be quite a pain for a new user.
>
> Alin

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] static libs and more

[Alin M Elena]

Hi, 

1. Few days ago maybe weeks on the list I have seen a discussion about 
static/dynamic linking.

One of the solution proposed there to achieve a static linking was

if (UNIX)
  set(CMAKE_FIND_LIBRARY_SUFFIXES ".a;.so")
endif(UNIX)
Something similar can be done for windows I suspect.

Maybe you can add an extra argument to find_package(... USE_STATIC)
and internally in FindXXX.cmake to use it to find the correct linkage. Just an 
idea.

2. I read in one post that intel was interested in cmake, fortran and Visual 
Studio.
Having the connections with them you could ask them if they may be interested 
in cmake and MKL. Just a thought as linking against mkl (pure layered 
versions) may be quite a pain for a new user.

Alin
-- 
__ 
 "...if the universities will not study useless subjects, who will?" 
   G. F. Fitzgerald, Nature, 45/46, 392 (1892)
__
Mr. Alin M. ELENA
Atomistic Simulation Centre
School of Mathematics and Physics
Queen's University Belfast
Office: +44 (0)28 9097 1428
Fax: +44 (0)28 9097 5359
http://titus.phy.qub.ac.uk/group/Alin/
[EMAIL PROTECTED] 
[EMAIL PROTECTED]
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] FindThreads and Fortran

[Alin M Elena]

Hi,

I try to determine the correct -lpthread against which I link in a Fortran 
project. (http://code.google.com/p/tdtbuj)
using only 
find_package(Threads)
leads to an error
-- Looking for include files CMAKE_HAVE_PTHREAD_H   
CMake Error: Unknown extension ".c" for file 
"/home/alin/forge/CMakeFiles/CMakeTmp/CheckIncludeFiles.c".  TRY_COMPILE only 
works for enabled languages. 
Currently enabled languages are: Fortran
See PROJECT command for help enabling other languages.

in order to make it work I have to enable C
enable_language(C)

Having in mind that my project is 100% Fortran I find the step uneasy.
Any idea how to avoid it?


Alin



-- 
__ 
 "...if the universities will not study useless subjects, who will?" 
   G. F. Fitzgerald, Nature, 45/46, 392 (1892)
__
Mr. Alin M. ELENA
Atomistic Simulation Centre
School of Mathematics and Physics
Queen's University Belfast
Office: +44 (0)28 9097 1428
Fax: +44 (0)28 9097 5359
http://titus.phy.qub.ac.uk/group/Alin/
[EMAIL PROTECTED] 
[EMAIL PROTECTED]
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cmake works only with --debug-trycompile

[Alin M Elena]

Hi,

I have a small project
http://code.google.com/p/tdtbuj

cmake is the build system.

in linux
if I do just cmake it fails to find the proper libs.
if I do cmake cmake --debug-trycompile will work (sometimes).

I use cmake version 2.6-patch 1 RC-6  (in opensuse 11).

The FindBLAS, LAPACK modules that I use are the local ones not the ones that 
come with the cmake distribution. 

Alin





-- 
__ 
 "...if the universities will not study useless subjects, who will?" 
   G. F. Fitzgerald, Nature, 45/46, 392 (1892)
__
Mr. Alin M. ELENA
Atomistic Simulation Centre
School of Mathematics and Physics
Queen's University Belfast
Office: +44 (0)28 9097 1428
Fax: +44 (0)28 9097 5359
http://titus.phy.qub.ac.uk/group/Alin/
[EMAIL PROTECTED] 
[EMAIL PROTECTED]
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] generic Symbian gcce-toolchain file

[Frans.Fuerst]

Hi,
 
I'm trying to use CMake to build Symbian 9.2-FP1 (S60) executables in a generic 
way (i.e. not building mmp-files which have to be interpreted by perl-scripts 
provided with the SDKs).
There have been similar questions asked here before but I haven't found a 
complete answer yet that would make it possible for me to establish a 
Symbian-capable build-system from scratch.
 
Is someone out there who can hear me and already managed to compile for a 
Symbian phone using CMake (and willing to share his knowledge)?
 
these are my given circumstances:
* Symbian-9.2-SDK + CSL Toolchain + Posix-Addon + Carbide 1.2 (which together 
should result in a complete toolchain)
* Windows XP
* CMake 2.6
 
My current toolchain file looks like this (i'm working on the built-in 
XP-console):
https://www.ran-dom.org/public/mixer-frans/brandneu/cmake-toolchain_files/toolchain-symbian-9.2-fp1-gcce-arm.cmake
 
I've appended a working compile command (snapshoted when called within the 
carbide IDE)
 
thanks for help in advance,
Frans
 
successful compile command snapshot (every argument in an extra line for 
convenience only):
 
arm-none-symbianelf-g++
-O2 
-fno-unit-at-a-time  
-Wall 
-Wno-ctor-dtor-privacy 
-Wno-unknown-pragmas  
-fexceptions 
-march=armv5t  
-mapcs 
-pipe 
-nostdinc 
-c
-msoft-float   
-DNDEBUG 
-D_UNICODE 
-D__GCCE__  
-D__SYMBIAN32__ 
-D__SERIES60_31__ 
-D__SERIES60_3X__ 
-D__GCCE__ 
-D__EPOC32__ 
-D__MARM__ 
-D__EABI__ 
-D__MARM_ARMV5__ 
-D__EXE__ 
-D__SUPPORT_CPP_EXCEPTIONS__ 
-D__MARM_ARMV5__  
-D__PRODUCT_INCLUDE__=\"/Symbian/9.2/S60_3rd_FP1/epoc32/include/variant/Symbian_OS_v9.2.hrh\"
 
-x c++ 
-include /Symbian/9.2/S60_3rd_FP1/EPOC32/INCLUDE/GCCE/GCCE.h  
 
-I 
...
 
-I /Symbian/9.2/S60_3rd_FP1/EPOC32/include 
-I /Symbian/9.2/S60_3rd_FP1/EPOC32/include/stdapis 
-I /Symbian/9.2/S60_3rd_FP1/EPOC32/include/stdapis/stlport 
-I /Symbian/9.2/S60_3rd_FP1/epoc32/include/variant 
-I "C:/Program Files/CSL Arm 
Toolchain/bin/../lib/gcc/arm-none-symbianelf/3.4.3/include" 
-o /Symbian/9.2/S60_3rd_FP1/EPOC32/BUILD/test.o 
/test.cpp

 
--
Dipl.-Inf.(univ.) Frans Fürst, Software Engineer 
 
Tel.: +49-9131-7701-6298 mailto:[EMAIL PROTECTED]  
 
Elektrobit Automotive GmbH, Am Wolfsmantel 46
91058 Erlangen, Germany
Managing Director Otto Fößel
Register Court Fürth HRB 4886
 
 



Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cmake distcc

[Vandenbroucke Sander]

Hi,

 

I'm using cmake 2.4 to build code for an embedded platform. To link
everything together I use static (.a) libraries.

 

For the sake of compiling speed I want to use distcc. I do it like this:

set CC=distcc nios2-elf-gcc

set CXX=distcc nios2-elf-g++

set DISTCC_HOSTS=pc710 localhost

cmake -G "MSYS Makefiles" ../

 

Yes, I'm working on windows. Using a cross-compiler build with mingw,
distcc is using cygwin.

 

Compiling is fine, distcc does it's job. Unfortunately my linker command
is messed up. CMake used to generate something like this: nios2-elf-g++
OBJECTS -lsystem ...

With distcc this changes to: nios2-elf-g++  OBJECTS -lsystem.lib ...
Ofcource there are no .lib libraries in my project...

 

What is going on here?

 

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] trouble with cmake 2.6-patch 0 cross compiling.

[Axel Roebel]

On Wednesday 16 July 2008 8:54:11 pm [EMAIL PROTECTED] wrote:
> Hi.
>
> I've got cmake 2.6-patch 0 installed and I'm trying to get a simple
> (helloworld.cpp) compiled and built on a linux system.
>
> My toolchain file looks like this:
>
> -- toolchain.cmake --
> SET( CMAKE_SYSTEM_NAME foobar )
> SET( CMAKE_SYST EM_VERSION 1 )
> SET( CMAKE_SYSTEM_PROCESSOR arm-foo )
> SET( CMAKE_SYSTEM_C_COMPILER /absolute/path/to/compiler )
> SET( CMAKE_SYSTEM_CXX_COMPILER /absolute/path/to/compiler )
Hi Phil,

I think you simply mixed these up. The last ones should be

SET( CMAKE_C_COMPILER /absolute/path/to/compiler )
SET( CMAKE_CXX_COMPILER /absolute/path/to/compiler )

no SYSTEM_ there!

see: http://www.cmake.org/Wiki/CMake_Cross_Compiling

Cheers,

Axel

> SET( CMAKE_FIND_ROOT_PATH /absolute/path/to/compiler/tools )
>
> SET( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER )
> SET( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
> SET( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )



-- 
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake