When dev-embedded/sdcc is installed, cmake's test suite attempts to run a test named SimpleCOnly_sdcc which fails. See to-be-attached build log and emerge --info.
Created attachment 246990 [details] /tmp/cmake-2.8.1-r2-build.log
Created attachment 246991 [details] /tmp/emerge--info.txt
Created attachment 246992 [details] /tmp/SimpleCOnly_sdcc-CMakeError.log
Is your -march correct?? Try with -march=amdfam10 and...regard your flags generally
(In reply to comment #4) > Try with -march=amdfam10 ohnobinki@ohnopublishing ~/abstraction/2010-2011 $ gcc -march=gobblygook ~/test.c -o /tmp/sdfsdf /home/ohnobinki/test.c:1: error: bad value (gobblygook) for -march= switch /home/ohnobinki/test.c:1: error: bad value (gobblygook) for -mtune= switch ohnobinki@ohnopublishing ~/abstraction/2010-2011 $ gcc -march=athlon64 ~/test.c -o /tmp/sdfsdf /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status ohnobinki@ohnopublishing ~/abstraction/2010-2011 $ sdcc -march=amdfam10 ~/test.c -o /tmp/sdf -:0: error 131: cannot generate code for target 'arch=amdfam10' ohnobinki@ohnopublishing ~/abstraction/2010-2011 $ sdcc -mamdfam10 ~/test.c -o /tmp/sdf -:0: error 131: cannot generate code for target 'amdfam10' I don't see where -march=amdfam10 would get me. > and...regard your flags generally What do you mean? I think that the problem my be Gentoo's cmake ebuild too agressively inserting CFLAGS and such into CMake's buildsystem. I don't know if Gentoo has any support for an ebuild using sdcc(1) to compile something; perhaps make.conf(5)'s CFLAGS variable shouldn't be used directly with sdcc(1). Also, sdcc(1) is intended to be used as a crosscompiler, but to use CMake with sdcc(1) one has to first compile a CMake for the --build system. It just happens that the tests fail when CMake's testsuite detects that sdcc is installed (and possibly because CFLAGS is non-empty which is the norm...).
If the error is: -:0: error 131: cannot generate code for target 'arch=athlon64' If you remove your -march...receive the same error?
(In reply to comment #6) > If the error is: > > -:0: error 131: cannot generate code for target 'arch=athlon64' > If you remove your -march...receive the same error? No. With my test.c file, removing -march causes sdcc to complain about no main() function just like gcc(1) does. But I still get all of the errors about my other CFLAGS in CMakeError.log, as shown in attachment 246992 [details] .
Created attachment 247055 [details] /tmp/SimpleCOnly_sdcc-CMakeError.log (In reply to comment #7) > as shown in attachment 246992 [details] . Actually, they don't show up in that attachment. The other CFLAGS errors show up in this one.
Given what sdcc is and how it is supposed to be used simple excluding of the test is best option for us.
(In reply to comment #9) > Given what sdcc is and how it is supposed to be used simple excluding of the > test is best option for us. Well, the correct fix would be to make sure that cmake's sdcc test doesn't inherit the host system's CFLAGS do not get passed to the test. The test's problem is that it respects CFLAGS; other than that, the test is completely valid on Gentoo even when considering what sdcc is and how it should be used. That is, sdcc isn't intended to be used with CFLAGS as defined in /etc/make.conf and it wrongly is being used with those flags here ;-).
(In reply to comment #10) > (In reply to comment #9) > > Given what sdcc is and how it is supposed to be used simple excluding of the > > test is best option for us. > > Well, the correct fix would be to make sure that cmake's sdcc test doesn't > inherit the host system's CFLAGS do not get passed to the test. The test's > problem is that it respects CFLAGS; other than that, the test is completely > valid on Gentoo even when considering what sdcc is and how it should be used. > That is, sdcc isn't intended to be used with CFLAGS as defined in > /etc/make.conf and it wrongly is being used with those flags here ;-). > I spent quite some time to make that cmake obey all system *FLAGS, do you think i am inclining tho hack it again once around to make sure one test does not use them? It is really way easier to just ignore the test. (patches welcome tho, altho they wont be ever accepted by upstream because they wont hit this issue most probably)
