The binary for Odyssey is huge - some 36 MB. Because it is >32 MB, its PPC FP op-codes can't be translated into SPE op-codes and it will have to run under emulation on the A1222.
36? It is 60 when unstripped, and almost 50 when stripped.
Quote:
Can you split part of the browser off as a library, to keep the largest binary down below 32 MB?
LibWebCore.a alone about 80MB when building happens. For granted that with debug info, but not sure if it will be less than 32MB.
I mean, of course, it is possible to make all the internal libs to be as shared/separate/etc, but not sure if we can go below 32, and more of it, it's huge-big-time-consuming work will be, that for sure.
But if anyone wants to do so, i can help with all info i know about it.
Perhaps Trevor should have thought of that before picking an awkward CPU chip or perhaps he can sponsor some work to bring an up to date web browser core to Amiga.
Perhaps Trevor should have thought of that before picking an awkward CPU chip
I don't think it was Trevor's fault: the CPU was most likely recommended to him. Possibly by the same genius who advised him to put the useless Xena/Xorro stuff on the X1000/X5000.
Advised by Varisys.. Good thing they have also pre-paid a 1000 CPU`s already At the same time we ordered and pre-paid for all the long lead time items including 1000 Freescale P1022 CPUs so we would have the key components available once we started the full manufacturing run.
The binary for Odyssey is huge - some 36 MB. Because it is >32 MB, its PPC FP op-codes can't be translated into SPE op-codes and it will have to run under emulation on the A1222.
36? It is 60 when unstripped, and almost 50 when stripped.
What matters for whether LTE can be used or not isn't executable size but how big the code segment is (".text" section in ELF files).
Running "ppc-amigaos-readelf -e" on the Odyssey exe it reports that the .text section is just a little over 33 MiB.
Running "ppc-amigaos-readelf -e" on the Odyssey exe it reports that the .text section is just a little over 33 MiB.
For me, it reports 210713c, ~35MB.
Do we need exactly no more 32MB, i.e. 31.9 will fit well or do we need around 30 and no more to be on the safe side?
Basically all we need then, and to make some of the 3d party libs be shared. The biggest ones which inbuild staticaly are: libicu libs : 11mbl libxml2: 2mb libjpeg: 1.5mb libfreetype: 1mb libsqllite3 : 1mb libcurl : 0.8mb libwebp : 0.5mb libxstl : 0.35mb libexpat: 0.3mb
While libicu ones looks as good case, they very hardcore crap and hard to build, etc and surely will be not very easy to make it be shared.
Imho the ones which should be not _that_ hard and which can be make as shared are:
So maybe for the test, we can build just libxml2 as shared. It will save us 2MB and we can see if SPE will deal with it. I do not have experience with creating true amiga libs. If it is easy enough and can be done fast, maybe you can grab the latest libxml2, make a shared library from it, and I can then build test odyssey binary and we will see how it goes?
If you look around I think you'll find there are already amiga-ized versions of some of these at least libxml2: 2mb libjpeg: 1.5mb libfreetype: 1mb libwebp : 0.5mb
We talk about real amiga libraries of _latest_ versions. Not 10 years old ones, or 68k ones. Exactly native amigaos4 xxxxx.library , which of the very latest version (which i use in Odyssey now).
For example, the only real amiga library of libjpeg i found is jpeg_lib from 24 Sep 2006. Absolutely no go. webp lib also from 27 Sep 2012, also no go. for xml2 and FreeType I found nothing on os4depot, only the same link libraries as I use.
We need _shared_ versions of _true amiga libs_ exactly of the latest versions of things i use now statically inbuild in the odyssey. Not sobjs, not link libs which all of us can /configure;make , but wrapped to the real amiga libs.
If I understand you correcly, you want to split the static linked library into a regular amiga shared library (.library) and a static linked wrapper library. The static linked wrapper library contains calls to the newly created amiga library. To make it a clean implementation, the static linked wrapper library must open and close this library each time the amiga library function is executed afaik.
In case of the jpeg library, you could also create a wrapper for jpeg datatypes.
@geennaam Yeah exactly. Link libs in this case will be a few bytes only, and whole real code in real shared amiga library. I do not know how internaly those library wrappers works, but from user pov you just open a library one time on running and close on exit (but internaly very possible that link-stub-wrapper will open it each time for each call).
You need to turn a shared private library into an amiga public library.
this bit of issue is public variables in staticky linked or shared objects is private to the program, that uses it. While public variables in Amiga library is public to all program that use the library.
So what you need is an instance to hold copy of “public” variables per application. instances can be allocated in the interface and the interface can be unique per program.
If global are stored in interface the data is also available to the application.
YourInstance = (struct YouInstance *) (((char *) (IInterface) - (IInterface -> data.NegativeSize)); YourInstance -> libGlobalVar = 33; (but you can hide “YouInstance -> “ with an macro.)
for some reason when I load up odyssey now I always get "initialising fonts". I cannot remember this happening before. Not sure what I have done / changed.
No big deal, but wondering why it is happening all of a sudden if it is not normal.
Thanks for all the work !
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.
for some reason when I load up odyssey now I always get "initialising fonts". I cannot remember this happening before. Not sure what I have done / changed.
Not sure if related to latest MUI5 or just Odyssey, but i can make the browser crashing at startup in this way:
1 - Using the latest MUI5 (expired) nightly build 2 - Launching Odyssey as usual by double clicks 3 - When the expired window popup appear on screen, instead of clicking to the Continue button, just pressing the Enter key
--> CRASH
What is strange is that if i press Continue in MUI expired requested, then Odyssey will be normally opened .. but instead it always crash if i press the Enter key instead!
But pressing Enter should be theorically the same as pressing the Continue button no?