It's not treated differently, it's depreciated. The TimeRequest structure has superceeded it, and the fields have changed names too. Check devices/timer.h for further info.
Apparently, somebody forgot to tell Roadshow's bsdsocket.library about the deprecation because functions like WaitSelect() still use struct timeval. If the bsdsocket autodocs and includes aren't updated then you have no choice but to use the __USE_OLD_TIMEVAL__ definition.
"undefined reference to `errno'" which when using clib2 just including errno.h works but not with newlib.
Of course it does - but only if you rebuild all sources using errno with newlib, which you obviously didn't.
Quote:
"undefined reference to `__assertion_failure'" Goodness knows what this is as it does not even appear in my code.
"undefined reference to `__iob'" Goodness knows what this is as it does not even appear in my code.
It's the same problem: You are linking with clib2 code, either old object files you didn't recompile or link libraries built for clib2.
@xenic
Quote:
Apparently, somebody forgot to tell Roadshow's bsdsocket.library about the deprecation because functions like WaitSelect() still use struct timeval.
Roadshow uses the BSD socket API and therefore the standard struct timeval, not the AmigaOS timer.device struct TimeVal. Since <proto/bsdsocket.h> includes the required includes to get struct timeval there should be no problems!?
It's questionnable that WaitSelect() should use an unix timeval instead of the Amiga timer.device structure. (as it's not a BSD API but an Amiga specific one). However I agree with you Roadshow is conforming to BSD socket API as such it's normal it's using an Unix timeval anywhere else...
It's questionnable that WaitSelect() should use an unix timeval instead of the Amiga timer.device structure. (as it's not a BSD API but an Amiga specific one).
It's an extension of the standard select() which can additionally wait for AmigaOS signals, with signals=NULL it's identical to select(). And according to the autodoc it's struct timeval: Quote:
n = WaitSelect(nfds, readfds, writefds, exceptfds, timeout, signals) [...]
sys/time.h, not devices/timer.h
Quote:
However I agree with you Roadshow is conforming to BSD socket API as such it's normal it's using an Unix timeval anywhere else...
They are binary compatible anyway, just not source compatible (tv_secs and tv_micro in the old timer.device struct timeval instead of of tv_sec and tv_usec in the time.h one, the timer.device timeval/TimeVal uses unsiged integers but the time.h one uses singed ones, with unsigned integers for example the timersub() macro in sys/time.h doesn't work).
Using an object file compiled using the previous GCC works perfectly. No crashes at all, yet the code is exactly the same. Something in the new GCC is giving me an "alignment" crash type which the older version didn't.
Don't mix object files with older versions. The compiler alignment has changed. If you don't use the new compiler your software will not be aligned on the 440ep and thus likely run slower on the Sam. There is also an alignment issue on all the previous SDKs with double types. Although you can use the older SDK for now you really should move up to the corrected GCC.
ssolie wrote: @BillE [quote] Don't mix object files with older versions. The compiler alignment has changed.
It is the NEW alignment that is causing the [problems - with one file only. The same structure is used in other files but without getting crashes.
Why will the same file compiled with the older GCC work fine - with both old compiles and the new compiled other files, yet when compiled with the new GCC give problems.
Quote:
If you don't use the new compiler your software will not be aligned on the 440ep ....
With the new compiler it is not aligned on my A1 which I find far more worrying ATM
It is only using the older object file in the final link that gives a stable executable, the new one unfortunately doesn't.
Is it because the structure is surrounded by #pragma pack(2) ... #pragma pack ? It has to be in order to read in a data file which I want to keep compatible with older versions and also the Mac version of the software. I do not want to change the data format just because a new compiler does not like it.
Yet the same structure is used in several files and only one function in one file is causing any grief. ANy ideas as to what has changed in GCC and how I can do to make the code work again other than re-installing the older GCC ?
I also tried recompiling the lot with newlib once sorting out a few includes, again it compiled fine but is still giving the same alignement error when run. Trying out an admittedly dodgy test of including the old clib2 compiled object for the file in question - it works.
I'll PM you with more detailstomorrow to see if we can crack what is going on with this alignment issue.
You could read the structure members separately. Its more work to read/write it from/to disk but the better alignment should make the access to the members a bit faster.
However, i will do some tests when i get my SAM back.
Excuse my curiousity but not a hardware fault?
~Yes I am a Kiwi, No, I did not appear as an extra in 'Lord of the Rings'~ 1x AmigaOne X5000 2.0GHz 2gM RadeonR9280X AOS4.x 3x AmigaOne X1000 1.8GHz 2gM RadeonHD7970 AOS4.x
~Yes I am a Kiwi, No, I did not appear as an extra in 'Lord of the Rings'~ 1x AmigaOne X5000 2.0GHz 2gM RadeonR9280X AOS4.x 3x AmigaOne X1000 1.8GHz 2gM RadeonHD7970 AOS4.x
Don't mix object files with older versions. The compiler alignment has changed.
No, it didn't. Of course you must not mix clib2 with newlib object files (incl. the ones in link libraries), but that has nothing to do with the version of gcc or ld and other than that there are no problems using old object files.
Quote:
If you don't use the new compiler your software will not be aligned on the 440ep and thus likely run slower on the Sam.
The wrong alignment for everything with a size > 4 bytes, and accessing wrongly aligned global double variables causes alignment exceptions on the 440ep slowing it down a lot, was caused by wrong (internal) linker scripts in the old version ld, not by the old version of gcc. It's not a SAM440ep-only problem, for example using global AltiVec variables didn't work with the old ld either because of the wrong alignment.
BillE wrote: > That's the problem that has me stumped. Newlib does > define errno in sys/errno.h included by errno.h
I noticed that too but for some reason the compiler or linker does not seem to find it ?
I fixed my timeval & errno problems with 2 changes. Because of some problems created by differences between the old clib2 network related includes and the SDK network includes, I had added "-ISDK:include/netinclude" to my makefiles for the old SDK. Removing that directive fixed most of my problems. I removed the "include errno.h" and replaced it with "extern int errno". My programs now compile and link, although I'm not sure if errno works. I think the SDK network includes might need some updating to avoid include problems but all seems well for me now.
My problem with the new SDK is that whatever I compile with the Allegro library, it links okay, but crashes after startup. With the old SDK I was not able to compile Allegro software at all, because it did not support dinymic linking. But dynamic link for SDL works fine with the new SDK, so I am not sure what I did wrong for Allegro.
I can't seem to find the specs file. I haven't used gcc since the days of 3.4 on the classic and Gunther was maintaining it. Seems the structure has changed quite significantly, but for the better no doubt, there (as far as I can tell so far) seems to be alot more compatiability and ease of compiling...
thanks
Edited by Slayer on 2009/2/2 8:27:03
~Yes I am a Kiwi, No, I did not appear as an extra in 'Lord of the Rings'~ 1x AmigaOne X5000 2.0GHz 2gM RadeonR9280X AOS4.x 3x AmigaOne X1000 1.8GHz 2gM RadeonHD7970 AOS4.x
works fine with clib2 but gives the following error with newlib
tools/tubsfind/tubsfind.c: In function 'fatal': tools/tubsfind/tubsfind.c:21: error: called object '__errno' is not a function tools/tubsfind/tubsfind.c:23: error: called object '__errno' is not a function
So far as I can see __errno is not being treated as a function, and not even referenced in those lines (the fprintf statements)
"multiple definition of `IDOS'" "multiple definition of `DOSBase'"
I ran into the same problem (and thank god your post). I was compiling like a happy bunny untill I added opening the DOS library. I got the above errors. But if I compile with -mcrt=clib2 it works.
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
