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.
Well, since constructors using .ctors now work just fine with newlib, it is definitely an issue with the specs, since (I am assuming) the compiler is the same.
Would it help you in any way, if I did the init_array implementation in elf.library real quick?
Would it help you in any way, if I did the init_array implementation in elf.library real quick?
By using an older elf.library, which still calls the __shlib_call_constructors/__shlib_call_destructors functions, it doesn't make any difference at all if the constructor/destructor functions are in .ctors/.dtors or .init_array/.fini_array instead. Of course the __shlib_call_* functions and shcrtbegin/end.c have to be updated for that, and the ld scripts adapted to it.
afxgroup's clib2 makes no sense at all, creating a new newlib4.(library|so) port would have been at most 1% of the work he put into his clib2.(library|so) until now, but in any case part of creating a C library for AmigaOS is implementing the required ld scripts for it, which he didn't do (yet).
If afxgroup doesn't want to, or doesn't have the time to, do the required changes in GCC/binutils the only other option would be to use the last know working versions of GCC and binutils, and that's GCC 2.95.x and 3.4.x (not 4.0.x or newer) and binutils 2.14.x, for his clib2 version for now. Of course even that requires updated clib2 parts in the ld scripts, but for GCC 2.95.x/3.4.x and binutils 2.14.x simply using a copy of the newlib parts of the ld scripts for clib2 works, which isn't the case for newer versions of GCC or binutils.
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.
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..
Just like for newlib, which is, and always was, open source (except for the very tiny AmigaOS 4.x parts).
Quote:
At moment my clib2 is more faster in a lot of parts compared actual newlib and has a lot of functions that newlib miss.
I very much doubt that since both newlib and clib2 are based on the NetBSD libc, just like any halfway usable AmigaOS C library always was, for example ixemul.library is based on the NetBSD libc as well. Unless you mean with "actual newlib" the last AmigaOS 4.x newlib.library version I ported more than 15 years ago, and not a current newlib version from https://sourceware.org/newlib/ ...
Just like for newlib, which is, and always was, open source (except for the very tiny AmigaOS 4.x parts).
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:
Unless you mean with "actual newlib" the last AmigaOS 4.x newlib.library version I ported more than 15 years ago, and not a current newlib version from https://sourceware.org/newlib/ ...
Yes of course I'm speaking about the OS4 newlib version and not the newer one
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
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.
Clearly we don’t care, everyone is bad, Amiga Inc is bad, Hyperion is bad, AmigaKit is bad, and Cloanto is bad, and so on, so what… we need to stop finding people to blame, take a break if you are not happy, do something else, but don’t stand in the way of people trying to enjoy there hobby. You feel angry about the company, and you don’t care about its users, clearly. It’s a shame, but while your grumpy and peeling wallpaper, some people try to find solutions.
It does not help that you are trying to be a gatekeeper, things are moving so fast in GNU, we are lagging behind everyone else.
you’re like everyone else you want to own it, it’s yours no one can touch it.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
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
Problem is that if you don't keep it to yourself. Someone will exploit it. This is unfortunately how it works in the amigascene.
Secondly, I personally don't believe in open-source. Bad coding gets copied because the copier doesn't understand half of it. It's IMHO the main reason why amigaos systems are unstable. Memory protection is just a gatekeeper for bad coded software.
However, I do believe in quality documentation with examples about how things are supposed to be done correctly.
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 see what you are doing here. And I can do that as well.
So you are suggesting that our tool chain is closed source? Because if it was open source, you don't need to spend time fixing it, right? It would have happened a long time ago.
Yes, Amigaos4 is in the wrong hands. But an Open source Amigaos4 would mean that within weeks there will be: -Amigaos4.2 -TheRealAmigaos4.2.1 -IKnowItBetterAmigaOSAllwayOneVersionHigher -AmigaOS4DoneRight -OneAmigaOS4toRuleThemAll -AmigaOS4-<insert your Favorite-ISA>
.ctors :
{
/* gcc uses crtbegin.o to find the start of
the constructors, so we make sure it is
first. Because this is a wildcard, it
doesn't matter if the user does not
actually link against crtbegin.o; the
linker won't look for a file to match a
wildcard. The wildcard also means that it
doesn't matter which directory crtbegin.o
is in. */
KEEP (*crtbegin.o(.ctors))
KEEP (*crtbegin?.o(.ctors))
/* We don't want to include the .ctor section from
the crtend.o file until after the sorted ctors.
The .ctor section from the crtend file contains the
end of ctors marker and it must be last */
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
}
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.
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
Since more than 15 years I didn't do any AmigaOS development any more, except for some bug fixes in my Enhancer Software parts.
