@elfpipe


This is the part of linker script (the .xs one) that is used at moment (same for .dtors)
Now the whildcard *should* include also shcrtbegin/end (I suppose even if the comment is vague)
So I don't understand why sections are in the libraries but empty
I've also noticed that .__preinit_array/.init_array/.fini_array and all other modern stuff is already there. So, linker side should be ok to use that sections and you could add them into elf.library.
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.
First of all i'm removing all hardcoded stuff and using amigaos.* scripts that are present in the ldscripts folder.
I'll keep you informed. However there is something wrong in our adtools for sure.

So all closed source is good coded, while open is bad? This was the 90's idea. Even Microsoft has open sourced almost everything. The problem on OS4 is we lack documentation, examples ad an OS that handles the problems. And in our situation we have to wait ages for a fix to be released. And trust me. If OS4 was open source we could have improvements and fixes very quickly. But OS4 is not ours. So we can't decide what to do. For example. Do you think that the fixed elf.library will be released soon? Honestly I don't think so..

I'd like to have you on clib2.. And of course your help is always indispensable..

Yes i know this problem very well. But even if you improve, fix and recompile your newlib version (that at moment of course is very far from the actual OS4 one) it will be useless since now it is a core os4 element that you can't simply replace.
That's why I started to rewrite clib2 to support OS4 only. To permit people and developers wants to contribute to have something that can be fixed and improved without any restriction.
But no one seems interested except few developers. So at moment this is what we have

Quote:
So it is useless for OS4 world since no one can recompile it. And since it is also an OS4 core library would be useless if not released by official channels

Quote:
Yes of course I'm speaking about the OS4 newlib version and not the newer one

my clib2 has only one sense. Anyone can update and use it without wating 10 years for a new newlib version. And since we are on OS4 world 10 years is also a good estimation..
Not only. At moment my clib2 is more faster in a lot of parts compared actual newlib and has a lot of functions that newlib miss.
However i'm still using .ctors/.dtors (so binutils doesn't need to be patched) with shcrtbegin/end but doesn't change (of course i've patched specs file and it is linking libc.so correctly). But while with static linking constructors *are present* with shared don't.

Honestly I don't know now. I've tried sop many things that I'm lost.. if you jump on skype or discord maybe we can go faster..

@walkero

No this site has the same problem

Honestly.. I'm to a dead end with constructors/destructors in shared objects..

objdump -s -j.ctors libc.so (or any other .so files) gives me always an empty section and so if I try to use the constructors inside libc.so the program crash because nothing is found

If I use libc.a of course everything works correctly.

Ah well, i tought the web site was yours. However can you try to spoof user-agent to something newer than odissey one?
Something like:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36 OPR/95.0.0.0

I've just tried this:

Open timberwolf:
load www.amigasoft.net -> it will work (nothing is shown up but it is a css/js problem)
load www.bhphotovideo.com -> it will show you an SSL error.

So most probably you have some strict SSL check on cloudflare that is causing this problem
You have to check in firewall area what is the cause of the error

The captcha appears because the user-agent most of the time. Check the firewall under cloudflare and you will see why the captcha is showing up.
Also. Which SSL configuration you have on cloudflare? Flexible? Or what?

But can you tell me what is the exact problem you have? Are you sure is not only a js/css problem?

I've just tried with some of my websites (https://www.animasystems.com and https://www.amigasoft.net) and they are working with odissey without any problems

Edit:
and they are behind cloudflare of course..

@elfpipe

Ok no problem. Since as I wrote adtools needs to be patched too.

@elfpipe

I've just tried the elf beta and I get no crash anymore. But while the static one works correctly (it prints some stuff in the console) the shared one doesn't print anything and exit.
I've checked with snoopy that .so files are loaded correctly by elf.library

@daveyw

You have to download a newer version of curl-ca-bundle.crt and replace the existent one (do a backup first)

no. I didn't change the linker scripts. But .init and .fini should be there and I get the same error. That's why I suspect it is a problem on both adtools and elf.library
However as I told in the post earlier the elf32-amigaos needs to be rewritten in my opinion (it lacks also .init/.fini part).
Check the mos one for example. It is totally different and more similar to newer one present on other platforms and it supports also .init_array/.fini_array:

no at moment i'm using a no-beta-test system with current adtools version and my clib2. But i think that adtools needs a lot of work to be compatible with latest changes in binutils.
BTW at moment:

clib2/libgcc/static works
clib2/libg++/static works
clib2/libgcc/shared works
clib2/libg++/shared crash because libstdc++ constructors are called before libc one

I'm trying to see if it is possible to fix this in clib2 at moment

I've just tried in clib2 to use .init_array/fini_array and .init/.fini and they both doesn't work. No costructors is called. Not only. It seems constructors are not linked at all.
So the problem is both in elf and adtools.