Ok you are crosscompiling so maybe it's a silly question, but we doesn't have an updated GCC to try ? For example latest YAM builds are compiled with GCC 4.7.1, Thore or Damato should have it i think ..
If the old sqlite port you have works fine, you can just keep it. A newer one isn't required.
Regarding your nullptr issue, you'd need a newer GCC (and more recent WebKit will definitely need a newer one since they use more and more C++11 features), but for this particular revision (r155188), you can just replace it with 0. Your crash issue is most likely unrelated to this, and probably caused by ICU somehow.
Ok you are crosscompiling so maybe it's a silly question, but we doesn't have an updated GCC to try ?
I just need to buld last one from adtools, which easy, but is last thing i want to do, as new crosscompiler as usual will bring some new bugs with which need to deal again.
I know where adtools placed of course :) Just build new compiler now will mean recompile of whole odyssey again, as well as it will bring new bugs in new compiler which i didn't have in current one (usual stuff) and it will need again some time.
@broadblues Quote:
nullptr is a C++11 extension which replaces NULL with a more strictly typed replacement.
So perhaps your g++ doesn't support C++11 ?
It is support it. There is -std=gnu-0x and -std=c++0x which make it works. Whole Odyssey builds with it now. As well, as i says in all other places nullptr works fine in webkit, its just in those particular files it didn't compiles.
Quote:
The suggestion there is to do #define nullptr __null
In google there is bunch of another suggestions as well, but, if check google more deeply, they says that you can't in all the cases replace it on 0 or NULL, expectually when c++ do overloading of all stuff.
BTW your crash is not because r0 in 0x00000000 it's because r8 is 0x00000000. Can you not get the line number of the crash?
What you mean by "can you not get the line number of the crash" ? How i can't get it, if :
7f860cb0: 80080160 lwz r0,352(r8)
mean relative access to r8 and registers dump show r8 as 0x00000000 too. (edit: fixed typo in previous post about r0).
@Fab Quote:
Regarding your nullptr issue, you'd need a newer GCC (and more recent WebKit will definitely need a newer one since they use more and more C++11 features),
I think i will build 4.4.5 to have all the same as you then.
Quote:
but for this particular revision (r155188), you can just replace it with 0.
That what i do before. Also , in one place i had to replace 0 on nullptr back. And nullptr used in those files no everytime the same. In some its just return nullptr, in some its ? something : nullptr, and co.
Quote:
Your crash issue is most likely unrelated to this, and probably caused by ICU somehow.
But crash point out on iterators (where i do those changes), as well as it point on those relative null pointers when crashes, as well as i tried libicu and with libicudatastub.a , and with full libicudata.a as static and all changes in libicu i do, its build it like:
Then i also have to undef some TZNAME define (in pputl.c or something), and as i on cross-compiler i also build x86 version of libicu in another place to have those "bins" which used to generate stuff, and put them instead of ppc ones to aos4 build so be able to compile and generate everything.
That all i do, and its the same as i do before (at least my notes says so for previous versions).
In other words, seems only way to go now its build new compiler from adtools (and meet with new bugs from it, of course :) ). At least it should deal with compiling issues with nullptr, and if bug will be still here, then it will point out on icu itself indeed and then will try to rebuild icu natively on os4.
@All That all will take some time, probably few days.
Edited by kas1e on 2014/2/2 7:26:53 Edited by kas1e on 2014/2/2 7:35:05 Edited by kas1e on 2014/2/2 7:43:43 Edited by kas1e on 2014/2/2 7:45:59 Edited by kas1e on 2014/2/2 7:47:04
What you mean by "can you not get the line number of the crash" ? How i can't get it, if :
By using addr2line on the stack trace or a more recent GrimReaper ofcourse, not from the diassembly obviously.
And, without reading you link to see if there are more differences, the difference between nullptr and 0 is that mullptr invokes the pointer based overloaded function and 0 the integer (if the function is overloaded to differentiate) whether that also applies to NULL which is (void *)0L I dont know. Most of the time that should be okay. You could save yourself the time of building a gcc compiler by checking where the code crashes first!
You will need to downgrade texinfo to before v5 as well.
There was commits 482-483 from SBA : "Fixed to allow building with latest texinfo tools", imho they deal with.
@broadblues I know how to use crashlogs :) but i will start from new compiler because i need it soon or later. Better to do it now, and exclude from todo list (for future versions of Odyssey as well).
From your stack trace, it doesn't look related to these small nullptr/0 changes at all... It's really about ICU. It's not that unusual to have crashes that points to null pointers, you know... It doesn't mean it's related to these nullptr changes.
A wild guess would be ICU fails to find some of its data files, and since it's so well designed, it doesn't check for errors and crashes. So if you want to make a quick test, just change findWordBoundary to something void, and see what happens.
And about this nullptr issue, i really just replaced with 0 where needed in my port. I just didn't include this change in released sources because you may not have needed it, if you have compiled it with a newer gcc, i didn't want to change webkit sources there without reason.
A wild guess would be ICU fails to find some of its data files
I just reuse your data files from 1.23. So it should find all datafiles imho and all should works ?
Can you just post your configure line for libicu so i can be sure i build it same as you ? You for sure make no single change in libicu ? Not a single/simple one ?
Quote:
It's not that unusual to have crashes that points to null pointers, you know... It doesn't mean it's related to these nullptr changes.
I build libicu without changes just like you says, as well as i reuse your datafiles from 1.23. How it can not find datafiles then ?
Quote:
So if you want to make a quick test, just change findWordBoundary to something void, and see what happens.
Ok, will check it tomorrow.
Quote:
And about this nullptr issue, i really just replaced with 0 where needed in my port. I just didn't include this change in released sources because you may not have needed it, if you have compiled it with a newer gcc, i didn't want to change webkit sources there without reason.
Omiga1200 ! i was in hope that your sources 1:1 the same as you release, and because of that make assumption that if sources have ppc-morphos-gcc-4.4.5 then sources ready to build for exactly that..
Well, you should run that snoopdos-like tool to check if ICU really looks for these files in progdir:resource/icublah/ dir? If you didn't specify this path anywhere in your icu build, it's extremely unlikely they will be found magically by ICU. :)
@Fab Of course i didn't specify any path to anything anywhere, you didn't says so, and i build it as you says: without any changes or specific flags. Can you maybe (another try to ask the same) copy paste there your configure line for libicu ?
I will check with snoopy tomorrow of course, but if you can just post line of how it all should be , it will save a lot of time, as i anyway will do it one time and forget for another years.
Well, you should run that snoopdos-like tool to check if ICU really looks for these files in progdir:resource/icublah/ dir? If you didn't specify this path anywhere in your icu build, it's extremely unlikely they will be found magically by ICU. :)
It still magically happens that it search for progdir:resource/icublah/ even without specifing this path when i build icu. And as i see api/morphos/icufiles.cpp contain all those patches. Log here: http://kas1e.mikendezign.com/temp/odyssey_icu_snoopy.txt
Quote:
So if you want to make a quick test, just change findWordBoundary to something void, and see what happens.
It all then start to crashes like this:
Crash log for task "OWB"
Generated by GrimReaper 53.17
Crash occured in module OWB at address 0x7E828CF4
Type of crash: DSI (Data Storage Interrupt) exception
Alert number: 0x80000003
The video are play in overlay? And how much is the video resolution? Ii think you can't go up 360p in browser mode, plus in morphos I have bad result if I using HTML 5 player goes better with the swf
Nope. As far as i know window mode on morphos also didn't use overlay, only full-screen.
Quote:
And how much is the video resolution? Ii think you can't go up 360p in browser mode
360, but some videos are pretty fast, some are pretty not.
Quote:
plus in morphos I have bad result if I using HTML 5 player goes better with the swf
By swf you mean swfdec plugin ? I didn't have sources of swfdec plugin.
What i notice, that there is 2 different players brings in youtube. That one which i show on screenshot looks like it looks on all other browsers (same player, etc, all works), while, sometime it show another player, with button "play", and it seems do not works as well for me. And what is interesting, is that the same vids which show me player as i show on images, now start to show another one, with that "play" button.
Its the same on morphos too for me: sometime one look of player, sometime another look, sometime it works, sometime not.
Also in player which i show in screenshots pressing on fullscreen do nothing (i also tryed to use fullscreen_fix script too). And again, its the same for morphos (with and without fullscreen_fix script). It works only in second player.
By swf you mean swfdec plugin ? I didn't have sources of swfdec plugin.
Doh!
another tip: Try to go in the preference menu of Owb and test the decoding options , like skip some frame etc etc (sorry im at work and cant exactly write what is write in the menu) It is in the preference where there are the decode compatibility and the h264 selection flag.
It still magically happens that it search for progdir:resource/icublah/ even without specifing this path when i build icu. And as i see api/morphos/icufiles.cpp contain all those patches. Log here: http://kas1e.mikendezign.com/temp/odyssey_icu_snoopy.txt
Again, this icufiles.cpp is just a check for the presence of these files, nothing more. You still *HAVE* to specify the data path in ICU itself. I can't check right now, but it's not more difficult than setting something like #define DATA_DIR progdir:resource/icudt49b or whatever. I'll check when i can.
About Youtube, you seem a bit confused, too, so to make it clear:
It works with *all* videos, provided you have the 2 userscripts added.
youtube.js is needed for the videos that are not available in HTML5 mode (there are still many, and youtube sucks for that) : in that case, the flash (or void object if flash plugin is not available) is removed from DOM and replaced by Odyssey's builtin HTML5 player.
youtube_fullscreen_fix.js is needed for two things: - enabling overlay mode when pressing fullscreen button in Youtube's HTML5 player (the builtin one doesn't need this, it switches to overlay properly). - changing links in youtube page so that clicking a link on the right triggers a page reload (and thus make scripts work again for the next video).
The flash plugin is not needed at all to have youtube working with these scripts.
Finally, the non-overlay mode is not very fast (it has to go through slow cairo path), but still fast enough to watch a video on peg2. But it's obviously much better with overlay, a 360p video takes about 30% CPU on a Peg2 then. And on a G5, 1080p streams are watchable at fullspeed in Odyssey.
The video are play in overlay? And how much is the video resolution? Ii think you can't go up 360p in browser mode, plus in morphos I have bad result if I using HTML 5 player goes better with the swf
You can go as high as you want. It's not restricted in any way... Obviously, and especially without overlay, you'd better not go higher than 360/480p on a Pegasos2.
And with swf i suppose you rather mean the flash replacement mode done with youtube.js. It's slightly faster than Youtube's bloated HTML5 player indeed, but they both work just fine, and more than fast enough when overlay is enabled. So if you don't have good results, just enable overlay mode already...
In any case, it's better than TW's 4 seconds per frame playback... :)
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
Donate
