CMake 3.29 Native (OS4)

Has anyone experienced any crashes? I've got the alpha CMake up and running and it starts to work. But it always always ends up in a crash. I'll collect some crash logs. Right now trying to update some code using the newer CMake.

@Hypex

What do you mean "always ends up"? As in : You can start cmake, and it does some work, but then it crashes? At what point does it crash, and of course : What does the crash look like?

If it is another stack issue, then it is easy to fix. AMOF I don't quite remember, if the online version contains a stack cookie.

@elfpipe

Quote:

So I enter a build folder and run a "cmake .." like so:


After printing all that to CLI I get a reaper. I'll post a cut down of it:


Quote:

You could be right. I checked and my shell has a paltry stack that's barely over 64KB. I changed it to 1MB and CMake didn't crash! Thanks for the hint. The shell needs a bugzilla if the default is really that small.

Ok so that's a lot better. But then I got stuck again. Like happened recently after reading back a few pages CMake cannot find my make command or compiler either:


I saved a Snoopy fail log but don't see where it's looking for a make or compiler:


I'm trying to build this project:
https://github.com/jibsen/tinf

@Hypex

This might be a problem with filesystems and case sensitivity issues. I haven't gotten around to checking cmake on another partition, so I can't tell for sure, but if you want to try it out, you can try installing in an sfs partition and see, if that helps. It might also be important, what partition your SDK is located at.

@Hypex

Try with:

hope i got it right

@elfpipe

Actually, it is on an SFS partition. My Development volume is SFS. On that is installed the SDK and CMake folders.

@Raziel

Thanks. That looks like an obvious route. I'm not sure how I did it a few years back. I managed to configure it with the older CMake but it doesn't work now as it relies on older so objects so I can't run it. But the new one complains about the old build files. Suppose I need to treat it like a cross compiler as on AmigaOS you need to hold it's hand when configuring a build, since it doesn't pick up things automatically like on other systems.

@elfpipe
Quote:Default for SFS partitions is case-insensitive, as on any other AmigaOS filesystem.

SFS partitions can be formatted case sensitive, but it has to be done at format time and with "SFSFormat". It's not possible to change it after formatting, nor can it be enabled with the AmigaOS SYS:System/Format tool.

For example OWB, which used CMake as well, can't be built on case-insensitive AmigaOS file systems and I had to use a case sensitive formatted SFS\2 partition for building it.

@elfpipe

Okay got it working. It didn't need to be told where compiler is. But it did need to be told where "make" is. So it was able to complete the build. The make ran without problems.

However, I managed to crash it again. I don't know how. I tested CMaking the tinf project from the RAM Disk. It crashed CMake. Does it matter if I CMake direct to list file without a build folder?

Looks like it drank a bad coffee from a bad cafe:

@joerg

Quote:

Thanks for the explanation. I had some problems with OWB, that went away, when I moved it to a FFS partition. As I said, I still need to test this difference, I am sure from what I hear from people testing cmake that there is a possible connection on functioning and some relation to the file system(s) used.

@hypex

The crash you are seeing looks strange, and I don't have a ready answer (from looking at the source in this place, there is not much to see, other than a possible connection to pipe()/read() which sometimes has a little bit strange behavior). EDIT: Is it a regular crash, or does it only happen from time to time (ie. are the conditions stable or spurious)?

About using source tree builds, this should not be a problem, but perhaps the specific build situation triggers some otherwise hidden problem.

@elfpipe

I can see a new clib4 version was released.

did you guys find the memory leak by chance?

@Raziel
Unfortunately, not yet, but plenty of improvements and fixes are introduced in this release.
For the memory leak, we have an open issue, and it is high in our priority to find it and fix it.

@walkero

ok, thank you

The new version has a new fresh memory allocator. Most probably it is not the cause of memory leaks (if any..) but worth a try

@afxgroup

does it work by simply updating clib4, or does cmake need a recompile?

@Raziel

It should work just replacing the library

@afxgroup

will try then, thank you

@afxgroup

Memory leak is still there.
But at least it's being worked on, so, no pressure