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 !:)
I think i got why it crashes: libpng12 should be used everywhere, and not libpng14. So i recompile cairo and pixman to use libpng12 instead of libpng14 (that was reasons to link whole odyssey with libpng14 now), as well as ported fresh libpng12 1.2.50.
Also i just tryed to link against libicudata stub library, and yep, it did the trick, binary now about 60mb. Need some time now to clean those things a bit.
So also in this case you are more or less "forced" to still using an old lib to avoid linking problems ? I mean LibPNG 1.2.50 is an old release right ?
While if i understand correctly we have an updated 1.6.8 release from MickJT that is the newest one
@samo79 1.2.50 is not old, its more or less new - July 10, 2012. Libpng is a bit mess in that terms, they have 2 (or even more?) different branches 1.2.x and other one which develops in parallel. And as far as i see, its webkit itself which use 1.2.x version and i assume there wasn't reasons for them to swith to 1.4 or whatever.
In other words, you imho think that "bigger numbers of libraries is better", but its not like this all the time, most of time, but not always: libicu and libpng good examples of opposite.
When i do fast ports, its offten happens that one or another use libpng12, while another ones libpng14, for that reasons i have separate libs with separate includes , etc.
To add, how it on os4depot with libpng now its a bit wrong, there should be 2 versions : that one which is more recent, and libpng12 as well.
check deeply that :http://www.libpng.org/pub/png/libpng.html if you in interest, some quote "Those who are happy with the current level of PNG support in their apps need not panic, however; libpng 1.2.x will continue to get security fixes for the foreseeable future"
Yep yep now i see .. Regarding versions infact also the LibICU team changed their internal revision number recently .. in latest release they start using a sort of "Amiga like" release numbers --> 52.x, 53.x and so on ..
But in this case atleast we have a single version with a single branch
@all Recompiling of everything with png12 fixed png-decoding problems as expected, and now owb quits because didn't found calltips.mcc (so can't create class autofillpopup). Good news is that Thore works on that class already, and that i can see in snoopy log that icu resources loads fine (what mean, my 1kb empty libicudatastub.a are fine).
For now will update curl, xml2, xslt, jpeg, rtmp, freetype, expat, openssl to be recent ones and debug-symbols-free.
Also still will be nice if anyone skilled enough can just re-implement spellchecker.library. It have just 3 functions:
Library done by Antoine Dubourg a.k.a. Tcheko, i can try to write him, but not sure if he will want to share code (i think as it in the mos now, even if he want he can't).
I like keeping the libraries unstripped, because it's mainly developers who will be downloading those archives and if a program crashes, addr2line can be used effectively. I also don't need to compile the libraries twice (and I do clib2 too), which would take quite a while when building natively. When a program is all working, I strip the binary.
Is it normal practice to disable debug (even in the Linux community) before uploading dev libs to a repo? Personally I'd prefer the symbols be left in.
Quote:
To add, how it on os4depot with libpng now its a bit wrong, there should be 2 versions : that one which is more recent, and libpng12 as well.
In the past I've been told by Orgin that he doesn't like multiple versions of the same software/libs on OS4Depot. I know libjpeg6b (and to an extent e-uae) is an exception. You or I could ask about libpng12, and you could upload your port as libpng12.lha
Edited by MickJT on 2014/1/29 7:11:53 Edited by MickJT on 2014/1/29 7:18:16 Edited by MickJT on 2014/1/29 7:22:09 Edited by MickJT on 2014/1/29 7:28:28 Edited by MickJT on 2014/1/29 7:48:59
Is it normal practice to disable debug (even in the Linux community) before uploading dev libs to a repo? Personally I'd prefer the symbols be left in.
Everyone do as they wish even on linux, but they mostly have "debug" and "release" in configures, so for release they strip debug symbols always.
As for debug symbols in ffmpeg, imho, you not need it there, as it mean to be "release" version where all works, and if some binary crashes for someone, then he add -gstabs for his binary, and can check where it crashes (till ffmpegs functions, of course). And then, if crash starts in ffmpeg, 3d party dev imho will not need to have debug symbols in ffmpeg itself, as if he can fix ffmpeg then he can build debug version later himself for test. But imho no one will go fixing ffmpeg if there will be bugs, so release version of them imho better as size will be much smaller, but result is the same.
That all not big deal in general, just 70mb of ffmpeg library its a bit huge :)
Quote:
In the past I've been told by Orgin that he doesn't like multiple versions of the same software/libs on OS4Depot. I know libjpeg6b (and to an extent e-uae) is an exception. You or I could ask about libpng12, and you could upload your port as libpng12.lha
Yep, i assume we need ask Orgin again, and explain why we need those 2 exceptions.
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
