Home  
Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
67 user(s) are online (56 user(s) are browsing Forums)

Members: 0
Guests: 67

more...
Support us!
Recent OS4 Files
OS4Depot.net



« 1 2 (3) 4 5 6 ... 43 »


Re: Odyssey 1.23 progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4193
@Fab
Quote:

You probably compiled ffmpeg with debug enabled (-g)


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:

/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.

   Report Go to top

Re: Odyssey 1.23 progress
Quite a regular
Joined:
2009/4/28 3:57
From Adelaide, Australia
Posts: 817
@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.

   Report Go to top

Re: Odyssey 1.23 progress
Quite a regular
Joined:
2013/10/5 14:07
From Italy
Posts: 616
@magnetic

Quote:
kas1e for PRESIDENT!


for sure him will be better compared with Putin

   Report Go to top

Re: Odyssey 1.23 progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4193
@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:

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 :)

   Report Go to top

Re: Odyssey 1.23 progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4193
@Fab

Quote:

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:

Quote:

./configure --build=i686-pc-cygwin --host=ppc-amigaos --with-cross-build=/usr/local/amiga/icu/source/icu_os4 --disable-shared \
--enable-static --disable-tests --disable-samples --disable-debug CFLAGS='-static -mlongcall' CXXFLAGS='-static -mlongcall' LIBS=-lunix


Once configure done, i have:

Quote:

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:

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.

   Report Go to top

Re: Odyssey 1.23 progress
Home away from home
Joined:
2006/12/2 3:55
From Italy, Perugia
Posts: 2975
@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 ?

   Report Go to top

Re: Odyssey 1.23 progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4193
@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.

   Report Go to top

Re: Odyssey 1.23 progress
Home away from home
Joined:
2006/12/2 3:55
From Italy, Perugia
Posts: 2975
@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 ..

   Report Go to top

Re: Odyssey 1.23 progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4193
@samo
Quote:

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.

   Report Go to top

Re: Odyssey 1.23 progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4193
@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

Register dump:
GPR (General Purpose Registers):
0: 6FFAE000 64D6DB80 DEADBEEF 00000000 64B0E600 00000001 7E1E5ACC 7E1E4F9C
8: 64B0E8E0 64B0E640 01B5238C 01B7786C 00000478 64FA7868 00000000 65DD66C0
16: 7D478008 00000000 00000000 00340014 02290000 02290000 1948779C 00000000
24: 654DFA12 00000000 64D6DC80 00000001 64B0E640 00000001 64EAF5B0 64B0E838


FPR (Floating Point Registers, NaN = Not a Number):
0: nan 0 0 0
4: 0 24.8 17.8 226
8: 2 4.5036e+15 4.5036e+15 0
12: 1 18 0 0
16: 0 0 0 0
20: 0 0 0 0
24: 0 0 0 0
28: 0 0 0 0

FPSCR (Floating Point Status and Control Register): 0x82004000


SPRs (Special Purpose Registers):
Machine State (msr) : 0x0200F030
Condition (cr) : 0x85027002
Instruction Pointer (ip) : 0x01B77874
Xtended Exception (xer) : 0x0000FFFF
Count (ctr) : 0x64B0B710
Link (lr) : 0x6573AE58
DSI Status (dsisr) : 0x64B0B6E8
Data Address (dar) : 0x65739A2C



680x0 emulated registers:
DATA: 688EE58E 00000003 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 64D6DA50
FPU0: 0 0 0 0
FPU4: 0 0 0 0



Symbol info:
Instruction pointer 0x01B77874 belongs to module "newlib.library.kmod" (HUNK/Kickstart)

Stack trace:
native kernel module newlib.library.kmod+0x0002b314
_ZN7WebCore14PNGImageReader6decodeERKNS_12SharedBufferEb()+0x70 (section 1 @ 0xD6FE34)
_ZN7WebCore15PNGImageDecoder15isSizeAvailableEv()+0x54 (section 1 @ 0xD6FB10)
_ZN7WebCore11ImageSource15isSizeAvailableEv()+0x30 (section 1 @ 0x15494C)
_ZN7WebCore11BitmapImage15isSizeAvailableEv()+0x48 (section 1 @ 0x1452D4)
_ZN7WebCore11BitmapImage11dataChangedEb()+0x14c (section 1 @ 0x145FB8)
_ZN7WebCore5Image7setDataEN3WTF10PassRefPtrINS_12SharedBufferEEEb()+0x16c (section 1 @ 0x1559F8)
_ZN7WebCore5Image20loadPlatformResourceEPKc()+0x38c (section 1 @ 0x15E5BC)
T.3013()+0x2e8 (section 1 @ 0x137A4C4)
_GLOBAL__I_BCScrollbarThemeMorphOS.cpp()+0x30 (section 1 @ 0x137A694)
native kernel module newlib.library.kmod+0x00000138
native kernel module newlib.library.kmod+0x00002088
native kernel module newlib.library.kmod+0x00002d54
native kernel module newlib.library.kmod+0x00002ee8
_start()+0x170 (section 1 @ 0x16C)
native kernel module dos.library.kmod+0x00024cd0
native kernel module kernel+0x0006acd0
native kernel module kernel+0x0006ad50

PPC disassembly:
01b7786c: 3863000f addi r3,r3,15
01b77870: 54630036 rlwinm r3,r3,0,0,27
*01b77874: 90230000 stw r1,0(r3)
01b77878: 94430004 stwu r2,4(r3)
01b7787c: 95a30004 stwu r13,4(r3)


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
   Report Go to top

Re: Odyssey 1.23 progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4193
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.

   Report Go to top

Re: Odyssey 1.23 progress
Not too shy to talk
Joined:
2007/1/5 10:14
Posts: 261
Well done kas1e!

   Report Go to top

Re: Odyssey 1.23 progress
Home away from home
Joined:
2006/12/2 3:55
From Italy, Perugia
Posts: 2975
@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

   Report Go to top

Re: Odyssey 1.23 progress
Quite a regular
Joined:
2008/4/10 13:57
From Northern Ireland
Posts: 871
Yes, these regular progress reports are really appreciated!

   Report Go to top

Re: Odyssey 1.23 progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4193
@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"

   Report Go to top

Re: Odyssey 1.23 progress
Home away from home
Joined:
2006/12/2 3:55
From Italy, Perugia
Posts: 2975
@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



   Report Go to top

Re: Odyssey 1.23 progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4193
@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:

APTR OpenDictionary(STRPTR, struct TagItem *ti);
void CloseDictionary(APTR);
STRPTR* Suggest(APTR, STRPTR, struct TagItem *ti);


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).

   Report Go to top

Re: Odyssey 1.23 progress
Quite a regular
Joined:
2009/4/28 3:57
From Adelaide, Australia
Posts: 817
@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:

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
   Report Go to top

Re: Odyssey 1.23 progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4193
@Mick
Quote:

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.

   Report Go to top

Re: Odyssey 1.23 progress
Quite a regular
Joined:
2009/4/28 3:57
From Adelaide, Australia
Posts: 817
@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
   Report Go to top


« 1 2 (3) 4 5 6 ... 43 »



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project