@jabirulo If you want to follow kas1e's advice, there should be a more recent version of libdebug.a in your SDK:clib2/lib/ directory. In my SDK I've created a link in SDK:newlib/lib/ to the libdebug.a in clib2: CD SDK:newlib/lib makelink SOFT libdebug.a TO //clib2/lib/libdebug.a
DebugPrintF() might work but after looking at the stuff that the functions in the WookieChat debug.c are doing, it might be better to just use kputc in libdebug.a.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
Ok, will revert to use debug lib. Erm Im not good at debugging stuff (niether at programming), but will try to do some tes and see why it crashes in such line.
@jabirulo Not very safe probably, but with libdebug it tested to death with different projects (dopus4,dopus5,odyssey,muiplayer,vpdf and whatever else few of us works on)
NEVER mix different C runtime libraries. Choose either one or the other, but do not mix them. Although they (amost) offer the same set of features and functions they are operating on completely different internal structures.
CD SDK:newlib/lib makelink SOFT libdebug.a TO //clib2/lib/libdebug.a
No!
YOu can't take libraries from clib2 and use then with newlib. You *might* get away with it with very simple ones, or ones with very little clibrary related stuff ( ie mostly OS calls) but you add an uncertainty that you can never really trust if bugs are real or not.
If you really want to use libdebug from clib2 with newlib then grab the src code and port it over to newlib!
Ok, will revert to use debug lib. Erm Im not good at debugging stuff (niether at programming), but will try to do some tes and see why it crashes in such line.
And is it "safe" to mix clib2 and newlib stuff?
Under normal circumstances clib2 & newlib object files and link libraries should not be mixed. However, in light of the fact that the clib2 debug library has been used with newlib in other applications (as kas1e pointed out), I think it's O.K. for you to use it for debugging. If you can find the bugs and fix them, then a public release should be done by someone who has commit privileges at the program repository; namely kas1e. He can decide if the clib2 debug library should be used in a public release. It's almost a moot point because the debug output will probably be deactivated in a public release (by removing -DDEBUG from the makefile).
In short, go ahead and use clib2 libdebug.a for debugging and let kas1e decide what to do about a public release.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
@broadblues & tboeckel If you are really that adamant about mixing clib2 & newlib library components, compile a newlib version and release it on OS4Depot.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
So after you have fixed strlen crash due to NULL Channel*, where the next crash happens?
:) That wasn't fixed of course , it was just temporary workoround probably, as problem is somewhere else..
To be honest better way will be first build aros and/or morphos binaries, test them (to see if that works at all), and only if , then trying to fix os4 build.
When I ran the compiled WookieChat without it's home directory, it crashed right away. When I D/L WookieChat 2.11 from OS4Depot and used the installer, it replaced my OS4.1FEu1 codesets.library with an ancient version of codesets library; very bad. I updated WookieChat with v2.12b15 and it runs but when I select a server and click connect it fails to connect.
You basically don't need to install it. Just get version from os4depot, unpack somewhere, build new binary, replace old one, and run from shell : you will see crash. You even will be not able to do anything.
Hmm.. but the fact the there actually is a NULL check later in the same function indicates to me that original developer expects Channel* to be NULL in some cases.
@Capehill Can't tests aros or mos versions at moment sadly. But that for sure will help a lot if someone will build latest revision for one of those platforms and test.
@kas1e I just spent an hour building clib2 with newlib (-mcrt=newlib) and libdebug.a is exactly the same size as the one I compiled with clib2. A binary diff says they are exactly the same. I'll do some serial output testing with the newlib version tommorrow but it looks to me like using a clib compiled link library is OK in some cases; despite the dire warnings from others.
I checked the repository and deadwood made some changes after the initial import and then geit made a lot of changes the next month. Since it appears that they are programming for AROS & MOS, the OS4 functionality may have gotten messed up. It might be a good idea to check out the original code (revision 1 or 2) and see if that will compile and work. If the original code works then somebody (not me!) can check out later revisions to determine where things went wrong.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
@Capehill Imho, it will crashes all the time one crash by next one, as Channel shouldn't be null in first place. Just need to understand why it null in that place where first crash happens.. We even can't say "After fixing the strlen() bug, next crash is here:" , as we didn't fix it, we just deal with side effect , but problem is that Channels NULL, while should't.
I haven't really IRCed for years so I don't know how WookieChat should work. However, when it starts, it's not connected to any server so there are no channels which sounds logical to me.
Anyway, after fixing the second crash, it is possible to connect some server. But after that I wasn't able to give any commands from keyboard.
@Capehil Yeah, i goin till the same state : after workoround strlen one, i then ignore second one (it can be ignored) and the same can't type a shit ) Ie. i can type, but can't "enter" it.
Btw, for me, it connectes to the server right after i run it (by default). I.e. i run binary, type nickname/name/etc, and then i can see via debug that it tries to connect to some server (amigaworld.de or something don't remember). And then it crashes. So probably it still want to feel Channel after connecting (as expected).
I think (but can be wrong), that this all all the same one bug, which we meet with different crash.
That by itself wouldn't work as you are still using the local clib2 includes, you need to remove the -Iinclude or similar from the makefile as well.
I understand your concern, but compiling with newlib includes didn't make much difference; the resulting libdebug.a files are the same size but a binary diff shows several differences. Better safe than sorry I suppose.
I have found something else I don't like. If you read change entry SDK:Documentation/Libs/clib2/changes "c.lib 1.129 (18.6.2004)" it states that libdebug calls RawPutChar() and RawMayGetChar() through the 68k LVO. I checked the code and that's still the case. Those 2 functions have prototyes in SDK:Include/include_h/proto/exec.h so I'm wondering why clib2 debug output is going through the 68k emulation instead of the PPC functions.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
@all Mazze checked aros build (see here). And its crashes exactly on the same place as our first crash.
What mean, wookie's code in latest revisioin just broken. Is it because of latest changes on SVN done by geit year ago, or is it because of anything else dunno. But fact is, code is broken in repo itself and for aros, and for os4. Interesting to check if it works on morphos at all..
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
