Qt 6 progress

@alfkil

What do you mean usage? You simply set -fPIC Which stands for Position Independent Code, AFAIK you should never use it in ordinary code under windows and Linux (except libraries and -usually- plugins maybe also device drivers)... the strange part is shouldn't it be enabled by default for Amiga, since all code should be position independent on it...

@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...

@trgswe

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

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.

can you give me a point where to start? I mean try to configure it as static lib?
I want to try to compile it and try to understand what is wrong. I know very well that is hard to work on this kind of projects alone and with tools that doesn't works very well. It is hard for us..

@alfkil

No keep it off for main programs, but enable it for all libraries (Including standard qt libraries, but excluding link libraries), one needs to checkout how amiga really handles sobjs, would it be better to go with amiga style libraries? (but then you have rewrite issues, maintenance issues),

However there is something strange in libstdc++ library
or better maybe in binutils
I'm trying to fix a problem on clib2. I've added a cout in an c++ include file that was causing the problem and now i get this error when i try to compile a simply c++ file

usr/lib/gcc/ppc-amigaos/11.1.0/../../../../ppc-amigaos/bin/ld: Dwarf Error: found dwarf version '5', this reader only handles version 2, 3 and 4 information.
/usr/lib/gcc/ppc-amigaos/11.1.0/../../../../ppc-amigaos/lib/clib2/libstdc++.a(ext11-inst.o): In function `_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC2EP4FILESt13_Ios_Openmodej'

And i have restored that include file.
Previously i had no error but lseek in clib2 was called with third parameter with a non sense value.
Also that dwarf error is not so clear to me..

@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.

@afxgroup

And follow instructions on the GitHub page.

@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.

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.

when i've seen this kind of error before it's because there are duplicate symbols, and the compiler and linker differ in which one they give priority to. what happens if you globally change the name of the function?

@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.

@alfkil
Yeah, tested your test case, exactly 2 different addresses on my x5000 as well, and the test case compiled via GCC 11.1 + latest SDK... But at least you have a test case! That half of fix :)

@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!

@alfkil
I'm currently working on adding proper share-group handling to ogles2.library.
This might be of interest for you and your QT6 project because it should allow sharing of textures etc. among contexts which didn't really work until now.
When I say "should" I actually mean "likely it already does" with the latest wip version 3.3. I guess I'm done but it's not really tested yet

There's a new aglCreateContext2 tag OGLES2_CCT_SHARE_WITH <ogles2-context-pointer>. This optional tag instructs ogles2 to share the same internal Nova-context (with a different render-state-object) and the same set of textures, VBOs, shaders and shader-programs of the given other gl-context.
So you create context 1 and then use its handle with OGLES2_CCT_SHARE_WITH for the creation of another context. The number of sharing contexts is unlimited and you e.g. may destroy context 1 and the resources will still be available for context 2. And the handle of context 2 can of course also be used to create another shared context.

Check it out (if you don't have an account there, contact Matthew to get one):
http://www.amiga.org/developer/bugreports/view.php?id=896

@alfkil

Uncertain, but I spent some time to download Qt's Repository (82
repos) and when I compare it with your repo I wonder if you are
missing some repos/part of repos for instance webkit is not only
webkit it is Qtwebengine-chromium, Qtwebengine, QtwebView,
qtWebSocket's, qtHttp, QtWebKit, QtFTP... some are purely IMO
test/development modules but if they repracated they are put into
the qt5-compat library which is also missing in your repo IIRC
in Qt4 the Qt3-compat library was very important, and so in Qt5
the Qt4-compat is/was very important.

My Qt 6 Folder is 3.24 Gb in Size
Your Qt6 Folder is 512 Mb in Size

alot can have been missing in those Gb's to make it uncompilable.

@trgswe

I know all this. I have most of the modules, you are mentioning, in ready-built versions on my linux hd. I was able to build qt-creator, which needs the Qt5-compat library, so I am pretty sure, that everything I did has been set up correctly. The only problem, in fact, seems to be the link error I have been talking about and just a few other things, for instance qmake doesn't work natively yet.

If we could fix the link error, I would be able to proceed.