No one, except for me, can recompile the AmigaOS 4.x newlib.libray, except for the very few people still supporting a company which changed their business plan into selling a pirated software distributions maybe (AmigaOS 4.1 FE and beyond, AmigaOS 3.1.x/3.2.x, a lot of that is based on stolen AmigaOS 4.x source codes, etc.). Even if Hyperion broke all of our contracts and I could simply ignore them as well as they do, even for newlib, the only AmigaOS 4.x software I was ever paid for, in contrast to them I still stick to the contracts I signed. But as long as there is no conflict with the newlib and AmigaOS 4.x NDAs I signed I'd help anyone creating a new AmigaOS 4.x port of newlib, no matter if it's an open source (BSD-like licences only, I'll never support any virulent licences like GPL/LGPL), or a closed source version.
Edit: 99% of the AmigaOS 4.x dependent parts of my newlib.library are based on the clib2 OS and CPU dependent source parts, I only fixed broken and extremely slow functions, but IIRC that were only about 5 functions.
Yes, but neither the time nor motivation to do a new port of newlib. Additionally it would be better if someone else does it since I did the original port for Hyperion, and even if I don't use any parts from that there would always be some doubts that I use them.
newlib is a portable C library for embedded and other restricted systems like Cygwin, similar to what OWB used to be for WebKit, therefore it's very easy to port.
Estimated time required for creating new AmigaOS 4.x port of the current version of newlib, without using anything from the old version (adding the required AmigaOS4 parts in the config and includes, but this time please use 64 bit integers for the I/O offset, time, etc. types, and implementing the OS specific functions): 3 hours. (libc.a and libc.so.4 only, for a newlib4.library.kmod more work is required)
The failed attempts to get libc_clib2.so working were very likely much more work...
But i've also seen that our eamigaos.c file is really old compared newer one. Even eelf32ppc.c file is more newer and doesn't has hardcoded stuff.
The AmigaOS4 parts were based on the RS6000 ones (especially the linker scripts, but probably other parts as well), if they are still maintained that should be the base of an update.
The failed attempts to get libc_clib2.so working were very likely much more work...
Beta 7 released has a working libc.so since months. The problem is when I try to use libstdc++.so because stream constructors are called before libc.so one and I get a DSI. Now my attempts to get that library to work, has broken something
Quote:
The AmigaOS4 parts were based on the RS6000 ones (especially the linker scripts, but probably other parts as well), if they are still maintained that should be the base of an update.
Linker scripts seems ok. They seems to contain all modern way to use constructors. So they should not be an issue And if you use gcc with -Wl,--verbose you will se the current one that is almost complete
The problem is when I try to use libstdc++.so because stream constructors are called before libc.so one and I get a DSI.
With the newlib libc.so there can't be such a problem because, just like the newlib libc.a, IIRC it only includes 2 or 3 functions and no constructors/destructors. The rest of the newlib libc are just stubs like int foobar(...) {return INewlib->foobar(...);} IIRC the newlib C library constructors/destructors are called inside the INewlib->_start() function, which is called by the crtbegin.c _start() function, and the C library constructors are called before IElf->InitSHLibs(elfhandle, TRUE), which is initializing libstdc++.so and any other .so used, and the C library destructors after IElf->InitSHLibs(elfhandle, FALSE).
That way using shared objects with newlib would have even worked if something was wrong in the binutils 15-20 years ago already... However if that would have been the case only very simple software using shared objects would have worked, but no software with complex .so dependencies like the shared object versions of OWB or the AmiCygnix QT.
Make sure when linking an executable using shared objects -lstdc++ is always before (the first) -lc, with correctly working binutils and elf.library it can only work in that order, if there is any -lc before the -lstdc++ crashing because of calling the libstc++ constructors before the libc ones is the correct result.
Well, the crashes I had in this days where caused by latest beta elf.library and i've just asked elfpipe to check. Regard my crash in libstdc++ unfortunately it is in the right order
==================================================
attempt to open /usr/lib/gcc/ppc-amigaos/11.1.0/clib2/gthr-amigaos-native.o succeeded
/usr/lib/gcc/ppc-amigaos/11.1.0/clib2/gthr-amigaos-native.o
attempt to open /usr/ppc-amigaos/SDK/clib2/lib/crtbegin.o succeeded
/usr/ppc-amigaos/SDK/clib2/lib/crtbegin.o
attempt to open /usr/ppc-amigaos/SDK/clib2/lib/crt0.o succeeded
/usr/ppc-amigaos/SDK/clib2/lib/crt0.o
attempt to open /tmp/cc0308en.o succeeded
/tmp/cc0308en.o
attempt to open /usr/ppc-amigaos/SDK/clib2/lib/libstdc++.so failed
attempt to open /usr/ppc-amigaos/SDK/clib2/lib/libstdc++.a failed
attempt to open /usr/lib/gcc/ppc-amigaos/11.1.0/clib2/lib/libstdc++.so failed
attempt to open /usr/lib/gcc/ppc-amigaos/11.1.0/clib2/lib/libstdc++.a failed
attempt to open /usr/ppc-amigaos/SDK/local/clib2/lib/libstdc++.so failed
attempt to open /usr/ppc-amigaos/SDK/local/clib2/lib/libstdc++.a failed
attempt to open /usr/ppc-amigaos/SDK/local/common/lib/libstdc++.so failed
attempt to open /usr/ppc-amigaos/SDK/local/common/lib/libstdc++.a failed
attempt to open /usr/lib/gcc/ppc-amigaos/11.1.0/clib2/libstdc++.so failed
attempt to open /usr/lib/gcc/ppc-amigaos/11.1.0/clib2/libstdc++.a failed
attempt to open /usr/lib/gcc/ppc-amigaos/11.1.0/../../../../ppc-amigaos/lib/clib2/libstdc++.so succeeded
-lstdc++ (/usr/lib/gcc/ppc-amigaos/11.1.0/../../../../ppc-amigaos/lib/clib2/libstdc++.so)
attempt to open /usr/ppc-amigaos/SDK/clib2/lib/libm.so succeeded
-lm (/usr/ppc-amigaos/SDK/clib2/lib/libm.so)
attempt to open /usr/ppc-amigaos/SDK/clib2/lib/libgcc.so failed
attempt to open /usr/ppc-amigaos/SDK/clib2/lib/libgcc.a failed
attempt to open /usr/lib/gcc/ppc-amigaos/11.1.0/clib2/lib/libgcc.so failed
attempt to open /usr/lib/gcc/ppc-amigaos/11.1.0/clib2/lib/libgcc.a failed
attempt to open /usr/ppc-amigaos/SDK/local/clib2/lib/libgcc.so failed
attempt to open /usr/ppc-amigaos/SDK/local/clib2/lib/libgcc.a failed
attempt to open /usr/ppc-amigaos/SDK/local/common/lib/libgcc.so failed
attempt to open /usr/ppc-amigaos/SDK/local/common/lib/libgcc.a failed
attempt to open /usr/lib/gcc/ppc-amigaos/11.1.0/clib2/libgcc.so succeeded
-lgcc (/usr/lib/gcc/ppc-amigaos/11.1.0/clib2/libgcc.so)
attempt to open /usr/ppc-amigaos/SDK/clib2/lib/libc.so succeeded
-lc (/usr/ppc-amigaos/SDK/clib2/lib/libc.so)
attempt to open /usr/ppc-amigaos/SDK/clib2/lib/libgcc.so failed
attempt to open /usr/ppc-amigaos/SDK/clib2/lib/libgcc.a failed
attempt to open /usr/lib/gcc/ppc-amigaos/11.1.0/clib2/lib/libgcc.so failed
attempt to open /usr/lib/gcc/ppc-amigaos/11.1.0/clib2/lib/libgcc.a failed
attempt to open /usr/ppc-amigaos/SDK/local/clib2/lib/libgcc.so failed
attempt to open /usr/ppc-amigaos/SDK/local/clib2/lib/libgcc.a failed
attempt to open /usr/ppc-amigaos/SDK/local/common/lib/libgcc.so failed
attempt to open /usr/ppc-amigaos/SDK/local/common/lib/libgcc.a failed
attempt to open /usr/lib/gcc/ppc-amigaos/11.1.0/clib2/libgcc.so succeeded
-lgcc (/usr/lib/gcc/ppc-amigaos/11.1.0/clib2/libgcc.so)
attempt to open /usr/ppc-amigaos/SDK/clib2/lib/crtend.o succeeded
/usr/ppc-amigaos/SDK/clib2/lib/crtend.o
/mnt/d/Sviluppo/Amiga/clib2/build/lib/libc.so needed by /usr/ppc-amigaos/SDK/clib2/lib/libm.so
found libc.so at /mnt/d/Sviluppo/Amiga/clib2/build/lib/libc.so
@afxgroup They way you are trying to fix the problem is way too complex and to much work for everyone involved.
Your clib2 libc.so doesn't work with C++, but if I got it right it's unknown if the bug is in your clib2 (for example the shcrtbegin/end.c data or functions for creating and calling the constructors/destructors arrays and functions), a bug in current versions of GCC, a bug in current versions of binutils, or a bug in the current beta elf.libray.
Using GCC 2.95.x or 3.4.x with binutils 2.14.x and an old elf.library is definitely working correctly. Try using those versions, if it still doesn't work it's a bug in clib2. If it does work with those old versions update either GCC or binutils to the current version, but not both at the same time. If it fails it's a bug in the GCC or binutils version you updated.
I'm pretty sure that sh/crtbegin/end code is working correctly. I'm reading that some people (not on amiga land) has a similar problem when using libstdc++.so. And I'm 100% sure that we had a problem with libstdc++.so. Even in the past with newlib we had problems. I remember very well I've always deleted libstdc++.so because there was problems with it and you can search the forum there and you will see This post is from 2011 but there are plenty of them. And at that time newlib was the only library that had .so files
@afxgroup At least the code on the Hyperion forum linked in the 2011 thread can't work, C++ exceptions (try ... catch) are not supported by my newlib port. At that time something was still missing in the OS4 kernel to be able to make it work.
Edit: Of course I didn't remove/disable those parts in newlib, it "just" couldn't work reliable without required changes in the kernel.
I don't think it is a "code" problem because if you use the static version you don't have any problem at all. The problems you have appears only when using .so version of the file
Does anyone know, if the openssl port on os4depot is supposed to work? Here I only get a full deadlock during runtime link. And this is with any version of elf.library counting from v53.27.
I had a drive, that came with the machine, and it grew tired after an intense session of repeated copying. I didn't know at the time, that the drive could get tired from this, so I ran an intense network test over the weekend, which would just repeatedly bang loads of data on it. Alas, the network algorithm passed the test, but the drive had to be changed.
So I bought a fresh drive, got it up and running with the os and all my old data on it. And then I knocked the machine over in an intense frenzy of going back and forth with a usb drive... It seemed to survive, but apparently it has started to allocate blocks, that might have failures. If I am lucky, I can have it live with a fresh hd. I would be rather grumpy having to buy another machine.
After having stashed my old Qt6 install on the (failing?) hd, I managed to run the test app with a fresh install.
I can get as far as this with https download :
Quote:
qt.network.ssl: No functional TLS backend was found qt.network.ssl: No functional TLS backend was found qt.network.ssl: No TLS backend is available qt.network.ssl: No functional TLS backend was found qt.network.ssl: No functional TLS backend was found qt.network.ssl: No functional TLS backend was found qt.network.ssl: No functional TLS backend was found qt.network.ssl: No TLS backend is available qt.network.ssl: No functional TLS backend was found qt.network.ssl: QSslSocket::connectToHostEncrypted: TLS initialization failed [### ] 0.0 bytes/sec Failed: TLS initialization failed
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
