@Raziel

Quote:

I have seen this with certain builds, and I am not sure, why it happens. It needs to be fixed of course.

Quote:

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.

@Raziel

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.

@Raziel

Quote:

Those warnings should be there. It indicates, that it is an old project and should be updated.

Quote:

Have you checked your memory consumption? There is a memory leak that we haven't trapped yet. More on this latter.

Update :

Quote:

The updated content looks like this:

* There is now a partial native build system, which is confirmed working on several cases. Certain build tools don't have complete function due to path issues, but there is enough of a framework to confirm functioning in complete extension.
* Completed/built binaries are confirmed working in all cases.
* This is now done using .so libraries instead of static linking.
* There needs to be done work to update OpenGL ES 2 bindings. This is probably trivial (if one has time).
* Simplified code base due to improved standard c library.

And in the release notes : Thanks to the work done by the authors of clib4.library.

@thread

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.

@jabirulo

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.

@jabirulo

Your setup looks correct. I don't know what to suggest. Maybe a run with snoopy?

@jabirulo

What happens if you rename your cmake folder "cmake-amiga"?

@all

Anyone having any ideas?

@jabirulo

Are you sure, you are using the right version of clib4.library?

EDIT : If you do "version clib4.library full", what does it show?

@jabirulo

Ok. So it is actually calling the compiler. The problem must be make/gmake. Are you by any chance using a non-standard SDK?

EDIT : Did it work for you before v0.0.3a? What if you add a "LANGUAGE c" clause to the project() definition?

@jabirulo

Did you complete these steps?

AmigaOS readme on github.com

@jabirulo

I have not tested cmake with bash (abc-shell I assume?). I have my doubts, that it is going to work. Have you tried just from a normal shell?

By the way, I am actually rather sad, that the "cmake -B build" syntax is starting to replace the old form. So much nostalgia in the little details on the command line! 😅

@vagappc

Quote:

Yes. Although the current port only uses soft render for normal (non-gl) windows.

There are different options for acceleration. I think there is a simple switch somewhere, that turns all windows into gl-windows, but of course one could also do something like in the old 4.7 version, that uses compositing for drawing operations. This last option would be a lot of work, but maybe interesting for scientific purposes.

@vagappc

* Switch to clib4
* qmake (native) works
* moc (native) doesn't work
* Rest is assumed working (but untested)

@MartinW

Nice

That's enough for me for now. Hope you enjoyed the testing, and thanks for putting work into it!

@MartinW

Please post a screenshot here.

Release 0.0.2a :

CMake 3.29 alpha2 on GitHub

Remember to get also the new version of clib4.library. Cheers!

@nbache

Quote:

Now, I guess I am not too involved in clib4 development, but I guess one of the main goals must be to make a perfect library, that is immutable and clear and meets all your needs. In all other cases, there could be the possibility of different apps relying on different quirks of different versions of that library, and it would be impossible to meet those needs, unless the user could pick and choose.

@MartinW

Quote:

Thanks! In the meantime, I did some calculations and figured out, that the problem is indeed a problem with symbolic links. I will test and turn the text and come up with a solution in a week or two.