[Bug 2111] AVR needs avr-libc to compile RTEMS.

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=2111

Gedare <gedare at rtems.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gedare at rtems.org

--- Comment #11 from Gedare <gedare at rtems.org> 2013-04-09 12:21:34 CDT ---
(In reply to comment #10)
> Found some interesting 'features' of the RTEMS build system.
> 
> the (unpatched) RTEMS build system only allows *-*-*rtems* targets.
> 
> (patching away the *-*-*rtems*) targets issue, revealed another issue:
> 
> cpukit/configure.ac appears to run a POSIX compliance check each time RTEMS is
> configured, whether posix is enabled (or not).
> 
> So, for a long-term avr-libc port, we need to pull out the POSIX compliance
> check into a cpukit/aclocal/enable-posix-compliance-check.m4
> and add a
> --enable-posix-compliance-check option to make POSIX compliance checking
> optional.
> 
> Apparently cpukit/score requires a struct timeval definition, but I'm not clear
> as to whether we need score to do the classic rtems library (or not).  If we do
> need score, where should the timeval struct be declared (within rtems, or in
> avr-libc?)  Do we need score to do the ticker demo?
> 
score contains the scheduling and context switch logic which is needed by
ticker. However, we replaced struct timeval timestamps with 64-bit integers
some time ago (although that has been suggested to be reverted), so I think we
can at the very least conditionalize the code that uses/checks for struct
timeval, and maybe even eliminate it by moving the timeval dependent code to
the posix directory. Internally, the score uses Timestamp_Control, which is
actually either a timespec or a 64-bit integer, so score depends on posix
timespec when not using 64-bit timestamps.

I think this problem you found actually stems from the classic API Clock
Manager (cpukit/rtems/include/rtems/rtems/clock.h) depends on struct timeval.

> I was really amazed that I could compile as much as I did without newlib
> support!
> So in summary, three issues: target restrictions, posix compliance checking
> when posix is disabled, and score/timeval.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.