@Georg

Thanks for your thorough code review. I will do an update and brush over as soon as that seems timely. For the time being, I have just done the code as quickly as possible for things to function minimally. Of course I need to brush over things, when everything is up and running. Thanks! :)

@thread

Has there been a discussion on rpaths?? It seems to not do anything to the linking process, when stuff is added here, and it would be quite useful to have this feature for qt programs.

@trgswe

I have checked the specification, and you are absolutely right, that it doesn't specify anything along the lines of what I am suggesting. This doesn't mean, though, that there are not some kinds of interpretive discrepancies present in the actual implementations (the build/runtime linkers respectively). I will probably have to check the compiler sources themselves (dreadful...).

@thread

Thanks to all who supported! And sorry for the sound issue!

I will spend the next weeks fixing up an SDK for release. Once I succeed, I will test everything thouroughly and then do a fresh stream. Sounds issue has been fixed.

The setting for age restriction has been changed, but sadly the on-stream chat has been lost. :(

@emeck

Thanks! It works up, but I screwed up the link, so the new stream is here:

Qt 6 Stream on YouTube

@kas1e

I don't know how to turn it on. I am in YouTube Studio, and the options for chat are shaded. :(

@trgswe

Thanks, that's really useful info! I really want to check it out, because I think there is some problem in this, that we need to fix. Building and running the shared version of Qt should be elementary and not elicit problems like this. By the way, I have a workaround, that consist in reverting to the old (Qt 4 and 5) notation for QObject::connect(), and this shows, that my theory is explanatorily correct in at least some respect.

@trgswe

That's not what I meant. What I am saying is, that linux and gcc might have updated their symbol interpreter. Maybe the AmigaOS runtime linker (the code responsible for linking exe and .so at runtime) is behind in some respect.

@George

You are exactly right. And that's why my theory is, that there has been some development in the interpretation of the elf binaries in later gcc versions. The AmigaOS runtime linker doesn't know about these and interprets them spuriously. The strange thing is, that it doesn't complain, that there is multiple instances of the same symbol. This hints at some peculiarity in the case. I think, that it is doubtful, that we are going to find a solution without having someone look at the runtime from the inside. ':(

Found this :

Article

It states the following :

Quote:

It is quite hard to understand the "does not change the current section to .bss" part. Why would it not do that? Perhaps this the clue to the 'solution' to the above - that the AmigaOS linker doesn't interpret these correctly by instead give priority to the empty version of the structure.

Ideas??

@kas1e

Yes :).

@thread

Guys, I need help again. There is some obscure link problem along the lines of the discussion link i posted above. I have a hard time pinning down, what needs to be done, but basically it seems, that the template functions of parent classes in libQt6Gui.so and libQt6Widgtes.so are not linked to the meta objects in the classes of the app. For instance, in textedit.cpp we have



This is done using QObject::connect(), which is defined like this :



Notice, that the staticMetaObject is located in the moc code of QTextEdit, which is part of libQt6Widgets.so. When linking statically ( - this is the hypothesis - ) the reference goes through, and the signal will be connected. When linking dynamically, this for some reason breaks.

The strange thing ( and now it gets really hairy ) is, that when you look at the symbol table of the textedit executable, you have this :

Quote:

And the symbol table of libQt6Widgets.so :

Quote:

This part, I don't understand. Please help me out! :)

EDIT : To abreviate - .bss is an empty, non-initialized line of data-bytes, whereas .data is a line of data-bytes initialized by set values in the data-segment of the object.

This is really strange, because what appears to be, is that an empty structure has been allocated for the staticMetaObject in the executable code, whereas it should have been linked to a set structure in the .data section of the libQt6Widgets.so shared object.

Could this be confirmed by anyone familiar with the concepts? Is this a strange compile bug, or is there some logical explanation/solution??

Thanks all! :) I have scheduled the stream like this :

Qt 6 Live Stream on YouTube

@all

Cool! So good to see so generous backup. I promise, I will do a good stream :).

I will, as Walkero suggests, use YouTube to stream instead of Twitch. I think this solution is better for my linux setup. The service has not been set up for broadcast yet (there is a 24 hour initiation pause). As soon as it is ready to broadcast, I will send suitable notification.

@ thread

Guys - I want to do a streaming event. I haven't set up anything technical yet (apart from testing the physical equipment), but I have decided on a date and time :

