Qt 6 progress

Don't trust the documentation.. there is something wrong somewhere..

@MigthyMax

Quote:

From first view, it looks like the constructors are called. Also your note, that some are called while others not is valid. I could construct a test to 100% verify, that it is the case.

EDIT: Maybe the file binutils/ld/emultempl/amigaos.em is a possible target for out search?

@MigthyMax
Quote:I don't understand PPC assembler much either, but I implemented those parts for the AmigaOS 4.x C library. The main difference between the constructor and destructor functions is, or at least should be, that the functions are called in opposite order, depending on their priorities, i.e. you may have something like
constructor_function1()
constructor_function2()
...
main() code
...
destructor_function2()
destructor_function1()

If for example the constructor/destructor functions 1 open/close a library the constructor/destructor functions 2 need it can only work if the functions are called in the correct order like in my example above, if constructor_function2() would be called before constructor_function1() instead it would crash because of the not yet opened library in the constructor_function1(), and it's the same for the destructor functions.

Regarding constructor example, it seems that test_dyn works differently when built with -mcrt=clib2. It crashes with a very long stack trace (recursion?). GCC 11.2.

@Capehill
Quote:Ignore clib2, it shouldn't be supported at all any more by the AmigaOS 4.x SDK and adtools since about 20 years already. At least that, removing any support for clib2 in all AmigaOS 4.x SDK parts, was one of the requirements for me porting newlib to AmigaOS. I have a contract from Hyperion including that clause of course, but as anyone should know by now any paper with Hyperion contracts are worth less than used toilet paper...
The GCC version used in this case should make less difference than the binutils version used, especially ld. Don't expect any binutils version newer than the one included in the AmigaOS 4.0 SDK (not 4.1 or newer) to work correctly, there were newer, but utterly broken cross-compiler versions of binutils about 15 years ago already, but only the even much older, AmigaOS 4.x native versions did work correctly at the time AmigaOS 4.0 was released.

Another option to check what's broken in GCC and/or binutils is using VBCC and it's vlink instead, and compare the generated ELF binaries and constructor/destructor codes in them.
Unlike GCC/binutils VBCC/vlink should still work correctly.

@joerg

Quote:

Good idea! But i couldn't figure out how to call vbcc to generate a sobj with/or to let him
produce PIC code. Anyone know how to do it?

How much sense do this funny shared objs make anyway, with something as big as the QT libs? They are not really shared anyway in most important place (memory), only in least important place nowadays (disk). Only advantage is, that if new version of libs come out, the exe using them does not need to be re-linked statically.

How big is a simple QT gui sample program if linked statically? Size in memory will be somewhat similiar.

If you have same sample program but linked with shared objects then complete huge (I guess) QT shared objs used by program will end up in memory. If some stuff in the shared obj is referenced. Unlike static linking where parts (.o files) in the lib which are not needed do not end up in exe and later in memory. And if you start program twice or have other QT programs running then each will have their own copy of huge (I guess) QT shared objs in memory.

I think ... (I'm no AOS4 guy)

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

@elfpipe

Quote:At least for WebKit it should be no big problem. For some AmigaOS 4.x versions of OWB I used shared objects, but most were build using static linking instead, and for example for my m68k port, the AROS port and the MorphOS versions of OWB and Odyssey using shared objects wasn't even possible.

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

I tried to get a picture how constructors/destructors call works on AmigaOS 4 with sobjs.
I now more or less tried to understand what the method __shlib_call_constructors and __shlib_call_destructors perform in sobjs.
As long i see it they implement loops calling methdos from the .ctors / .dtors section. Similar to the methods
init/fini from afxgroup clib2 in the file crtbegin.c

So long so good. If a program needs sobjs, the used clib takes care to to call InitSHLibs from the elf library, which again
calls __shlib_call_constructors/ __shlib_call_destructors. Afxgroup clib2 does is like this. Because i can only sneak
in the clib from afxgroup, this is a guess for newlib and the default clib2.

My conclusion is now regarding the 139 bug is either the __shlib_call_constructors implementation is buggy, which i cannot confirm,
(BWT does anyone know where the code for this methods are generated) or the used clib library had the great idea to not use the
InitSHLibs from elf.library, but instead to implement a own process to call constructors/desctructors. Actually it can even be that
InitSHLibs is buggy and all clib calls it.

So I compiled the 139 test case with newlib and the default clib2 from the SDK. Using newlib behaves as reported, faulty. Using clib2
the dynamic compilation fails with an DSI during staring.

Thus can anyone compile the example with the clib2 from afxgroup and report back the result from running the static and dynamic version?

@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

@MigthyMax

Do you get the same problems with GCC 2.9.x and GCC 3.4.x and the binutils used by the AmigaOS 4.x SDKs with those versions?
IIRC anything newer never worked correctly and of course I didn't care care at all and didn't update newlib.library for GCC 4.x.y versions and beyond because none of those newer versions were available as native AmigaOS 4.x compilers/linkers at that time, only as cross-compilers I never used.

Sounds like there were changes in GCC and ld how the constructors/destructors arrays are generated and called and newlib and elf.library never were adopted to those changes...

For example for OWB I used a mix of GCC 2.9.x and 3.4.x, GCC 3.4.x only for the C++ sources which couldn't be built with 2.9.x any more, and there never were any problems with the shared objects OWB was using, and there were a lot of shared objects used by OWB, and not only the automatically linked .sos worked but the dynamically loaded video player and codes shared objects worked without any problems as well (except that they only were dummy implementations which I used for testing and which didn't do anything, the required video codec and player library used by OWB was never ported to AmigaOS).

