#cd build/
#cmake ..
-- CMAKE_HOST_SYSTEM_VERSION : 53.18
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
CMake Error: Generator: execution of make failed. Make command was: /Devel/cmake-amiga/bin/cmake -E env VERBOSE=1 /SDK/C/gmake -f Makefile cmTC_629ed/fast
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /SDK/gcc/bin/gcc
CMake Error: Generator: execution of make failed. Make command was: /Devel/cmake-amiga/bin/cmake -E env VERBOSE=1 /SDK/C/gmake -f Makefile cmTC_9582e/fast
-- Check for working C compiler: /SDK/gcc/bin/gcc - broken
CMake Error at /Devel/cmake-amiga/share/cmake-3.29/Modules/CMakeTestCCompiler.cmake:67 (message):
The C compiler
I have changed my theory : I believe now, that it is your compiler, that fails to build an executable. The step that fails would be some call on try_compile() (in the ABI detection script). This could potentially happen, if the setup you are working with requires, say, "-athread=native" in order to compile (and not fail).
Could you please try and change the compiler version with the
SDK:Tools/set_defGCC
tool?
EDIT: It could also potentially be caused by the spelling of symlink names in the version control of the SDK. This might be different in different version.
I have not fixed case sensitivity issues in cmake, since it never came up in my tests. I will try and find time to address this issue. In the meantime, be aware, that spelling (upper-lower case) in path names might be the subject of success/failure of calls during generation/build.
I have not fixed case sensitivity issues in cmake, since it never came up in my tests. I will try and find time to address this issue.
Don't do that, it may break more than it fixes. For example I could build OWB on AmigaOS 4.x only if the sources were on case sensitive formatted SFS partitions. On any other file system, default on AmigaOS is upper=lower case for the ASCII chars, it failed because it had different files with the same names where only the case of some chars differed.
This doesn't particularly help anyone with their troubles, but I did manage to get 20 minutes just now to update my copy of cmake and can confirm that for me, everything still works as it did before. I haven't had a chance to progress to a more complex program yet - real life getting in the way!
a first test with a small project shows that it works for me now
one policy warning (more on a bigger project) but that's it. I take it those warning are the same as with compiler warnings, i can suppress them with flags, but it would be better to fix them?
CMake Deprecation Warning at CMakeLists.txt:1 (CMAKE_MINIMUM_REQUIRED):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
-- CMAKE_HOST_SYSTEM_VERSION : 53.18
-- The C compiler identification is GNU 11.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /SDK/gcc/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Configuring done (8.8s)
CMake Warning (dev) at src/CMakeLists.txt:3 (add_library):
Policy CMP0115 is not set: Source file extensions must be explicit. Run
"cmake --help-policy CMP0115" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
File:
/Development/Porting/musepack/libreplaygain_r475/src/gain_analysis.c
This warning is for project developers. Use -Wno-dev to suppress it.
-- Generating done (0.2s)
-- Build files have been written to: /Development/Porting/musepack/libreplaygain_r475/build
Thanks a lot
Now, off to play
edit:
I have yet to find a way to reproduce it, but after some time all the cmake binaries turn non-executable...i get the error message that this binary is not exectuable (all three cmake, ctest and cpack)
yep, that seems to be it, eats away upto 770 MB, i still should have roughly the same left, but it looks like it's either hellishly fragmented or the display is wrong.
once the "file is not executable" comes up not even odyssey starts up anymore
That'a all good fun. Maybe we will have time this weekend to trap the memory gnome. Good to see, though, that the software actually runs somewhere in the outer universe.
-- CMAKE_HOST_SYSTEM_VERSION : 53.18
-- The C compiler identification is GNU 11.3.0
-- The CXX compiler identification is GNU 11.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: ///SDK/gcc/bin/ppc-amigaos-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: ///SDK/gcc/bin/ppc-amigaos-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
Not sure if this is a problem later on, since it gets detected nonetheless, but i'm hesistant to say there isn' t a problem.
Also and opt: device is being asked for, cancelling this lets me move on
I have seen this with certain builds, and I am not sure, why it happens. It needs to be fixed of course.
Quote:
Also and opt: device is being asked for,
I don't think there is an invocation of /opt/ in the binary, so this is probably from some script in the Modules/ directory. I have touched absolutely none of these, someone else has a project going doing generic updates there.
EDIT: I probably accidentally included a reference to /opt/ in the build command for cmake itself. This would explain, that it comes up with a more or less simple build.
@elfpipe This huge memory leak Raziel meet with looks very similar with one we have with clib4 build of gdb: loading of some more or less big binaries cause full memory eating and "memory exhaused" words. Can be well related to calloc/realloc ?
As well as both cmake and gdb use pipes, and with both of them we have on exit not cleared pipe-handlers left in dos processes. This one also cause small memory leak.
And, there some another strange problem with memory happens which by amount of leaked memory looks like same you had with cmake tests, and in gdb it easy reproduced like this : https://github.com/AmigaLabs/binutils-gdb/issues/23