Saturday December 4th at 16:00 (4 PM - GMT +1)

Let me know, if that suits you. If you are interested in taking part, of course. It could be cool to gather at least a few people, and with the time frame in order, I would try and have a finalized product, so for enabling people's own experiments.

@kas1e

I am pretty sure, that at least IExec and IDOS are included in the startup code. So it would mean trouble, if I defined them by hand.

I am doing a shared build now to see, if it solves some of the problems with linking the web engine. I am so sure, that it will, that I am ready to take on problems with the amiga build. I am guessing, that they will mostly be related to paths.

EDIT : To answer my own question - I found this line in the CMake complex :

Quote:

It basically tells the linker to complain about undefined symbols. The symbols mentioned above are all included in the amigaos specific startup code, so the linker needs to disregard those.

EDIT : I think we have been here before :

rpath-link

It seems, that the dynamic linker doesn't read the rpath. Can this be confirmed??

EDIT : After manual assign, this is the result :

emutls

.. which is because of this :

libstdc++.so has wrong version

If I copy libstdc++.so and libgcc.so from adtools (build version 11) it links correctly. But sadly the unix path module (-lunix) seems to have stopped working (same as -lauto, I guess). Is there any good way to re-enable unix paths?? It is quite essential for not having to change entirely the way Qt 6 works...

EDIT : So, the problem was not with -lunix after all - as a matter of fact this works quite well. No, instead it was a missing reference in qlibraryinfo.cpp :

Quote:

... has to be insterted for __amigaos4__ in that function.

Now, signals have a hickup when switching to dynamic linking. This phenomenon is discussed in this thread :

invisible dynamic symbols related to missing signals in Qt

@walkero

But -lauto doesn't work with dynamic linking, or??

EDIT : Ah, now I remember... These should be included in the startup code, right?? And because I am linking a library, this is not included by the linker. So what I am looking for is some flag to switch off warnings for undefined symbols...

Thanks for all the input. I will handle things with care.

Now : I have started building everything again, this time with dynamic linking. I have reached the point, where the linker complains, that it has undefined symbols like IDOS, IExec, INewlib etc.

Is there a generic solution to this, or do I need to set up manual code bits to open these interfaces manually? I am thinking IExec... and INewlib...

@ferrels & kas1e

Both are correct, and I have noticed the compiler switch. At this point, there are so many things going on, so many switches to keep track of, that even if I make it with an actual executable, it will be magical. And just to make it clear : I have not given up, I am simply giving it a break in fear of overload. There is plenty of time, maybe I will push it to next year, maybe, maybe... ;)

EDIT : And just to comment on the link - I am pretty sure, that the responsible is static vs shared. This should be fixable.

@virgola

Quote:

This is interesting. I definetely want to work out some more of the 3D bindings offered by Qt. I am watching this at the moment :

QtQuick3D

Only caveat is that Qt really wants to use the EGL layering libraries. It is quite rudimentary what we have in os4 ogles2, and that means doing a lot of stuff by hand, that ends up being quite complicated and work consuming. That, and the fact, that there seems to be bugs preventing workability (see earlier posts regarding ogles2).

@Skateman

Thank you very much!

@spotUP

Yes. It is quite large, you know... And lot's of potential loose ends. Like big endian not being supported in the renderer and the v8 bytecode generator. But hey, if we just dive in, it might end up in our ball park...

@pjs

Thank you Pj's! It is highly appreciated.

At this point, I think it best to take a break from the webengine and do some tricks with the actual Qt codebase instead. I will be aiming for some kind of preliminary release and a stream event within the next few weeks. Stay put!

@thread

Guys... I need help. I have built the entire chrome source base necessary for creating libQt6WebEngineCore.a. But there is some problem with the build system. Instead of being 256 MB large, it only comes out 900 kb, so obviously something has been left out. I am looking at the build files and ... it is quite complicated, because it uses a combination of CMake and the google build tool 'gn'.

If someone has the time to look at the repos and just give some kind of preliminary evaluation of what could go wrong with such a build. I am hair-raisingly close to being, ehm, tired. It would be so good to at least have a complete build before taking a break.

EDIT : This file should be responsible for the coupling between the two build systems :

CMakeLists.txt

Make sure to notice, that the chromium base is in submodule inside src/3rdparty.

EDIT : I think, maybe, that the Ninja is the problem. What do you think ?

Quote: