I've just push some changes that should (read more..) fix the shared objects problem. But something really strange happens.

Basically if I compile the library with DEBUG=true (means serial output) everything works correctly, while if I disable debug I have a DSI in printf (or however no output) when it try to use stdout because the f->position has a wrong value.
I mean if i use static linking or shared libc.so with DEBUG on f->position is zero. If I use libc.so with NO DEBUG f->position is 3539005. I'm pretty sure that position is zero when iob is initialized (there is a memset) but i've also forced all positions fields to zero..
I've checked inside #ifdef DEBUG and there is nothing that can be related to iob..
Which weird amigaos animal can cause this?

Yes. I remember the problem on gprof not generating correct code due the 0x100000000 but the problem seems different
Because even the linux one doesn't find the .debug_ranges section.
So even if you fix the problem with start address you will have something that is not working because a section seems totally missing

Well,
I've tried https://www.moneysavingexpert.com with Opera on Windows and the check is shown also there. So the problem is not on Odissey certificate or TLS. It is a check they have enabled. Something like "I'm under attack" but since JS code is not working on odissey the page doesn't work

Well, let's start a new thread.
I was testing grprof with clib2.
File are created correctly but if I try to use gprof on gmon.out I receive a lot of DWARF errors.



If I use the linux one i get this error:


So there is something that is causing a lot of problems in our generated exe files
Any hint?

great mate! Now let's fix the other problems :)

All Exec functions are optimized for CPUs. All newlib code is in Exec. So you have to use Exec functions since they are always optimized for the current machine. Maybe they aren't for x5000 but only kernel developers know

you could try curl and see if https is working correctly

Take a look at snoopy output

No. this is not working

@kas1e
package updated

@elfpipe

it is linked against amissl or openssl?

I doubt a virus for OS4 exists..
smartmontools is from 2005.. hope it will work. you should try smartctl and see what happens

You mean smart for amigaos for example?

Beta 8 released and changes merged into master

https://github.com/afxgroup/clib2/releases/tag/v1.0.0-beta-8

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

@joerg

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

@joerg

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

@joerg

Quote:
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:
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

Funny.. i've just tried both https://www.bhphotovideo.com and https://ko-fi.com/walkhero on Odissey with my Sam440 and they are working correctly..

I've tried almost all web sites I have on cloudflare and everything is working correctly. So most probably is something that is set Cloudflare side in those particular side that is raising captcha up. I suspect is something in SSL configuration (and Timberwolf test is the best candidate)
Unfortunately without having a web site that has that problem I can't check in the firewall why captcha is shown.
Maybe if @walkero has access to cloudflare could check what is wrong