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
TuneNet forum
Unsatisfactory Software forum
Bottom
Previous Topic
Next Topic|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/27 5:28
#43 |
|---|---|---|
|
Home away from home
 
Joined:
2007/9/11 12:31 From Russia
Posts: 6820
|
@Fab
Quote:
Yep, ffmpeg add debug symbols by default and --disable-debug was need need it. In end, that what i have now: libavcodec.a: 4.2mb libavdevice.a: 3kb libavfilter.a: 175kb libavformat.a: 440kb libavutil.a: 380kb libswresample.a: 92kb libswscale.a: 330kb In summ ~5,5mb, cool. @MickJT 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:
So seems -mlongcall need it for that one anyway, as well as dunno about those ffmpeg erros on configure stage: Quote:
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. |
|
 
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/27 13:55
#44 |
|---|---|---|
|
Quite a regular
 
Joined:
2009/4/28 4:57 From Adelaide, Australia
Posts: 939
|
@kas1e
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. |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/27 14:27
#45 |
|---|---|---|
|
Quite a regular
Joined:
2013/10/5 15:07 From Italy
Posts: 624
|
@magnetic
Quote: kas1e for PRESIDENT! for sure him will be better compared with Putin |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/27 14:32
#46 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6820
|
@Mick
--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:
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 :) |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/27 14:43
#47 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6820
|
@Fab
Quote:
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: Quote:
Once configure done, i have: Quote:
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: libicudata: 20mb libicu18n: 7mb libicuio: 95kb libicule: 810kb libiculx: 150kb libicutu: 400kb libicuuc: 4mb 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. |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/27 15:50
#48 |
|---|---|---|
|
Home away from home
Joined:
2006/12/2 3:55 From Italy, Perugia
Posts: 3400
|
@tlosm
[/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 :) So you have a binary now ?  |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/27 15:55
#49 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6820
|
@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. |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/27 16:08
#50 |
|---|---|---|
|
Home away from home
Joined:
2006/12/2 3:55 From Italy, Perugia
Posts: 3400
|
@kas1e
Quote: 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 .. |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/27 16:27
#51 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6820
|
@samo
Quote:
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:
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. |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/28 6:31
#52 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6820
|
@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:
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 !:) Edited by kas1e on 2014/1/28 6:59:44
|
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/28 11:13
#53 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6820
|
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. |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/28 11:18
#54 |
|---|---|---|
|
Not too shy to talk
 
Joined:
2007/1/5 10:14 Posts: 262
|
Well done kas1e!
|
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/28 12:17
#55 |
|---|---|---|
|
Home away from home
Joined:
2006/12/2 3:55 From Italy, Perugia
Posts: 3400
|
@kas1e
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 http://os4depot.net/?function=showfil ... brary/graphics/libpng.lha Aniway, your daily progress is awesome |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/28 12:22
#56 |
|---|---|---|
|
Quite a regular
Joined:
2008/4/10 14:57 From Northern Ireland
Posts: 967
|
Yes, these regular progress reports are really appreciated!
|
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/28 12:30
#57 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6820
|
@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" |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/28 12:42
#58 |
|---|---|---|
|
Home away from home
Joined:
2006/12/2 3:55 From Italy, Perugia
Posts: 3400
|
@kas1e
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 |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/29 5:30
#59 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6820
|
@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: Quote:
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). |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/29 6:44
#60 |
|---|---|---|
|
Quite a regular
Joined:
2009/4/28 4:57 From Adelaide, Australia
Posts: 939
|
@kas1e
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:
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 |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/29 8:09
#61 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6820
|
@Mick
Quote:
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:
Yep, i assume we need ask Orgin again, and explain why we need those 2 exceptions. |
|
|
|
||
|
|
Re: Odyssey 1.23 progress |
Posted on: 2014/1/29 11:11
#62 |
|---|---|---|
|
Quite a regular
Joined:
2009/4/28 4:57 From Adelaide, Australia
Posts: 939
|
@kas1e
OK. The next time I upload the ffmpeg libraries, I'll disable debug symbols. (Edit: maybe) Edited by MickJT on 2014/1/29 13:39:29
|
|
|
|
||
Top