[CMake] can't build translated makefile on snow leopard 10.6.5 w/ g++ 4.2.1 (complaint: g++: No such file or directory, although g++ is there!!)

Andreas Pakulat apaku at gmx.de
Mon Dec 20 17:53:01 EST 2010


On 20.12.10 23:34:55, ny wrote:
> The code was never been tested on a mac, not to mention snow leopard.
> I have the guarantee that it compiles + builds for win + linux.
> Project was a collaborative effort and unfortunately I am stuck without a
> makefile =P and with the ugly *.vcproj file. Note that I did not use an
> automated  ruby script I found for

Then either it doesn't build on Linux or there must be something else
for Linux. There is no buildsystem that operates on .vcproj files
(afaik) except VS which doesn't work on Linux.

> the translation of *.vcproj to makefile, since the script only
> handled the basics -> no pre/post-build steps or file-specific flags are
> included;
> instead, I translated from scratch to CMakelists and then converted to
> makefile. not that tricky as it sounds..
> 
> So, assuming the problem is w/ the makefile, why do I have a clean
> makefile during the configuration/generation steps?

Are you mixing up Makefile (which is something that make works with) and
CMakeLists.txt (which is the input for cmake, which then generates
Makefiles from it)? To me the above doesn't make much sense when talking
purely about Makefile's.

> Note that I choose to generate Unix makefile, not an xcode project.
> 
> I 've successfully translated the *.vcproj file into a makefile,
> fixed a few issues, linked to external libs, but the build w/ make fails and
> I get
> 
> *i686-apple-darwin10-g++-4.2.1: g++: No such file or directory
> make[2]: *** [CMakeFiles/.../.../...cpp.o] Error 1
> make[1]: *** [CMakeFiles/.../.../all] Error 2
> make: *** [all] Error 2
> *

Whats the full errror and the full compile line (run make VERBOSE=1)?

> which, honestly, I don't remember seeing before -> complaining about
> g++ I mean and not missing file or dir. Note that g++ *is* in place, I can
> successfully compile other programs.
>
> Assuming that /usr/bin was somehow not in the path during the cmake
> invocation,
> I used
> *
> *
> *set(CMAKE_C_COMPILER /usr/bin/gcc)*
> *set(CMAKE_CXX_COMPILER /usr/bin/g++)*
> 
> in the beginning of my CMakeList.txt without any luck.
> It complained temporarily for a conflict, i.e. had to reset the cache,
> but no progress so far. I
> 
> 
> I am stuck a few hours now and I suspect  (or better hope) that the
> problem is sth similar to the typical 32-bit/64-bit problem in mac
> ports. I tried w/ -arch i386 -m32  flags without any luck, so I 'd love to
> hear any thoughts, ideas..
> I guess there are parts of the code need to be re-written especially
> for OS X SL, but I cannot figure out the problem since the failing error is
> not
> descriptive enough.
> 
> When I build a xcodeproj (with g++ flag -arch i386), I get:
> 
> *lipo: can't figure out the architecture type of: /var/folders/9b/
> 9b2CWG5gHvCi5hawjO4o5E+++TI/-Tmp-//ccXHDX6t.out
> Command /Developer/usr/bin/gcc-4.2 failed with exit code 1
> *
> When I build a xcodeproj (with g++ flag -arch x86_64), I get:
> 
> *setenv LANG en_US.US-ASCII
> /Developer/usr/bin/gcc-4.2 -x c++ -arch x86_64 -fmessage-length=0 -
> pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -mdynamic-no-
> pic -DCMAKE_INTDIR="Debug" -isysroot /Developer/SDKs/MacOSX10.6.sdk -
> mmacosx-version-min=10.6 -gdwarf-2 -Wmost -Wno-four-char-constants -
> Wno-unknown-pragmas //... ...
> i686-apple-darwin10-gcc-4.2.1: g++: No such file or directory
> Command /Developer/usr/bin/gcc-4.2 failed with exit code 1*
> 
> all cryptic..

Do you have a g++ in /Developer/usr/bin/? I don't know too much about
the setup of Compilers on MacOSX, but if gcc-4.2 is run in that path,
maybe it expects the g++ at the same place and not just /usr/bin (unless
the two are symlinked).

Andreas

-- 
Tonight's the night: Sleep in a eucalyptus tree.


More information about the CMake mailing list