Issues / Observatons with the new SDK 53.13

	Bottom Previous Topic Next Topic
Register To Post

(1) 2 3 »

ktadd

Posted on: 2009/1/28 2:54 #1

Quite a regular

I've run into the following issues with the new SDK:

newlib is used by default now instead of clib2.

Problem caused:
SHRT_MAX and SHRT_MIN are not defined in newlib.

Compiling with -mcrt-clib2 cures this problem.? What are the equivalents in newlib?

I also now get the following compiler Warning with SDK 53.13 but not with the old SDK.

ffmpegGUI.c:1955: warning: value computed is not used
Line 1955 reads:? RA_Iconify(objects[OID_MAIN]);

Should I be using something different?

Slayer

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/28 3:47 #2

Quite a regular

@ktadd

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

xenic

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/28 8:00 #3

Just can't stay away

@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?

Varthall

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/28 10:07 #4

Just popping in

@ktadd

Things that I have observed so far:

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

Varthall

salass00

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/28 10:27 #5

Just can't stay away

@Varthall

You can get MiniGL 2.0 headers from the MiniGL SVN. That is what I have done.

The project page doesn't seem to be up ATM though...

I'm using MiniGL 2.0 in a project to do fast blitting of 2D "sprites" with alpha channel.

salass00

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/28 10:31 #6

Just can't stay away

@ktadd

Quote:

Problem caused:
SHRT_MAX and SHRT_MIN are not defined in newlib.

You could just add to your code:
#ifndef SHRT_MIN
#define SHRT_MIN (-0x8000)
#define SHRT_MAX (0x7FFF)
#endif

BillE

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/28 13:07 #7

Quite a regular

@thread

I too am having problems if using the default setting of newlib.

If I use mcrt=clib2 things compile as before.

But if using newlib I get the following problems.

"undefined reference to `errno'"
which when using clib2 just including errno.h works but not with newlib.

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

"multiple definition of `IDOS'"
"multiple definition of `DOSBase'"

No doubt creeping in because I am using
#define __USE_INLINE__
at the start of the code but it works in clib2 so why not newlib ?

Any ideas what causes these newlib problems, or should I just replace "gcc" with "gcc -mcrt=clib2" in my makefiles.

Bill.

Varthall

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/28 13:19 #8

Just popping in

@BillE

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.

Varthall

joerg

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/28 19:15 #9

Just can't stay away

@ktadd

Quote:

Problem caused:
SHRT_MAX and SHRT_MIN are not defined in newlib.

They should be defined if you include <limits.h>.

Quote:

I also now get the following compiler Warning with SDK 53.13 but not with the old SDK.

ffmpegGUI.c:1955: warning: value computed is not used
Line 1955 reads:? RA_Iconify(objects[OID_MAIN]);

Probably because you don't use/check the return value ("Returns non-zero if successful or 0 on error.").

xenic

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/29 2:46 #10

Just can't stay away

@BillE
Quote:

"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?

BillE

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/29 17:43 #11

Quite a regular

@xenic

> 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 ?

BillE

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/29 17:50 #12

Quite a regular

@thread

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 ?

Bill.

Rigo

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/29 18:51 #13

Supreme Council

@BillE

Quote:

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.

Simon

Chris

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/29 19:48 #14

Amigans Defender

@xenic

Quote:

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.

I get this sort of thing quite a lot with newlib, and have not been able to figure out why. math.h seems to be the main culprit.

Missing function defs just give a warning which I ignore (lnks ok). Missing defines I add manually to my own code.

Chris

ssolie

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/30 8:21 #15

Amigans Defender

@Varthall
I contributed C++ Boost and I didn't port a new version yet. Many tools and libraries are supplied by 3rd parties.

ExecSG Team Lead

ssolie

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/30 8:26 #16

Amigans Defender

@BillE
Quote:

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.

ExecSG Team Lead

ssolie

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/30 8:29 #17

Amigans Defender

@BillE
Quote:

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.

ExecSG Team Lead

BillE

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/30 11:32 #18

Quite a regular

@ssolie

Quote:

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.

Bill.

tboeckel

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/30 12:00 #19

Just popping in

@BillE

Quote:

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.

abalaban

Re: Issues / Observatons with the new SDK 53.13

Posted on: 2009/1/30 12:35 #20

Quite a regular

@BillE

Quote:

BillE wrote:
@ssolie

Quote:

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.

Back to a quiet home... At last

Register To Post	(1) 2 3 »
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )