well, that means that it isn't find libstdc++.so. So most probably you should put gcc4 (iirc owb blastoise was compiled with it) in the same OWB dir.
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
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.
That's great progress. Nothing is stopping you to continue with QT6, or?
I think the solution from you performing de/constructors resolving in the elf library, without we need for the __shlib_call_de-/constructors in the c library is right solution. With this solution sobjs can be realized transparent to the used c library.
BTW, i ruined my setup with misspelled entry in the Kicklayout file, without having a USB rescue stick , and the 4.1 FE iso has no recent version of the gfx driver, .... But i can boot again. Now i have only somehow a corrupted filesystem
BTW, i ruined my setup with misspelled entry in the Kicklayout file
You should always have (at least) 2 kickstart entries in your Kicklayout file, and a copy of the SYS:Kickstart dir for it, for example in SYS:Kickstart/failsafe: - The one currently used (default). - An old one using known working versions of the kickstart files (using the kickstart modules in SYS:Kickstart/failsafe instead of the SYS:Kickstart ones). That way you can always boot and fix possible problems, not only in case of a misspelled entry, but for example in case a new version of a kickstart module doesn't work as well, which is a more common problem.
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:
__attribute__((section))
tag in gcc. If someone can come up with a test and/or solution, it will be rewarded.
One thing : I have a suspicion, that something is off with the
Quote: __attribute__((section))
tag in gcc. If someone can come up with a test and/or solution, it will be rewarded.
No idea if something is wrong in current GCC versions, but it used to work in GCC 2.95.x and 3.4.x. To check if it still works use something like __attribute__((section("foobar"))) int foobar = 1; and either check the assembler output (GCC -S foobar.c -o foobar.s), or readelf on the object file.
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
Unless I'm mixing something, or something changed in recent GCC/binutils versions, that's wrong and can't work. -use-dynld is for linking executables using shared objects only, crtbegin.o and crtend.o are used for linking. To create shared objects you have to use something like "gcc -shared foo.o bar.o ... -llibabc -llibxyz -olibfoobar.so" instead which will link with shcrtbegin and shcrtend.o instead. The code in shcrtbegin.o calls the constructor/destructor functions in the shared object.
Yes. This is another problem we found. In .so creation for clib2 crtbegin/end is used instead of shrtbegin/end and we we'll fix also this. 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. It is more easy to see that to explain..
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.
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.
Yes. This is another problem we found. In .so creation for clib2 crtbegin/end is used instead of shrtbegin/end and we we'll fix also this. 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. It is more easy to see that to explain..
Looks like the specs file wasn't update to support shared objects with clib2. You need an entry for -use-dynld linking using crtbegin.o (with the _start() function setting up argv[], interfaces, etc. and calling IElf->InitSHLibs(elfhandle, TRUE), main(), and IElf->InitSHLibs(elfhandle, FALSE)) and crtend.o and an entry for -shared linking using shcrtbegin.o (with the __shlib_call_constructors() and __shlib_call_destructors() functions) and shcrtend.o instead. Simply adding/updating the missing clib2 parts using the newlib ones should work.
Edited by joerg on 2023/2/1 15:20:30 Edited by joerg on 2023/2/1 15:20:51
It is working in this way. Except for adtools part that needs to be fixed. I've made some changes in my source (for example that oune you are wrote) but there are others things to do..
@afxgroup You don't need to update adtools for changing the specs, if no specs file is included in current versions you can use "gcc -dumpspecs > specs" to get the internal one. I don't remember in which gcc directory it has to be stored, though.
Yes. There is also a spec file on github with my changes but .so libraries in adtools are not created with -use-dynld. I think that there is something different to change somewhere
- After completion of the build I ran:
> find . -name "libstdc++.so"
./gcc-cross-build-11.3.0/ppc-amigaos/clib2/libstdc++-v3/src/.libs/libstdc++.so
./gcc-cross-build-11.3.0/ppc-amigaos/libstdc++-v3/src/.libs/libstdc++.so
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
