nothing like a little problem solving to start the day
I didn't get to install the new SDK (although I did download it)
edited due to lack of insight
Edited by Slayer on 2009/1/28 19:36:32
~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
@ktadd I ran into the same type of problem with MAXPATHLEN. It's defined in clib2 but not in newlib. There's not much you can do but define it in your sources or some include file that you use with all your programs. As far as your error goes, could the function have a return value that you're not using?
- there are no Boost and Minigl libraries/headers. Are they going to be released later, separately?
- when running a couple of configure scripts, a warning window is opened, saying that a stack value was set too low (2k instead of the 6k required on a printf() function), and that the function may not work as expected. I don't have here the exact text, I'll copy it here tonight when I'll be at home. Luckily the configure script works, albeit using 100% of the CPU.
First thing to check, have you deleted *all* of the .o clib2 objects before switching to newlib? The "assertion" problem might be caused by the fact that you are mixing objects compiled with clib2 with others compiled with newlib.
"undefined reference to `errno'" which when using clib2 just including errno.h works but not with newlib.
That's the problem that has me stumped. Newlib does define errno in sys/errno.h included by errno.h but the linker doesn't accept or recognize it because I get the same error as you. It's easy to solve missing value definitions, even it you have to define them in your program, but missing functions are a different story. Apparently newlib still isn't up to snuff yet so I guess I'll have to stick with clib2 also. I wonder how you could port a *nix program using newlib if errno doesn't exist?
I have found some more problems with the new SDK that affect not only newlib but also if you are using the mcrt=clib2 option.
struct timerequest seems to be treated differently and the compiler complains unless you add #define __USE_OLD_TIMEVAL__ at the beginning of any file using it.
This change does not seem to be documented. In fact the document "OS4 Migration Guide" shows an example of setting up a timer but has not been updated to point out that you would now need to set this #define in order to use it.
I am also still trying to find out why one of my source files now leads to a crash when compiled using the new GCC and clib2, but when using the old object file compiled previously I get no crashes. I am still investigating that one !
Anyone know who we can report these "bugs/features" to ?
struct timerequest seems to be treated differently and the compiler complains unless you add #define __USE_OLD_TIMEVAL__ at the beginning of any file using it.
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.
struct timerequest seems to be treated differently and the compiler complains unless you add #define __USE_OLD_TIMEVAL__ at the beginning of any file using it.
That structure was obsoleted ages ago and the change is well documented in the devices/timer.h header file. Don't use the old structure as it was a bad mistake.
I am also still trying to find out why one of my source files now leads to a crash when compiled using the new GCC and clib2, but when using the old object file compiled previously I get no crashes. I am still investigating that one !
Be sure to turn on and fix any and all compiler warnings. At a minimum use -Wall -Wwrite-strings -Werror.
Be sure to turn on and fix any and all compiler warnings. At a minimum use -Wall -Wwrite-strings -Werror.
Done that, surely though wouldn't -Wall suffuices as the 'all' part looks to me as if it would include the other two ?
Do I need to recompile all files with these warnings enabled or just the troublesome one ?
I get no compiler warnings at all, but get a crash when running the code.
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.
It looks as if I may have to go back to using the older version of GCC.
Done that, surely though wouldn't -Wall suffuices as the 'all' part looks to me as if it would include the other two ?
No. -Wall implies many, but not (as the name might suggest) all possible warnings. Just take a look at gcc's manual to inform yourself about the individual options.
Be sure to turn on and fix any and all compiler warnings. At a minimum use -Wall -Wwrite-strings -Werror.
Done that, surely though wouldn't -Wall suffuices as the 'all' part looks to me as if it would include the other two ?
No in fact the purpose of -Werror is to make GCC treat warnings as if they were errors. As a consequence you won't be able to compile a file that still have a single warning in. The purpose of -Wwrite-strings is to warn you when you are trying to write to read-only strings.
I personally have adopted this options for my projects warnings are here for a reason and disambiguating statements is not only good for the compiler but also for the programmer.