I hope in libc.so because all *_CONSTRUCTORS are in libc.so and i'm using shcrtbegin/where __shlib_call_constructors and __shlib_call_destructors are and in the crtbegin I call InitSHLibs at start and at exit I've noticed also that libc.so and libgcc.so remain in use when using DEBUG=on (that works..) while they are unloaded with NO DEBUG....
I've just added sigsetjmp/siglongjmp to beta9 Also shared objects are working correctly now but you need a new elf.library (not yet released) that fix some problems. The new elf.library will resolve also this problem
I'm trying to make clib2 fully reentrant but I have a problem with setjmp/longjmp. If I declare jmp_buf __exit_jmp_buf; globally (like in classic lib2 version) I have no problem and the longjmp works correctly. But if I put it into my _clib2 struct that contains all variables, longjmp points to trashed memory. I suspect it is an alignment problem (or something worst..) I've tried to allocate the _clib2 struct with AVT_Alignment. I've also add pragma pack(2) but no luck. I've also tried to use a pointer to jmp_buf and then allocate it with AllocVecTags but always same problem. Any hint?
Well, yeh, I expect long jumps to happen locally in programs, not being shared by different programs / threads.
Like errono, you need a local store, its only accessible to that thread / library. is there not user data in exec task that be pointed to local store structure.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
But it is local. I mean it is defined in a local struct and passed via pr_CLibData like in newlib. So i'm sure it is local to that program. It isn't defined in a global struct shared by all programs that use clib2.library. That's why it is strange
nevermind.. i've fixed it. It was my mistake setting pr_CLibData in a wrong place..
Edit: Now i have a problem that seems something similar.
Basically if I use stdin/stdout/stderr inside clib2 code I have no errors while if they are used inside the C program (f.e. fprintf(stdout,"")) I have a DSI. stdin & co are pointer to the first three initialized iob in a clib2 constructor and for example if I use printf() that internally use fprintf(stdout) it works..
Beta10 branch now contains the clib2.library. It is not perfect 100% but thanks to the shared library now the old c++ bug with .so files has gone. It is 99% reentrant. I've tried to move all global and static variables but there is something more to test. Feel free to test it and report problems. I'll write an OS4 installer soon
@Andrea Good steady progress with clib2. It was worth a shot to start with, in the end of all.
With the latest screenshot, I feel myself dumb because as i see this is just a sockets' communication between server and client, but wasn't they working before ? Or they somehow multithreaded / multitasked / whatever , so i can try to build minetest with it ?:)
Keep in mind that clib2 now is a shared.library. So you need to install clib2.library into LIBS: folder (An installer is in the package)
There are tons of changes and fixes (and maybe new bugs..) The screenshots above was showing Unix sockets They are emulated via native sockets. You don't need to change any linux code to made them work. There are a couple of examples in the test_programs/threads folder. That was possible thanks shared library that is opening a lot of new possibilities. pthread mutexes functions now are using OS4 Mutex functions There are many new functions added (and usually tested)