[En-Nut-Discussion] Newlib version dependent defnition of unsetenv

Ole Reinhardt ole.reinhardt at embedded-it.de
Tue Feb 17 12:24:15 CET 2009


Hi Harald,

> > So I'd like to make a descision on compile time if newlib is < 1.17 or
> > newer. Any Idea for that? Using define _NEWLIB_VERSION is quite
> > uncomfortable, as it is defined as a string.
> 
> Mh... may be we can base the decision on another change. I'm unable to
> find something like a ChangeLog, only
> http://www.nabble.com/Newlib-1.17.0-is-released-td21135527.html
> which isn't very informative.

I'd like to bring this point up again. I just asked on the newlib
mailinglist, if there is any solution to check the correct version.

>> <ole.reinhardt at thermotemp.de> wrote:
>> newlib.h defines _NEWLIB_VERSION as string, so it can't be checked by
>> the C preprocessor.
>>      
>> I'd like to vote for a versioning system like the linux kernel uses
>> by defining a number and macros to request the major / minor versions
>> along with the string representation.

I just got a unsatisfactory answer:

> This won't work well for newlib, because the release discipline
> amounts to "update the version every december". You'ld need to use the
> CVS revision number. There is no correlation between the nominal
> newlib version number and the feature set.

The further communication wasn't more satisfactoring:

>> Oh, I understand. Is there any other way to differentiate between
>> those versions / feature sets?

> Don't rely on versions, but check for them. One way to do so would be 
> using autoconf.

In other words: There is no good solution and no willing on the side of
the newlib developers to implement an easy to check version numbering.
We have to solve it in another way. 

I don't like the autoconf way as we would need to alter the complete
NutOS build process. For my own purpose I solved the problem by adding a
config option to the configurator. That's not a nice solution either.
I'd like to first discuss this before checking in my solution.

Another Idea would be to overwrite the unsetenv declaration using #undef
in an own stdlib.h where we include the original one. And to always use
the posix compatible declaration returning an int. 

Any suggestions?

Regards,

Ole Reinhardt 

-- 
 _____________________________________________________________
|                                                             |
| Embedded-IT          Hard- und Softwarelösungen             |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        +49 (0)271  7420433 |
| Luisenstraße 29      Mobil:             +49 (0)177  7420433 |
| 57076 Siegen         eMail:    ole.reinhardt at embedded-it.de |
| Germany              Web:         http://www.embedded-it.de |
|                      UstID / VAT:       DE198944716         |
|_____________________________________________________________|



More information about the En-Nut-Discussion mailing list