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...
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...
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..
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..
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?
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?
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 :)
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.
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.
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.
After reading an article about how linker and how dynamic loading is realized in the elf format, i thought about you problem. My first thought about your problem with the different address of the method, muts be that you get in the dynamic linked app, the address of the stub method of the PLT. So i started to investigate the C example at issue 109. First i took a look at the static linked app:
To have the correct address of the world method in the main method, the flowing relocation were present in the object file fr the main.c. The main.o file isn't build by the makefile , you need to build it by yourself with cc -o app_static.o -c main.c -L. -lhello -athread=single<[font=Haettenschweiler]world:
Relocation section '.rela.text' at offset 0x354 contains 6 entries: Offset Info Type Sym.Value Sym. Name + Addend 00000014 0000080a R_PPC_REL24 00000000 hello + 0 0000001a 00000906 R_PPC_ADDR16_HA 00000000 world + 0 0000001e 00000904 R_PPC_ADDR16_LO 00000000 world + 0 00000022 00000506 R_PPC_ADDR16_HA 00000000 .rodata + 0 00000026 00000504 R_PPC_ADDR16_LO 00000000 .rodata + 0 0000002c 00000a0a R_PPC_REL24 00000000 printf + 0
And its the second and third relocation, which is responsible for correct behavior in the static linking.
Thus my thought was that the relocation must be wrong in the dynamic variant. So taking a look at the relocation of dynamic linked app should reveal it:
Quote:
[0]>Work:Home/Workspaces/109>readelf -r app_dyn
Relocation section '.rela.sbss' at offset 0x2b8 contains 2 entries: Offset Info Type Sym.Value Sym. Name + Addend 010100d8 00000113 R_PPC_COPY 010100d8 __stdiowin + 0 010100dc 00000613 R_PPC_COPY 010100dc __unix_path_semantics + 0
Relocation section '.rela.plt' at offset 0x2d0 contains 3 entries: Offset Info Type Sym.Value Sym. Name + Addend 01001048 00000215 R_PPC_JMP_SLOT 01001048 printf + 0 01001050 00000315 R_PPC_JMP_SLOT 01001050 hello + 0 01001058 00000515 R_PPC_JMP_SLOT 01001058 world + 0
But as we can see the second and third last relocation are just the relocation needed for the main method to get the address of the world method and not as i thought the PLT stub function. You can verify that the relocation addresse the same instruction in the main method, with an objdump -d app_dyn.
As a conclusion, i don't think that it is an bug in the compiler. I think that it is a bug in the OS and how dynamic linkage of so files is implemented. I couldn't find ayn deeper information how dynamic so linking in AmigaOS 4 is realized, os it my conclusion is just a vague hint that the cause lies in the OS. But maybe someone more involved in the OS part can pick that and investigate it further,
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
Donate
