When configuring a minimal cmake project using an AmigaOS toolchain file, you get this:
Quote:
-- The CXX compiler identification is GNU 11.1.0 System is unknown to cmake, create: Platform/AmigaOS to use this system, please post your config file on discourse.cmake.org so it can be added to cmake -- Check for working C compiler: /opt/adtools/bin/ppc-amigaos-gcc System is unknown to cmake, create: Platform/AmigaOS to use this system, please post your config file on discourse.cmake.org so it can be added to cmake CMake Error: Generator: execution of make failed. Make command was: cmTC_7bd00/fast && -- Check for working C compiler: /opt/adtools/bin/ppc-amigaos-gcc -- broken CMake Error at /usr/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message): The C compiler
Run Build Command(s): cmTC_7bd00/fast && No such file or directory Generator: execution of make failed. Make command was: cmTC_7bd00/fast &&
CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:3 (project)
-- Configuring incomplete, errors occurred! See also "/home/alfkil/cmake-mini/build/CMakeFiles/CMakeOutput.log". See also "/home/alfkil/cmake-mini/build/CMakeFiles/CMakeError.log". a
Toolchain file:
Quote:
# this one is important SET(CMAKE_SYSTEM_NAME AmigaOS) #this one not so much SET(CMAKE_SYSTEM_VERSION 1)
# where is the target environment SET(CMAKE_FIND_ROOT_PATH /opt/adtools) # search for programs in the build host directories SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -athread=native")
Setup has been tested with adtools build of gcc 8 and 11. Both fail.
Is there any knowhow on how to make cmake work together with the Amiga compiler? Or maybe an idea for a patch...
According to a related google search the issue might be with escape characters and how they are handled by the compiler. Relating to my experiential memory of building cmake natively on AmigaOS, i'd say it's a likely explanation.
Thanks! I had a little progress. The minimal cmake now configures correctly. Problem now : I need -G Ninja, which makes the configuration fail with this output:
Quote:
-- The CXX compiler identification is GNU 11.1.0 -- The C compiler identification is GNU 11.1.0 -- The ASM compiler identification is GNU -- Found assembler: /opt/adtools/bin/ppc-amigaos-as -- Check for working CXX compiler: /opt/adtools/bin/ppc-amigaos-g++ CMake Error: The detected version of Ninja (GNU Make 4.2.1 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.) is less than the version of Ninja required by CMake (1.3).
CMake Error at /usr/share/cmake-3.16/Modules/CMakeTestCXXCompiler.cmake:37 (try_compile): Failed to generate test project build system. Call Stack (most recent call first): CMakeLists.txt:39 (project)
-- Configuring incomplete, errors occurred! See also "/home/alfkil/qt6-build/CMakeFiles/CMakeOutput.log".
Thanks! I had a little progress. The minimal cmake now configures correctly. Problem now : I need -G Ninja, which makes the configuration fail with this output:
You should not need Ninja it should build a regular Unix makefile too.
I think its -G Unix
Now Ninja will definitely make it build faster...
But I would try to remove the option and get working first.
Qt6 now configures completely except for OpenGLES2. Thanks! I will need to play around with that part a bit before progressing. I'd like to learn how GLES2 feels on Amiga before going on to implement stuff, that uses it. But nice to know, that configuring Qt6 is now as 'easy' as this :).
Edited by alfkil on 2021/8/26 18:28:37 Edited by alfkil on 2021/8/29 15:44:51 Edited by alfkil on 2021/8/29 15:59:19 Edited by alfkil on 2021/8/29 16:11:23 Edited by alfkil on 2021/8/29 17:16:28 Edited by alfkil on 2021/8/29 17:17:54 Edited by alfkil on 2021/8/30 12:14:07 Edited by alfkil on 2021/8/30 15:54:56 Edited by alfkil on 2021/9/2 19:59:59 Edited by alfkil on 2021/9/2 20:06:18 Edited by alfkil on 2021/10/15 17:39:19 Edited by elfpipe on 2022/12/30 14:59:44 Edited by elfpipe on 2023/2/8 16:51:57
That is awesome. I wont lie I spent many days working on LLVM build as it was my first time working with CMAKE. It can be finicky but it is super powerful and I like it better than the old config scripts. I was able to build LLVM without having to work on anything more than code issues not flaying about with the build system.
1) it doesn't seem to be Amigaos core releated 2) it doesn't seem to be windows related... 3) it might be apple related since they do deal with something called unwinding in the UI, there is a specific library called libunwind (IRC) on savannah.org.
[b]The libunwind project[/b]
[center]The primary goal of this project is to define a portable and efficient C programming interface (API) to determine the call-chain of a program. The API additionally provides the means to manipulate the preserved (callee-saved) state of each call-frame and to resume execution at any point in the call-chain (non-local goto). The API supports both local (same-process) and remote (across-process) operation. As such, the API is useful in a number of applications. Some examples include:[/center]
[b]exception handling[/b]
The libunwind API makes it trivial to implement the stack-manipulation aspects of exception handling.
debuggers
The libunwind API makes it trivial for debuggers to generate the call-chain (backtrace) of the threads in a running program.
[b]introspection[/b]
It is often useful for a running thread to determine its call-chain. For example, this is useful to display error messages (to show how the error came about) and for performance monitoring/analysis.
[b]efficient setjmp()[/b]
With libunwind, it is possible to implement an extremely efficient version of setjmp(). Effectively, the only context that needs to be saved consists of the stack-pointer(s).
so my answer is somehow either libunwind has been put as a dependency into Qt 6.1.2 or you have somthing that enables macintosh/iOS/tvOS code.
Are you using the libstdc++.so that is built along with gcc 11, or are you using the one the one that is supplied with the OS (in SOBJS:)? If it's the latter then that is likely the reason for your problem.
IIRC the newer libstdc++.so is not backwards compatible so the best solution ATM is to bundle it with your program or not use shared objects if possible.
You may also need to update other compiler shared object files like libgcc.so. I'm not sure as I don't use shared objects much anymore.
I think, you are on the spot. I have not updated libstdc++. I have, however, changed my strategy towards the use of static linking as not only a rule og thumb but rather as an absolutte principle. Qt tries to avoid this, but in vain. ;)
I think there is a deeper issue of shared objects being conceptully stray in comparison to the way they are implemented on amiga. It seems to give more problems that it solves, and often working on 100% static pays off in simplicity.
I doubt that the current build includes stuff from Mac OS. It is very tightly wound around generic Unix, and its autodetection of features seems to catch most stray functionalities. I deem it more likely that one shared objects was mismatching between host and target platforms.
While that may be true to an extent it also limits the ability of building big projects natively.
ScummVM is hitting the 2GB RAM barrier on compiling the binary natively already and it will stay that way until there is a breach of that barrier (which may never come).
I switched to a shared build to still be able to provide native builds, as switching to cross compiles will be equal to quitting amiga completely for me.
I hope that whatever OS solution there will be in the *near* future will bring system-wide extmem support and 2+GB RAM support.
I just want to chime in on this about dynamic linking. I am with Raziel with this. For the size of executables we are now looking at static linking is almost to point of unusable with C++. Right now only viable option for C++ on AmigaOS is Clib2 statically linked.
For LLVM a Debug build is almost a 1.5 Gig and the Amiga Elf loader struggles runs executable two three times and memory is hosed.
Striped you are looking at minimum of 30+meg executable. The libStdc++ for Clib unstripped is almost 26megs. I would love to try to get Clang building but until a newer version of newlib becomes available that supports C++ 14 and the std namespace. I am not sure how much further I can go. And for LLVM there is no way to compile native. I had to reconfigure my Hyper-V to give at least 16 gigs of ram to my Linux instance to get LLVM cross to build.
Anyway just sharing some thoughts on dynamic vs static linking. Teach me to not just stick with C!
I of course understand, that there are cases, where dynamic linking is the only option. I was a little too quick on the trigger, but also my statement was more a reminder to myself, that it sometimes helps the advancement of intent to limit the number of unknown factors. I simply thought that on top of feeling a wee tad unfinished, the dynamic linking aspect also gives rise to potential problems such as lost symbols at shutdown, multiple possible linking objects, incongruent search paths etc. So it is very nice to work without this for the time being.
When all that is said, I am of course (of course.... ;) ) going to build Qt 6 with dynamic linking at some point to satisfy the requirement of having small (wee small) executables and also because of completeness. But before I get to that, I will like to first have a complete and congruent model for paths that might or might not preserve some built in unix aspects.
It has been quite a few years since I did the port of cmake. Since I have never received any complaints before now, I assume that you are the first to use it :).
I am not in a position to do much coding work right now. Sadly. I spend much of my joy on the Qt port, that has ended up being an impossible job due to the compiler bug (or whatever it is). So no, I am not doing a cmake port right now.
If I manage, I will track down the original package of the old port and repost.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
