On Monday 17 December 2007, you wrote: > Alexander Neundorf wrote: > > On Monday 17 December 2007, Gonzalo Garramuño wrote: > >> Bill Hoffman wrote: > >>> Gonzalo Garramuño wrote: > >>>> * good for cross-compilation. > >>> > >>> CVS CMake (and the coming 2.6 CMake) have extensive support for cross > >>> compilation. > >>> > >>> http://www.cmake.org/Wiki/CMake_Cross_Compiling > >> > >> I'm still having a lot of problems with it. Even cross-compiling on a > >> 64-bit machine for 32-bit builds is, afaik, not really possible without > >> major hacking of Platform/UnixPaths. > > > > Ok, what are you doing exactly, what are the problems ? > > First, trying simple 32-bit compiles on a 64-bit machine (Ubuntu OS).
I'm not sure this really counts as "cross compiling". Two basic assumptions were -the executables for the target cannot run (in general) on the build host -the target environment is completely different from the build host environment, i.e. with its own set of libraries and headers located in a separate subtree (as it is the case for embedded linux, Win CE, eCos, sdcc, AD compilers, Cray compilers etc.) This is not really the case here. I think there is a bug report about chosing these variants you need correctly. > For 32-bit compiles on a 64-bit machine, the problem is that UnixPaths > does not change the location where it searches for files. > > First, CMAKE_SYSTEM_LIBRARY_PATH is set incorrectly to always search > lib/ paths instead of lib32/ or lib64/ paths. This will create warnings > for the most part as the linker is usually smart. However, if a library > is not present on 32-bits, the 64-bits file will get picked up and the > problem will only appear show up when linking, not during configuration. > > CMAKE_SYSTEM_PROGRAM_PATH also suffers from a similar issue. This is an > issue with modules that use pkgconfig, for example or that set settings > from finding executables like ruby. It isn't entirely clear to me if > there is a standard location for 32-bit bin files (not libs) in Linux, > thou. > > CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES is also wrong, adding both 64 > and 32 bits paths. > > Afaik, there's no variable indicating whether to compile for 32bits or > not. And cmake does not check for the -m32 flag at all. CMAKE_SIZEOF_VOID_P Maybe this should be honored more extensive ? But this is an issue more for Brad (or Bill) ? > I have my own UnixPaths and modules to work around most of the above, Can you please post it ? > but it would be good to have this working out of the box. Yes. > Recent versions of cmake seem to have also added this: > > # Enable use of lib64 search path variants by default. > SET_PROPERTIES(GLOBAL PROPERTIES FIND_LIBRARY_USE_LIB64_PATHS TRUE) > > which seems highly undesirable or a so far undocumented feature. Brad, Bill ? > --- > For cross-compiling, I was trying to do some compiles from my Unix box > to windows using a unix-mingw32 to windows toolchain. I was utterly > unsuccessful. I just kept fixing one error only to find another one. I > had followed the cmake wiki for cross-compiling, but there were still > many issues with paths in modules and the like. If you want to walk me > thru it, I'll start a new thread with the errors I find as I go thru it > again. Yes, please. It should work and I'm happy about feedback. Alex _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake