Who's Online |
94 user(s) are online ( 19 user(s) are browsing Forums)
Members: 2
Guests: 92
walkero, Paul,
more...
|
|
|
|
|
Re: Qt 6 progress
|
|
Just can't stay away 
|
Quick question : Does anyone know, if the compiler tag -athread=pthread works? If yes, how to enable it? Currently it complains : Quote: /opt/adtools/lib/gcc/ppc-amigaos/9.1.0/../../../../ppc-amigaos/bin/ld: cannot find gthr-amigaos-pthread.o: No such file or directory
|
|
|
|
|
|
Re: Qt 6 progress
|
|
Just can't stay away
|
@afxgroup Quote: And the main problem is that _init function is called inside the program and instead of loading that one in libc.so it is calling that one present (and is wrong) in the exe file. So the constructors are not called and (for example) libstdc++.so crash because files are not opened. Please make sure, that you update elf.library before testing this. In the new version, the correct constructors should be called from the entries in the .ctors section, and there should be no need to double it. I'm not sure, if calling a constructor twice could be a problem (Qt does this), but better to make sure. The latest version of elf.library is 53.37. Are you planning on a new release of adtools? If you get there, please let me know.
|
|
|
|
|
|
Re: Qt 6 progress
|
|
Just can't stay away
|
@MigthyMax Quote: Just out of curiosity, TLS (ThreadLocalStorage) isn't required/needed by QT 6? Qt has some form of tls, but I don't know enough on the subject to give you the details. EDIT : Qt6 has some problem with threading at the moment. Apparently thread.wait() is called on the main thread, which is not good. I have troubles understanding, how this could be connected to dynamic vs. static linking. It works on static.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/30 16:46
#44
|
Just can't stay away
|
@MigthyMax Quote: That's great progress. Nothing is stopping you to continue with QT6, or? Well... There seems to be more issues with dynamic linking. Some ui functions are off, and they used to work, even with dynamic link. So I am off to try a different compiler version (most likely gcc 11) and reconfigure my Qt6 setup. One thing : I have a suspicion, that something is off with the Quote: tag in gcc. If someone can come up with a test and/or solution, it will be rewarded.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/30 14:03
#45
|
Just can't stay away
|
@afxgroup I can confirm, that OWB Blastoise still works, if libstdc++.so is replaced by an older version. Quote: regard my issue we are working on it. Basically we are changed all .so libs creation under adtools to use -use-dynld because at moment everything is linked against .a files and it is an error That sounds sensible. Looking forward to see the result.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/30 12:19
#46
|
Just can't stay away
|
@joerg
I have now tested OWN Blastoise. It fails, but this is probably due to the missing dependencies in libstdc++.so mentioned by afxgroup.
@afxgroup
Do you have an idea how to fix this?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/28 17:51
#47
|
Just can't stay away
|
@joerg
The problem was, that the current implementation of __shlib_call_constructors would fail (= yield an incomplete array of constructors).
The reason for this problem is not 100% clear. But at least it has to do with the fact, that the .ctors (and .dtors) section would somehow not read completely.
Doing an implementation inside of elf.library does the job. This secures, that the section has the right size, that it is thoroughly relocated and that NULL pointers inside the section is handled.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/28 13:39
#48
|
Just can't stay away
|
Voila. Quote: 11.STICK:ctor_test> test_dyn
ctor
ctor2
foo
bar
f 123
main result 123
dtor2
dtor
11.STICK:ctor_test>
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/28 12:55
#49
|
Just can't stay away
|
@MigthyMax
Ach, nein... Hopefully it was not because of a system update.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/27 11:02
#50
|
Just can't stay away
|
@MigthyMax Maybe there is one more lead for you. Quote: Relocation section '.rela.ctors' at offset 0x174c contains 3 entries:
Offset Info Type Sym.Value Sym. Name + Addend
10011040 00002301 R_PPC_ADDR32 100006f4 _Z4ctorv + 0
1001103c 00002701 R_PPC_ADDR32 1000076c _Z5ctor2v + 0
10011038 00000801 R_PPC_ADDR32 10000520 .text + 388 And : Quote: [12] .ctors PROGBITS 10011034 001034 000014 00 WA 0 0 4
[13] .rela.ctors RELA 00000000 00174c 000024 0c 24 12 4 So a .rela.ctors is of size 36 (0x24), which equals three (3) entries. BUT when calling elf.library on the file, it outputs this : Quote: [Elf32_OpenReloc] section size = 24, entry size = 12
[Elf32_HandleReloc] Trying rela section 13 for reference section 12 So only two entries. The missing entry is now the static_initialization function, that calls foo() and bar(). Why is there a difference in size here?? I think elf.library gives the correct output, because it seems to just chuck out what's on disk. So the theory is, that readelf is 'inventing' entries as it goes along. But how?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/25 13:37
#51
|
Just can't stay away
|
@MightyMax No need to worry about the specs after all. It was simply a missread of the debug output on my behalf. Everything runs as it should. Now, I have this : Quote: 3.Work4.1:STICK/ctor_test> test_dyn
foo
bar
f 123
main result 123
3.Work4.1:STICK/ctor_test> So this is a step in the right direction. What I am doing is just to look up the .ctors section and treat it as an array of (uint32 *) pointers to functions. So far - as you can see - the foo and bar functions are called. These are coupled in a single entry through a caller function. The .ctors section is 12 bytes long (0x0c), so three pointers. The two others are NULL. I am guessing, that these other two represent the ctor() and ctor2() functions. Apparently there is an issue with incomplete relocation. Is it possible that someone could assist in analyzing the readelf output to try and figure out, which kind of relocation is missing? Thanks! EDIT: As a matter of fact, it is worth to take a look at this : Quote: 3.Work4.1:STICK/ctor_test> readelf -s lib.o
Symbol table '.symtab' contains 22 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FILE LOCAL DEFAULT ABS lib.c
2: 00000000 0 SECTION LOCAL DEFAULT 1
3: 00000000 0 SECTION LOCAL DEFAULT 3
4: 00000000 0 SECTION LOCAL DEFAULT 4
5: 00000000 0 SECTION LOCAL DEFAULT 5
6: 00000000 0 SECTION LOCAL DEFAULT 6
7: 000000a8 56 FUNC LOCAL DEFAULT 1 _ZN12_GLOBAL__N_115foo_ct
8: 000000a8 56 FUNC LOCAL DEFAULT 1 _ZN12_GLOBAL__N_115foo_ct
9: 00000000 1 OBJECT LOCAL DEFAULT 4 _ZN12_GLOBAL__N_1L18foo_c
10: 000000e0 56 FUNC LOCAL DEFAULT 1 _ZN12_GLOBAL__N_115bar_ct
11: 000000e0 56 FUNC LOCAL DEFAULT 1 _ZN12_GLOBAL__N_115bar_ct
12: 00000001 1 OBJECT LOCAL DEFAULT 4 _ZN12_GLOBAL__N_1L18bar_c
13: 00000184 128 FUNC LOCAL DEFAULT 1 _Z41__static_initializati
14: 00000204 60 FUNC LOCAL DEFAULT 1 _GLOBAL__sub_I_lib.c
15: 00000000 0 SECTION LOCAL DEFAULT 8
16: 00000000 0 SECTION LOCAL DEFAULT 10
17: 00000004 80 FUNC GLOBAL DEFAULT 1 _Z3foov
18: 00000000 0 NOTYPE GLOBAL DEFAULT UND puts
19: 00000058 80 FUNC GLOBAL DEFAULT 1 _Z3barv
20: 0000011c 100 FUNC GLOBAL DEFAULT 1 _Z1fi
21: 00000000 0 NOTYPE GLOBAL DEFAULT UND printf
3.Work4.1:STICK/ctor_test> Apparently the assembler has discared the ctor(2) and dtor(2) functions (they are included in the assembly). So probably this is the reason for the two vacant spaces in the .ctors section. Now - why would the assembler discard entries? The entries look almost exactly the same as the entries, that are included (in the assembly).
Edited by elfpipe on 2023/1/25 15:00:12
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/24 17:03
#52
|
Just can't stay away
|
@joerg Quote: IIRC there is no code inside crtend.o and shcrtend.o, they only include the end markers of the constuctor/destructor arrays, the code for calling the functions is in crtbegin.o and shcrtbegin.o.
If there is a problem with crtend.o or shcrtend.o it can only be because of a wrong linking order, i.e. something is wrong in the specs file of GCC. This is good to know. There is definitely something wrong with the calling order, so now the question is just where. @MightyMax : Are you up for this?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/24 16:00
#53
|
Just can't stay away
|
@MightyMax @joerg
I am presently in a bit of a mess. I have fixed InitSHLibs, so that it looks up the .ctors section. This required fixing a bug in LoadSegment. So far so good. But now I get a deadlock when the app closes down, and apparently (from what I can gather from Sashimi, before it dies) InitSHLibs is called AFTER CloseElf, which is probably the cause of the deadlock.
I cannot see any place, that this can happen from inside elf.library, so I gather the crtend.o or shcrtend.o is responsible. I cannot produce a disassembly any of of these. Can anyone else produce a disassembly?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/23 13:07
#54
|
Just can't stay away
|
@MigthyMax Quote: I found where the __shlib_call_de-/constructors are "defined". they are part of the newlib c library and only present in the shcrtbegin.o file.
Can you post the source code for it here?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/23 12:56
#55
|
Just can't stay away
|
|
|
|
|
|
|
Re: libpng.so 14 there is a download link, thanks
|
Posted on: 1/22 18:18
#56
|
Just can't stay away
|
@white
I only have 12 and 16. Not sure, where this dependency has sneaked in.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/22 15:04
#57
|
Just can't stay away
|
@MigthyMax InitSHLibs calls __shlib_call_constructors. Well, we can conclude, that here again the amiga is trying to do a non-standard solution, that doesn't work. I would say, that the correct solution would be to scrap the __shlib_call_constructors function and do construction by looking directly at the .ctors and .dtors sections from within elf.library. What do you think? Look here : https://maskray.me/blog/2021-11-07-init-ctors-init-array
|
|
|
|
|
|
Re: libpng.so 14 there is a download link, thanks
|
Posted on: 1/21 10:58
#58
|
Just can't stay away
|
@white
I am glad to know, that the qt browsers work. Currently, as you might know, I have shifted focus from Qt4 to Qt6, and so there is not going to be more work done on the Qt4 stuff.
I can see, if I have the correct libpng on my machine. If I do, I will post a link here.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/15 12:09
#59
|
Just can't stay away
|
@joerg
I misspoke. The 'WebKit' I am refering to is the Qt wrapper around chrome. The build system here is very complex, and the less I have to mess with it, the better. The older webkit modules from previous Qt versions was no problem.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/14 15:48
#60
|
Just can't stay away
|
@Georg
You are completely right, and that was my first consideration. I originally planned to do Qt6 with static linking only.
BUT meeting the requirements of software, I want to build, changed my mind. I want to build qtcreator and webkit, and those build systems don't work with attempted static linking.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
