C++ headers are provided with the compiler and not newlib/clib2.
Simply saying that something is missing from std:: namespace is not helpful for me as this is a C++ thing and not something that newlib (or clib2) can provide directly. More helpful would be to know what c library functions are missing that gcc needs in order to provide said feature...
I've already emailed you privately with some of the specifics.
While the C++ headers are provided with the compiler, they use our C stdlib headers. In a few cases we could just enable the missing definitions with a #define in config++.h. However, with cmath, enabling the #define in question results in a list of missing functions. That one was disabled for a reasion.
IIRC, you need to enable the following in config++.h: #define _GLIBCXX11_USE_C99_MATH 1 #define _GLIBCXX98_USE_C99_MATH 1
NOTE: Newlib and clib2 have separate config++.h
There are some other remaining defines that are disabled too, including ones related to wchar and complex number support. Ideally, we'd have everything in the latest C and C++ libraries supported.
Would it be easier to port latest Webkit for AmiCygnix ?
AmyCygnix is additional layer with its shortcomings and limitations. Fast and efficient browser should't have any big layers in between : it slow things down and bring issues of all sorts.
Edgar can be asked if he can port any browser which use WebKit to AmyCygnix.
Adding this here, before I forget about it. WebKit also uses posix_memalign(), and I just hit this again with another library. It's a POSIX function that would be very useful if newlib/clib2 supported (along with the new ISO C11 aligned_alloc() that will eventually replace it).
Those kind of function ideally can be of course in clib2/newlib, but they can also be in os4_funcs.cpp included and to be builded with.
Lets get those into clib2/newlib instead of creating an os4_funcs.cpp. With clib2, there's always the option of creating a temporary fork, and submitting pull requests to the master repository.
Volunteers are still needed to make it all happen...
Oh, once billyfish has figured out the mmap()/munmap() stuff, let's get that into the official stdlibs too. That way, Billyfish is the last person who will need to create a workaround...
Yes, we need an active maintainer for adtools (GCC and the C++ stdlib), and clib2/newlib. Jacadcaps encountered things that needed MorphOS kernel changes, so help from the OS4 dev team may be required either way.
my clib2 has already memalign/posix_memalign/aligned_alloc/valloc already implemented and (little) tested. And with new memoory allocator everything seems really stable and (most important..) fast I've also implemented mmap/munmap but these functions needs to be inserted in Kernel and handled by kernel not by c library. Our are only workarounds. Slow workarounds.. You should give a try..
Edit: And if someone helped, things could be faster...
It's not a requirement to get it built, but lack of kernel TLS support will hurt performance. That jacadcaps lists it in his porting doc tells you that the performance hit is probably quite sizable.
Quote:
But shouldn't it be possible to get things done in the kernel now, with Trevor being the owner?
Possibly.
@afxgroup Quote:
Edit: And if someone helped, things could be faster...
Absolutely.
BTW, is it possible to install your CLIB2 next to the official clib2? I can't seem to find the installation instructions.
@flash Since it is still in heavy development and not widely tested I wouldn't recommend it. But when this is stable and as complete as possible, I don't see why not.
But what I would like to see would be more people helping in that project. I wish I was experienced enough to contribute.
I am in the same position, but, help can be found by just using the library. I am using it in mednafen now and others. I can see, then, what things are missing in CLIB2 that I can report, or "attempt" to add. By using CLIB2 in larger projects, we can already help.
@hans
https://github.com/afxgroup/clib2. It should be a matter of cross-compiling. Installing it "somewhere" and then copying over the clib2 directory to your AmigaOne. Personally, I think I would toggle between the original clib2 and bleeding-edge by just using a soft link.
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.
It should be a matter of cross-compiling. Installing it "somewhere" and then copying over the clib2 directory to your AmigaOne.
I might be wrong but this is not so simple. You need to have the GCC compiled with that clib2 as well, otherwise, the generated binary is not working well. I tried it with one of my projects and although it compiled just fine, it failed to work. And that's what I understood by discussing it with afxgroup.
If you guys are interested, I could create a GCC version for AmigaOS 4 working with that clib2. But that won't happen yet, because afxgroup is on vacation and unavailable to provide some necessary changes for using shared objects. As soon as he is back, I can do those changes.
Now, it will - pull down SDK5334 instead of 5330 - use CLIB2 HEAD@afxgroup instead of the older version - change two trivial issues in the HEAD of CLIB2 (https://github.com/afxgroup/clib2/pull/67) - change the use of Reschedule() to be something else (SDK 53.34 made Reschedule private): https://www.amigans.net/userinfo.php?uid=133 - extract the SDK 5334 LHA properly, since it was changed due to execsg lha
The sed is crude, but it works for now. Going forward in this Makefile we should probably check that the user is using a "decent" version of LHA:
lha --version
LHa for UNIX version 1.14i-ac20220213 (x86_64-pc-linux-gnu)
CLIB2 is only used statically, but so was it previously during the build. So, SHARED=no is used in CLIB2 makefile.
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.