By the way : If someone has a Nemo mb for sale, then I'm a high bidder.

@kas1e

Here is the latest version, I could find :

Crimsoncrisis.asm

@kas1e

Quote:

Well, maybe you can? :) At least you are in a better position to do the work at the moment. I am in a total burnout, trying to recover.

@Raziel

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.

@kas1e

I think the most up-to-date version of the file is located on my Sam, that resides with a friend for the time being. I can get it earliest by the end of next week.

If you are in a workflow, I suggest you work your patches from what you have now. AFAIR the changes, that are needed, are pretty easy to spot. Basically all calls to RtgMaster.library need to replaced by calls to graphics.library. If you manage to do this, you should have a running version with very few bugs (there are still some graphics in the in-between-games screens, that are off). And if you get this far, then maybe you will see clearly how to fix the timing bug, that makes it impossible to play and win level 2 of the game.

@kas1e

Thank you! :)

Yes, that is true - it is very clear, now. But why it happens to just this one type of symbol... I would have to know a great deal more about how the compiler works, to answer that!

@NinjaCyborg

I am not sure exactly what you mean. It is the same symbol, referenced in exactly the same way, just from two different places. It doesn't seem to have anything to do with the function name, rather it must be the way it is referenced (by &object::function() ). You are correct, that there are two instances of the symbol : One is instantiated inside the shared object and is a symbol of type .text with an address and a size. The other is an UND* (undefined symbol), residing inside the main executable, and this one should be linked to the first one upon execution by the runtime linker. You can confirm this by using objdump -t on the executable and the shared object and searching the resulting texts for the function name.

This is exactly the same pattern as with a shitload of other symbols in the Qt libraries and executables, that all end up linking perfectly well with the code executing as it should. I am really troubled to understand, why it would fail in this case. But the test shows very clearly, that the exact same printf statement executed in two different places produce different addresses for the exact same symbol referenced in exactly the same way. So there must be a bug somewhere.

Preferably, someone with an updated system (latest system files) should test this to confirm, that it is not just happening on my system.

I'm linking to the error report test case here, in case anyone wants to get snappy with it. Who knows, there could be a solution, we haven't thought of?

https://drive.google.com/file/d/1dTrUx ... fBcwhYy1/view?usp=sharing

When run, it will output two different addresses for the same symbol. This is the bug, that I can't fix, and I am pretty sure, that it is either the compiler or linker, that has a problem. It has been tested against GCC 11 and 8.

@trgswe

Thanks you for the link to the video. I watched it, and it is very good at talking about modern syntax in these things.

Basically, what is the problem with the current Qt6 for Amiga is, that the newer version of the connect statement uses a template, that somehow gets the function address wrong for the connecting signal. Why this happens is a huge mystery, and I have already spent too much energy on trying to find a fix. If someone solves this, I will buy beer and send gifts.

@kas1e

There is a timing bug, that makes it impossible to win in level 2 of the game. The enemy attack comes too fast, which makes it impossible to build up ressources to win the battle.

There are references in the code to some of the custom chips, that have to do with timing. I think these references are responsible for the error, but I never made it through to understand, what was going on. Maybe you can do a better job.

@LiveForIt

You are right. Hmm. I think maybe, that this is an old version of the assembly file. AFAIR I changed all references to RtgMaster.library to graphics.library calls. I will see, if I can find a more moderne version of this source on my harddrive.

@afxgroup

And follow instructions on the GitHub page.

@afxgroup

There is a file

configure-amiga.sh

in the root of the repo.

In this file, change

AmigaOS

to

Generic

and it will produce a static build.

@kas1e

In case you want to fix the timing bug in Napalm :

https://www.dropbox.com/s/gogzdtpndxudq5u/crimsoncrisis.asm?dl=0

I have officially given up.

The current base can be used under cross environment on linux, if you build it yourself and use the supplied toolchain. If you configure it to use static linking, it works fine. If you configure it to use dynamic linking and build Qt libs as shared objects, then you need to keep in mind, that all of your QObject::connect() calls will fail, unless you change the notation to the old style from Qt4.

@trgswe

So maybe I should try disabling it?? This begins to become very hairy...

@thread

Nope. I tried both -mlongcall and forcing -fPIC for shared library objects. Nothing works.

Basically, there is a single symbol (in this case a function) that changes value from when it is called in the main executable to when it is called from within the shared object. The content resides in the shared object and is linked from the main executable. This does very much sound like an issue with either -mlongcall or -fPIC, but at this point at least I haven't cracked the code to make it work. This begins to annoy me...

@kas1e

That is fantastic progress! :)

Remember, that there is a version of IRA available on os4depot, that actually handles WarpOS executables. In case you want to get really fancy ;).

@Capehill

I will do that, if the next step fails. Thanks for mentioning!

@thread

Could someone please repeat the correct use of -fPIC when building shared libraries and applications that use them?? I want to be absolutely sure, that this is in fact the problem here, which would be wonderful.

@trgswe

Thanks! I will take a look.

@thread

In the meantime - this issue needs to be fixed, if we want a dynamic linking version of Qt6. The dynamic link version is a requirement for building qt-creator, so it is quite cruzial.

The issue is described here :
https://github.com/sba1/adtools/issues/109

I have looked at adtools, and I am not in a position to find a solution at this point. Anyone have ideas for attacking the problem??