@All All rebulds, those errors gone, but now same errors happens in the libicu libaries (at first in the libicui18n.a): Quote:
/usr/local/amiga/ppc-amigaos/SDK/local/newlib/lib/libicui18n.a(decContext.ao): In function `uprv_decContextSetStatus_46': decContext.c:(.text+0x4c4): relocation truncated to fit: R_PPC_REL24 against symbol `raise' defined in .text section in ../Tools/OWBLauncher/CMakeFiles/owb.dir/MorphOS/main.cpp.obj collect2: ld returned 1 exit status
What mean need to rebuild all libicu libs now with same -mlongcall (and, i fear all the other libs i link with may need the same rebuild with -mlongcall in end..)
@Fab Thanks for, it through bring few warnings:
Quote:
WARNING: Option --enable-demuxer=aac_latm did not match anything WARNING: Option --enable-decoder=pcm did not match anything WARNING: Option --enable-decoder=wav did not match anything WARNING: Option --enable-demuxer=vp8 did not match anything WARNING: Option --enable-demuxer=vp9 did not match anything
But all other options ok, builds fine and size of final ffmpeg libs now reduces pretty much:
libavcodec: full: 70mb , your: 20mb libavdevice: full: 257kb, your: 80kb libavfilter: full 6mb, your: 1mb libavformat: full 28mb, your: 3mb libavutil, libswresample and libswscale: mostly the same as with full build.
As for -lmlongcall, google still says that code with it bigger and as result slower, but if it make no visual differences for your tests, and other solutions is ugly hacks, then will just do as you do for mos.
latm is in 2.0 but perhaps it's been renamed. As for wav and pcm, there's so many options I can't tell you which ones to use.
I was going to say libvpx_vp8 and libvpx_vp9 but then I realised that's probably not the same as vp8 & vp9 without the libvpx prefix. There's probably internal decoders for it, and of course you'd want to use them to keep filesizes down and reduce the amount of dependencies.
@Mick I use the latest ffmpeg snapshot (that one which we discuss with you week ago), which about the same as Fab use in 1.23, so i think the lines he post should works on version i have, just maybe something changes somewhere ..
Also libavcodec.a of 20mb is seems a bit big anyway.. Just want somehow to make it all in bounds of original mos binary (i.e. 50-60mb with mediaplayer), not something around 100mb :)
@Fab Which version of icu libs you use for now ? I just checked icu downloads, and last one are 52.1 and size pretty fat as well. In 1.17 readme i see you do update to ICU 4.9.1 is it version you use now ? Also that "the data files are now stored externally in PROGDIR:resource/icudt49b/ to save some memory. Make sure to copy them if you update (a requester will warn you if you don't).", so it mean some specific changes in code of libicu too and if so, can you share them too ? I can of course build version 4.9.1 all statically, but binary will be again bigger then..
If you've got a binary from a previous build (where all internal demuxers/decoders are enabled), then you can use "ffmpeg -formats" (and -codecs / -decoders) to get a list of the proper names, and then you should be able to use them on the configure line.
To me this binary size question hangs on this: if displaying an image puts away RAM for as long as the browser is running, then the binary size needs to be as slim as possible.
@Thematic Binary should be small in any case, just for more or less fast loading: 50-60mb is already not small, but as far as i see morphos version of 1.23 with mediaplayer are 53mb of size, so should be 60mb max for os4 version.
@ddni Need to deal with libicu now (and maybe some other libs will need rebuilding with mlongcall as well), as well as deal with ffmpeg to have it really 5mb of size, as well as deal with mediaplayer after binary will links and usuall os4 specific parts will be fixed.
You probably compiled ffmpeg with debug enabled (-g). That makes them way bigger.
About ICU, i still use 4.9.1. There's no reason to update, and it's so boring to build i prefer doing it as rarely as possible. If the data files are external, that's because there was some issue that prevented the big libicudata containing all data files from working properly (possibly a bigendian issue with their weird custom elf loader). And since libicu is so smart that it crashes as soon as a datafile is missing, i had to check for every datafile. But this code is in Odyssey itself, not in ICU, so you don't need anything else.
You probably need to add --disable-debug for next ffmpeg releases as well.
@Fab But even with such small size, libicu still scream about:
Quote:
/usr/local/amiga/ppc-amigaos/SDK/local/newlib/lib/libicui18n.a(decContext.ao): In function `uprv_decContextSetStatus_46': decContext.c:(.text+0x4c4): relocation truncated to fit: R_PPC_REL24 against symbol `raise' defined in .text section in ../Tools/OWBLauncher/CMakeFiles/owb.dir/ MorphOS/main.cpp.obj
So seems -mlongcall need it for that one anyway, as well as dunno about those ffmpeg erros on configure stage:
Quote:
WARNING: Option --enable-demuxer=aac_latm did not match anything WARNING: Option --enable-decoder=pcm did not match anything WARNING: Option --enable-decoder=wav did not match anything WARNING: Option --enable-demuxer=vp8 did not match anything WARNING: Option --enable-demuxer=vp9 did not match anything
I currently will worry with libicu/mlongcall recompile, just to have binary links in end, and then will back to those ffmpeg warnings when will worry with mediaplayer.
Is it necessary to do that when I strip my binaries? As for the ffmpeg libraries, any binaries linked against it can also be stripped. Most of the time libraries can be stripped after the fact too (there are some cases where "strip" has problems doing this to libraries). Isn't it better that they're not stripped? Odyssey can be a special case.
I can't remember if ffmpeg & libs are compiled with -g by default or not, but I'd rather not change anything.
If --disable-debug does more than remove "-g", than I understand that it can bring the file size down more so than "strip" can, but if you're building the libraries yourself then you can do that. I think it serves a purpose leaving it how it is, with Odyssey being a rare exception.
--disable-debug remove -g yep. And for binaries its enough to do striping, it will remove it too, but as you also want to release libraries for SDK (those lib...a from ffmpeg), then on them strip will not works, and big fat .a files will be in archive, while, with --disable-debug that info will not be inside of lib...a files => small size of them. With binaries striping of course can do the stuff, but just have big .a in SDK make no sense if they contain info no one need in general )
@tlosm Quote:
better compared with Putin
Or with Smutin :) Seriously, i just do boring re-compile work of what Fab do, there nothing cool to be honest. Its even sad, that we do not have any developer on os4 who can do browser from scratch as Fab do :)
And since libicu is so smart that it crashes as soon as a datafile is missing, i had to check for every datafile. But this code is in Odyssey itself, not in ICU, so you don't need anything else.
But then libicu should be builds without static data build in libicudata.a ? Previously i have libicudata.a 17mb of size, now as all the stuff you use externally there should be something like making all that data shared or so ? Currently my mega-line is:
ICU for C/C++ 49.1.2 is ready to be built. === Important Notes: === Data Packaging: static This means: ICU data will be stored in a static library. To locate data: ICU will use the linked data library. If linked with the stub library located in stubdata/, the application can use udata_setCommonData() or set a data path to override. Building ICU: Use a GNU make such as make to build ICU. checking the version of "make"... 3.81 (we wanted at least 3.80) ok
Which i assume wrong, and libicudata.a should be just some stub, as all the datafiles are external now ? Is there some magic options for configure which will do what i need ? Like "--enable-shareddatafiles" or so ?
I also have to deal with some TZNAME define, and as i on cross-compiler i also build x86 version to have those "bins" which used to generate stuff, and put them instead of ppc ones to aos4 build, so that all works in end, and i have:
i also have that stubdata/libicudata.a , which is only 1kb , but search for udata_setCommonData() in Odysseys code, and didn't found it, so dunno if it right to use the same stub of libicudata.a or not.
[/OT] Haha, but Putin still the best compared to any other capitalist-bankers of the western €uro crap! [/OT]
@kas1e Quote:
Or with Smutin :) Seriously, i just do boring re-compile work of what Fab do, there nothing cool to be honest. Its even sad, that we do not have any developer on os4 who can do browser from scratch as Fab do :)
@samo Nope, and not only because i build libicu with static data in and need to build some stub to avoid +17mb of binary (which is pretty much a lot), and because with new libicu which i build now, it mean new includes , and new names of functions with different prefix in compare with what i use previous, what in turn mean : recompile of almost whole odyssey with new icu includes again ! :)) feel the pain :) Recompile already starts and should be done tomorrow if nothing will going wrong with new icu includes. Then binary even with that useless 17mb libicudata should be done and later there will need only recompile libicu to be small, or maybe just to reuse that libicudata.a stub of 1kb, dunno for now.
Nope, and not only because i build libicu as static and need to build it shared to avoid +17mb to binary (which is pretty much a lot), and because with new libicu which i build now, it mean new includes , and new names of functions with different prefix in compare with what i use previulsy, what in turn mean : recompile of almost whole odyssey with new icu includes again ! :))
My full solidarity .. for sure recompile all anytime you update somethings (or you make a mistake) might be a very boooring job .. In my little world i had the same problem with my little "just recompile" projects, but of course their are not a monster like OWB ..
Aniway a curiosity, are you recompiling with the latest LibICU of you are coming back using the same old version used by Fab ? Probably it would be exactly the same for end users, but maybe not ..
Quote:
(should be done tomorrow if nothing will going wrong).
Great .. once the first binary will be done it would be pretty interesting to check if the video part will work as is (using cybergraphics emulation) or not, then of course the speed of them under our little machines ..
Aniway a curiosity, are you recompiling with the latest LibICU of you are coming back using the same old version used by Fab ?
I do it like Fab to avoid any problems and mess in which very easy to bring yourself. Check any morphos version starting from 1.17: You will found there Resources/icudt49b/ directory 17mb of size, that is that what we have previously in libicudata.a , which was attached to main binary (same as it was before on morphos till 1.17 of course). Then , since 1.17 all that icu data-stuff go out external to that place , and all necessary code to handle all those files are in odyssey now. So making a mess with new versions of libicu while we all know how it all done, will make big, fat, unnecessary and wrong mess without needs.
In other words all logical, you can be sure :)
Quote:
Great .. once the first binary will be done it would be pretty interesting to check if the video part will work as is (using cybergraphics emulation) or not, then of course the speed of them under our little machines ..
I assume it will crashes right away :) And because of needs to open somewhere some more interfaces, and because there somehow will be again differences with os4/mos of how they handle some datas , and because cybergraphics stuff will not works (as our cgx emulation includes is not full, i generate my own based on morphos's FD files for "cgxvideo" ). Will it works, or not to be seen, but i assume not. At least overlay i think will not and p96 replacements will need.
@all Binary done, current size 82mb. -20mb of static libicudata which shouldn't be there = 62mb. And 9mb of differences with morphos version can be debug in all other 3d party libs i link with. So making it about the same of size as on mos will be done.
But, as it was expected, it crashes (like again anyone think it will not:) ). Crashlog looks like this:
Quote:
Crash log for task "OWB" Generated by GrimReaper 53.16 Crash occured in module newlib.library.kmod at address 0x01B77874 Type of crash: DSI (Data Storage Interrupt) exception
Seeing crash it's about png decoding, i assume because on mos version fab use shared versions of png.library and jpeg.library, but through it should works as i fix them the same as in 1.16 before, by making empty libraries/png.h, and proto/png.h in which i just include <png.h> so to use it as static. Time for boring time wasting , again !:)
News feed
OS4 Feedback forum
OS4Depot Feedback 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
Donate