@elfpipe

The link you posted, I have already found on my quest, but thanks anyway.

Thinking about the problem, the current state seems to be that InitSHLibs don't handle de-/constructor in anyway. It just delegates the handling to the __shlib_call_de-/constructors, which is a custom Amiga solution. Furthermore who/where is responsible for creating the __shlib_call_de-/constructors stubs/glue code is unknown.

Thus handling the calling of de-/constructor in the elf.library seems to the better solution and more in common how elf dynamic loading is handled on other OSes. Additional the elf.library could implement de-/constructor handling via dtor/ctor and even support for the newer variants, like init_array. So the sobjs/binutils could evolve to be more standard alike.
Eflpipe as long i know, you have access to the sources of the elf.library, so it is in your hands.


@joerg

I tried to compile the issue 139 from adtools with GCC 4, which failed with an error regarding the de/constructor attribute. I didn't followed that way any further. I switch the gcc to 11.

Bur it's good to know that in older gcc setups everything worked as expected, because currently I only focus on GCC 11 and latest ported binutils/latest binutils from GNU.

@MigthyMax
Quote:I implemented the newlib.library parts, maybe I helped with the elf.library code for it as well (not sure any more), but that was for GCC 2.9.x/3.4.x and even older binutils versions used for those AmigaOS 4.x SDKs.
That was about 15-20 years ago, it's very unlikely that anything of that still works with current versions of GCC and binutils.

@joerg

You are properly right. I couldn’t find the sources/patches regarding gcc 2/3. Do you know where they are?

@MigthyMax

Quote:https://sourceforge.net/projects/adtools/
https://sourceforge.net/p/adtools/code/HEAD/tree/branches/gcc/

@joerg

thanks. I thought github adtools is a one-to-one copy/clone of the sourceforge repo.

@elfpipe @afxgroup ....

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.

As with my experience during digging around in this topic, the shobjs support on OS4 is an custom defined solution, with interaction between the elf.library and the newlib. Or, you can name it even a none standard implementation. And as I see it newlib is the only c lib having these glue functions. So any other c lib implementation who wants to support the creation of shobjs needs to supply these glue function, to have it work with the current available tools. Thus currently my guess is, that the glue functions of the newlib has bug, which misses to call all presents constructor.

But going forward I'm with elfpipe, that custom glue code/logic in the shobjs should be avoided. And the dynamic linker (elf.library) should implement the various strategy calling de-/constructors, depending what is present in the so file. As long i oversee the elf standard and the amiga additions we have/cloud support the flowing variants:

a) The newlib __shlib_call_de-/constructors variant for backwards compatibility. Might be that it is not needed, because all shjobs file already have all information to support the next variant:
b) The .ctor/.dtor variant, which is elf standard. But even that is replaced with a newer variant:
c) The .init_array variant, which is "latest" shit on the elf side.

Going for the latest variants, would be really coll, because the needed modification to binutils would be minimal.

I don't know where it is the problem. But at moment this happens.

I create the .so using shcrtbegin/end.c files that has __shlib_call_de-/constructors. I've also tried to use _init and _fini instead of that function. In this case there is something that I don't understand.

Basically in the exe files there are _init/_fini defined in crtbegin.c files that calls constructors. And everthing works perfectly.
But if I try to use libstdc++.so/libc.so in this case libc.so calls always _init function but instead of calling that one present in libc.so calls that one present in the exe file and of course nothing works because libc constuctors are not called.

I don't know if it is clear.

Edit:
of course _init is defined in libc.so (I can see it using nm command)

1000fe40 T _init

Another piece maybe I forgot.
In exe file (crtbegin.c) I call before calling constructors:


But the constructors doesn't seems to be called. Or maybe libstdc++.so constructors are called early (before the libc constructors) and so I get a DSI