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.
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.
@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..
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.
@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.
Well, I didn't use the longcall option without reason. The executable got too large at some point, and it couldn't be avoided without annoying hacks.
That being said, you're not forced to make it even 50 MB larger than required by linking the whole ffmpeg libraries. Just build the decoders/formats/parsers in the HTML5 specification, it will take less than 5MB then.
For instance, using the following options would be a good start: --arch=powerpc --cpu=powerpc --enable-runtime-cpudetect --disable-indevs --disable-protocols --enable-protocol=file --disable-network --disable-encoders --disable-decoders --disable-hwaccels --disable-muxers --disable-demuxers --disable-parsers --disable-bsfs --disable-devices --disable-filters --enable-decoder=aac --enable-decoder=aac_latm --enable-decoder=h264 --enable-decoder=mp3 --enable-decoder=theora --enable-decoder=vorbis --enable-demuxer=aac --enable-demuxer=aac_latm --enable-parser=aac --enable-parser=aac_latm --enable-demuxer=mp3 --enable-demuxer=mov --enable-demuxer=ogg --enable-parser=mpegaudio --enable-bsf=h264_mp4toannexb --enable-decoder=pcm --enable-decoder=wav --enable-demuxer=flv --enable-decoder=flv --enable-decoder=h263 --enable-decoder=vp8 --enable-demuxer=vp8 --enable-parser=vp8 --enable-decoder=vp9 --enable-demuxer=vp9 --enable-parser=vp9 --enable-bsf=aac_adtstoasc --enable-decoder=mpeg4 --enable-parser=mpeg4video --enable-demuxer=matroska)
Oh, and by the way, you probably won't even notice a difference between using longcall or not in an application like Odyssey. I didn't see any in benchmarks, at least.
@afxgroup Yep, i already tested it with dopus5 : whole dopus5 builds on my cygwin for about 30 minutes i think. On dopus5.org serv (which is just some common linux with more or less ok cpu) , build whole dopus5 for about 7 minutes. That for os4 version, os3 version builds even faster. Its and cygwin slower in few times, and cpu differences make sense of course :)
which cpu are you using? did you use the -j switch when compiling?
Of course all with -jX, it speed up things a little , but as i build it on cygwin on notebook which i just buy for some simple text work that just tells and speed pretty sucky. I thinking about build it on some of my remote linux servs, but repeat all the same steps now which i do in last days but on another serv pretty boring, so better just wait a day :)
@all Found that in morphos build -mlongcall also in use. So, will rebuild everything with it now (damn!). Through, that mean 1.23 will be slower somewhere. Dunno when -mlongcall start to be in use , but till 1.17 there wasn't. But as Fab add it then its all expected, so one more day till binary done as whole recompile starts. But for sure with -mlongcall things going to be slower (google says same). As well as attaching that huge-fat ffmpeg libraries will make loading of binary slower, too, as binary will be bigger.
@all Ok, so far all the linking errors fixed, everything ok, but, for making final binary there is one linking and fresh error remain (like anyone think it will be the same as with other versions:) ).
So, problem (i think) is the size of the final binary, when we use ffmpeg together with latest webkit core. ffmpeg static libraries by itself is about 100mb of size now (latest ones, even just libavcodec.a bigger on 20mb now), as well as all main odysseys static libs are about 80mb of size.
In end, when final linking is about to be done , it fails with such errors:
Quote:
main.cpp:(.text+0x130): relocation truncated to fit: R_PPC_REL24 against symbol `setjmp' defined in .text section in /usr/local/amiga/ppc-amigaos/SDK/newlib/lib/libc.a(stub_setjmp.o) ../Tools/OWBLauncher/CMakeFiles/owb.dir/MorphOS/main.cpp.obj: In function `create_application(char*)': main.cpp:(.text+0x374): relocation truncated to fit: R_PPC_REL24 against symbol `__getreent' defined in .text section in /usr/local/amiga/ppc-amigaos/SDK/newlib/lib/libc.a(stub___getreent.o) main.cpp:(.text+0x38c): relocation truncated to fit: R_PPC_REL24 against symbol `fwrite' defined in .text section in /usr/local/amiga/ppc-amigaos/SDK/newlib/lib/libc.a(stub_fwrite.o) ../Tools/OWBLauncher/CMakeFiles/owb.dir/MorphOS/main.cpp.obj: In function `open_libs()': main.cpp:(.text+0xa5c): relocation truncated to fit: R_PPC_REL24 against symbol `__getreent' defined in .text section in /usr/local/amiga/ppc-amigaos/SDK/newlib/lib/libc.a(stub___getreent.o) main.cpp:(.text+0xa74): relocation truncated to fit: R_PPC_REL24 against symbol `fwrite' defined in .text section in /usr/local/amiga/ppc-amigaos/SDK/newlib/lib/libc.a(stub_fwrite.o) main.cpp:(.text+0xaa0): relocation truncated to fit: R_PPC_REL24 against symbol `__getreent' defined in .text section in /usr/local/amiga/ppc-amigaos/SDK/newlib/lib/libc.a(stub___getreent.o) main.cpp:(.text+0xab8): relocation truncated to fit: R_PPC_REL24 against symbol `fwrite' defined in .text section in /usr/local/amiga/ppc-amigaos/SDK/newlib/lib/libc.a(stub_fwrite.o) main.cpp:(.text+0xac4): relocation truncated to fit: R_PPC_REL24 against symbol `__getreent' defined in .text section in /usr/local/amiga/ppc-amigaos/SDK/newlib/lib/libc.a(stub___getreent.o) main.cpp:(.text+0xadc): relocation truncated to fit: R_PPC_REL24 against symbol `fwrite' defined in .text section in /usr/local/amiga/ppc-amigaos/SDK/newlib/lib/libc.a(stub_fwrite.o) main.cpp:(.text+0xc14): relocation truncated to fit: R_PPC_REL24 against symbol `__getreent' defined in .text section in /usr/local/amiga/ppc-amigaos/SDK/newlib/lib/libc.a(stub___getreent.o) main.cpp:(.text+0xc2c): additional relocation overflows
And there is more , for almost all usual amiga functions from lib.a, and in all the objects.
All what i can notice while linking happens, is that it all reach moment when binary are 145mb of size (holy shit!), and then on moment when it all should be done, it fail with such errors.
I of course can think that stripping and co will help after all, and binary can be reduced to something more adequate, but, as far as i understand, all those errors happens now because of the size of binary.
All what i found currently is that thread: http://www.amigans.net/modules/xforum ... t_id=47726#forumpost47726 which in end mean "recompiling everything with -mlongcall", but problem that the code gets slightly slower then and so you know what results is.. I already do test if -mlongcall will help on one of objects, and it is, i can recompile everything with it, but it also mean code will be slower.
Any ideas / suggestions ?
Edited by kas1e on 2014/1/24 11:40:42 Edited by kas1e on 2014/1/24 11:43:20 Edited by kas1e on 2014/1/24 11:50:01 Edited by kas1e on 2014/1/24 11:50:32
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
