Qt 6 progress

@alfkil

If my and AOrganizer's math is right, it's 10AM Saturday
12/4 US Eastern time. I'd be glad to join. Dunno how
I can help, expect to be a user. ;D

Cool! ..in any case.

Thanks,

PJS

I'd like to be present (4 PM local tima - Italy).

+1

Yep, I'll be glad too to watch/see such stream!!!!

@alfkil

+1 :)

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

Qt 6 Live Stream on YouTube

@alfkil
You probably mean that one instead: https://www.youtube.com/watch?v=fOpTrd6gNz0 ?:)

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

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??

@alfkil

I wish I could help with this one but it's outside the scope of my abilities.

I don't know much about this shared objects in AOS4, but shouldn't they show up in exe as "undefined". In Linux

objdump -T `which kate` | grep -i staticmeta | grep -i lineedit

shows:

0000000000000000 DO *UND* 0000000000000000 Qt_5 _ZN9QLineEdit16staticMetaObjectE
0000000000000000 DO *UND* 0000000000000000 _ZN9KLineEdit16staticMetaObjectE

Maybe check with some other AOS4 programs which use shared objects, to see how the shared symbols in the exe appear there.

@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. ':(

@Georg

I don't think so... since linux and amigaos4 uses ELF as binary format they are compatible with one another, so linux can easily parse the amigaos4 exec.

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

@alfkil

I don't know enough about C++ but if I were dynamic linking a C program and had the issue you describe I would think that some structure had been declared 'static' in my program that should have been 'extern' .

@alfkil

Quote:

It's essentially saying that this symbol should be put in .bss with this much space. You would find lines like that interleaved with other code in the assembly output.

Using a really bad and probably not quite accurate ARexx analogy

address FOO

changes the address for all commands

address FOO command

only for that line.

@alfkil

that's not possible since it is defined in the ELF format documents (You can't define your own that easily), I would suggest getting this or similar documents

https://refspecs.linuxfoundation.org/

and look at elf.pdf (v. 1.2), elfspec_ppc.pdf (PPC Specifc and contains some DWARF information specific for the PPC), there are additional docs there (gabi41) that are interesting but not relevant (IMHO).

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

@alfkil
Will be youtube chat enabled today?:) So far seems disabled

@kas1e

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