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.
If all that disabling debug removes is debug symbols and gstabs info then why remove it? Kas1e may not like it but he is just one developer and seeing which function your program crashes in when developing is very useful.
If debug adds actual debug code though, there may be efficiency reasons to remove it.
gstabs stuff does not affect executable size WRT to relocation etc on the size of the file on disk. I don't think debug symbols are even loaded into memory (for static builds not so sure about sobjs) until it crashes and the Grim Reaper appears.
Well, I'll think about it some more :) I want to just leave things how they are by default. If it's built with -g, then it stays that way. The ffmpeg libraries I could make an exception since they're rather big. However, those are only static libs, and so you're still going to be able to strip whatever binary you make with them.
Quote:
If debug adds actual debug code though, there may be efficiency reasons to remove it.
Yeah, that's why I was asking before whether --disable-debug did anything more than remove -g. With ffmpeg it might disable other code that's unnecessary for a release archive, but I don't think it does.
As well , as with all that removing and striping final binary are "just" 52mb of size (that with attached mediaplayer libs and co), which even a bit smaller than on morphos :)
Another good news is that i have some initial version of calltips.mcc from Thore, that mean it also passed. Now some minor bugs which the same to fix as previously, and in other words i hope tomorrow to have browser running and have some tasty screenshots !
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
