definition of mingw version

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

definition of mingw version

Roumen Petrov
First link "HOWTO Submit Bug Reports for MinGW Defects" on page
http://mingw.sourceforge.net/wiki/HOWTO point to non existing page.

Also I can't post to new tracker2
"http://sourceforge.net/tracker2/?group_id=2435&atid=102435".
If this is correct link to post bugs I get same message as was reported
in the list : "Permission: User Not Found: Only members of this project
have permission to view this page (you are not listed as a member of
this project).". A link on top of the page in "LogOut".


I would like to ask help/report about some issues:

1)
Please find attached file "strtod-tests.tgz" with:
- test-strtod.c :  test C-program;
- strtod-gcc.log : linux output;
- strtod-mingwex-3.15.log : mingw output, emulated environment, linked
with mingwex library from runtime 3.15;
- strtod-mingwex.log - previous version(3.14), native output.

Function strtod may be is correct now - the number of tested items is
too short.
The test show that function atof work fine and may be mingwex library
has to be replace it too.
What about printf output ? Is it correct ?


2)
The next issue (sorry that I post in same email) is about definition of
mingw runtime version.
It is defined in _mingw.h as : "#define __MINGW32_VERSION
3.15". Note the dot in the string. This definition don't allow to use in
code #if __MINGW32_VERSION > xxxx.
What about to define it as example to 0x030F ?

Also I prefer to use common syntax ("#if __MINGW32_VERSION > xxxx")
instead that I see in same file for gnu compiler version "#if
__MINGW_GNUC_PREREQ (3, 0)" .
I wonder where such definition(__MINGW32_VERSION) is used. It can't be a
#if statement. If it is a function like prinf the code can be replaced
by: "...%d.%d  " , ... __MINGW32_MAJOR_VERSION, __MINGW32_MINOR_VERSION
... what is backward compatible.

I found one place where the current definition is used - configure
script, but the autoconf script is buggy:
$ ./configure --help
`configure' configures mingw-runtime __MINGW32_VERSION to adapt to many
kinds of systems.
The macro MINGW_AC_CONFIG_SRCDIR is not enough.


I would like to check for working strtod in a configure script.
Since I would like to check in cross-compilation environment too I think
that check for version is enough.



3)
Next issue is same as 2) but is for w32api package.
Same issue for the definition from include/w32api.h:"#define
__W32API_VERSION 3.11"

As example xmlsec project (see file src/mscrypto/xmlsec-mingw.h) contain
missing form w32aip definitions and structures . I would like to include
in #if statements, but now without to do checks by configure script.


Roumen






-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: definition of mingw version

Roumen Petrov
Roumen Petrov wrote:
[SNIP]
> 1)
> Please find attached file "strtod-tests.tgz" with:
[SNIP]
Now attached

Roumen

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

strtod-tests.tgz (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: definition of mingw version

Greg Chicares
In reply to this post by Roumen Petrov
On 2008-09-14 21:48Z, Roumen Petrov wrote:
>
> The next issue (sorry that I post in same email) is about definition of
> mingw runtime version.
> It is defined in _mingw.h as : "#define __MINGW32_VERSION
> 3.15". Note the dot in the string. This definition don't allow to use in
> code #if __MINGW32_VERSION > xxxx.
> What about to define it as example to 0x030F ?

Some programs may rely on its present style; changing it now would
break backward compatibility.

In my own code, I define a macro like this:

#define MY_MINGW_VERSION (__MINGW32_MAJOR_VERSION * 100 + __MINGW32_MINOR_VERSION)

and then I can write, e.g.:

#if 308 <= MY_MINGW_VERSION
#   define COMPILER_PROVIDES_EXPM1L
#endif // 308 <= MY_MINGW_VERSION

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: definition of mingw version

Keith Marshall
In reply to this post by Roumen Petrov
On Sunday 14 September 2008 22:48:53 Roumen Petrov wrote:
> First link "HOWTO Submit Bug Reports for MinGW Defects" on page
> http://mingw.sourceforge.net/wiki/HOWTO point to non existing page.

So, that page has not yet been migrated from the old to the new wiki;
either follow the advice on the home page, to refer to the old wiki,
when you can't find the content on the new, or better still, join in
and help with the migration.

> Also I can't post to new tracker2
> "http://sourceforge.net/tracker2/?group_id=2435&atid=102435".

Where did that link come from?  The project page still refers me to
https://sourceforge.net/tracker/?group_id=2435&atid=102435 (note
*not* tracker2).

> If this is correct link to post bugs I get same message as was
> reported in the list : "Permission: User Not Found: Only members of
> this project have permission to view this page (you are not listed
> as a member of this project).". A link on top of the page in
> "LogOut".

> I would like to ask help/report about some issues:
>
> 1)
> Please find attached file "strtod-tests.tgz" with:
> - test-strtod.c :  test C-program;
> - strtod-gcc.log : linux output;

If that's what you see on GNU/Linux, then your glibc has a seriously
defective strtod() implementation.

> - strtod-mingwex-3.15.log : mingw output, emulated environment,
> linked with mingwex library from runtime 3.15;
> - strtod-mingwex.log - previous version(3.14), native output.

Check the ChangeLog; you should see that strtod() has been made C99
compliant in 3.15, where it wasn't in 3.14; this output looks fine to
me.

> Function strtod may be is correct now

I think so.

> - the number of tested items is too short.
> The test show that function atof work fine and may be mingwex
> library has to be replace it too.

Maybe.  The standard would suggest that it should return the same as
strtod(), with a NULL pointer passed as second argument.

> What about printf output ? Is it correct ?

Yes, for the MSVCRT implementation.  Try compiling your test case
with -ansi, and see the difference, (with 3.15).

> 2)
> The next issue (sorry that I post in same email) is about
> definition of mingw runtime version.
> It is defined in _mingw.h as : "#define __MINGW32_VERSION
> 3.15". Note the dot in the string. This definition don't allow to
> use in code #if __MINGW32_VERSION > xxxx.
> What about to define it as example to 0x030F ?
>
> Also I prefer to use common syntax ("#if __MINGW32_VERSION > xxxx")
> instead that I see in same file for gnu compiler version "#if
> __MINGW_GNUC_PREREQ (3, 0)" .
> I wonder where such definition(__MINGW32_VERSION) is used. It can't
> be a #if statement. If it is a function like prinf the code can be
> replaced by: "...%d.%d  " , ... __MINGW32_MAJOR_VERSION,
> __MINGW32_MINOR_VERSION ... what is backward compatible.

And by the same token, you can just as well test the MAJOR and MINOR
versions, perhaps combining them, as Greg suggests.

> I found one place where the current definition is used - configure
> script, but the autoconf script is buggy:
> $ ./configure --help
> `configure' configures mingw-runtime __MINGW32_VERSION to adapt to
> many kinds of systems.
> The macro MINGW_AC_CONFIG_SRCDIR is not enough.

Well, *I* wrote that macro, and I resent you glibly calling it buggy,
without offering any alternative; it does what it says on the tin, and
it is *your* expectations which are buggy.  (FWIW, I wrote the macro
to use the format the package maintainer had already chosen for the
definition of __MINGW32_VERSION; I could have worked with either
format, and chose not to demand that the maintainer change it.  If
there is a bug, it is possible that the PACKAGE_VERSION should not be
incorporated into PACKAGE_TARNAME).

> I would like to check for working strtod in a configure script.
> Since I would like to check in cross-compilation environment too I
> think that check for version is enough.

Well, such usage really *is* buggy -- you should test for feature
support, *not* for versions, (although I accept that in a cross
compile environment, a version test may be better than nothing, when
you need a run test, to check the feature).

Regards,
Keith.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: definition of mingw version

Roumen Petrov
Also I miss to add w32api to the subject.
Please, see my comments in quoted test.

Keith Marshall wrote:

> On Sunday 14 September 2008 22:48:53 Roumen Petrov wrote:
>> First link "HOWTO Submit Bug Reports for MinGW Defects" on page
>> http://mingw.sourceforge.net/wiki/HOWTO point to non existing page.
>
> So, that page has not yet been migrated from the old to the new wiki;
> either follow the advice on the home page, to refer to the old wiki,
> when you can't find the content on the new, or better still, join in
> and help with the migration.
>
>> Also I can't post to new tracker2
>> "http://sourceforge.net/tracker2/?group_id=2435&atid=102435".
>
> Where did that link come from?  The project page still refers me to
> https://sourceforge.net/tracker/?group_id=2435&atid=102435 (note
> *not* tracker2).

Dunno whats happen. Yesterday I just follow links from old wiki and I
get a message that page will be redirected. Today I can't reproduce I
will tray later with some other issues.


>> If this is correct link to post bugs I get same message as was
>> reported in the list : "Permission: User Not Found: Only members of
>> this project have permission to view this page (you are not listed
>> as a member of this project).". A link on top of the page in
>> "LogOut".
>
>> I would like to ask help/report about some issues:
>>
>> 1)
>> Please find attached file "strtod-tests.tgz" with:
>> - test-strtod.c :  test C-program;
>> - strtod-gcc.log : linux output;
>
> If that's what you see on GNU/Linux, then your glibc has a seriously
> defective strtod() implementation.

May be is broken, but it pass all python tests, this include "float",
"math" and "cmath"(complex). Also native windows build (version 2.6b3,
distributed with msvcr90), pass all tests even in emulated environment!


>> - strtod-mingwex-3.15.log : mingw output, emulated environment,
>> linked with mingwex library from runtime 3.15;
>> - strtod-mingwex.log - previous version(3.14), native output.
>
> Check the ChangeLog; you should see that strtod() has been made C99
> compliant in 3.15, where it wasn't in 3.14; this output looks fine to
> me.

I know this.


>> Function strtod may be is correct now
>
> I think so.

Today I spend time to test python against mingw runtime 3.15 and win32
api 3.12. The results is much better - "float" test is passed. For the
protocol the python patch is posted in issue 3871:
http://bugs.python.org/issue3871 .
So according the "float" and "math" tests strtod is fine for python if
we link with mingwex.
A mysterious issue is in "math" test. The python function ldexp(1,
10*10) don't raise exception if is called in the test script. If is
called in separate python program it's work fine.
Please don't reply to this issue in this mail thread. I will open
another one later.


>> - the number of tested items is too short.
>> The test show that function atof work fine and may be mingwex
>> library has to be replace it too.
>
> Maybe.  The standard would suggest that it should return the same as
> strtod(), with a NULL pointer passed as second argument.
>
>> What about printf output ? Is it correct ?
>
> Yes, for the MSVCRT implementation.  Try compiling your test case
> with -ansi, and see the difference, (with 3.15).

According python tests cases {v}snprintf from mingwex is fine.


>> 2)
>> The next issue (sorry that I post in same email) is about
>> definition of mingw runtime version.
>> It is defined in _mingw.h as : "#define __MINGW32_VERSION
>> 3.15". Note the dot in the string. This definition don't allow to
>> use in code #if __MINGW32_VERSION > xxxx.
>> What about to define it as example to 0x030F ?
>>
>> Also I prefer to use common syntax ("#if __MINGW32_VERSION > xxxx")
>> instead that I see in same file for gnu compiler version "#if
>> __MINGW_GNUC_PREREQ (3, 0)" .
>> I wonder where such definition(__MINGW32_VERSION) is used. It can't
>> be a #if statement. If it is a function like prinf the code can be
>> replaced by: "...%d.%d  " , ... __MINGW32_MAJOR_VERSION,
>> __MINGW32_MINOR_VERSION ... what is backward compatible.
>
> And by the same token, you can just as well test the MAJOR and MINOR
> versions, perhaps combining them, as Greg suggests.

Multiplication is so fast operation.
What about a definition like this one:
((__W32API_MAJOR_VERSION << 8) | __W32API_MINOR_VERSION )
Also similar with __MINGW32_XXX_VERSION.

About the name I prefer this definition to replace existing one :
__W32API_VERSION and __MINGW32_VERSION.
I don't think that new format(hex-format) will impact legacy applications.
We can't use old format in #if statement.
If the current version format was string may be proposed change will
break legacy applications.
Since the current version format is numeric I don't expect impacts.
As I point (see quoted text above) legacy application (if exist) may use
format specifier like this one "...%d.%d.." and to pass
__MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSION.

If the final decision as result of this discussion is don't change
existing one and to add a new definition I will accept too.
For the name of new definition I would like to propose
__W32API_VERSION_HEX and __MINGW32_VERSION_HEX respective.


>> I found one place where the current definition is used - configure
>> script, but the autoconf script is buggy:
>> $ ./configure --help
>> `configure' configures mingw-runtime __MINGW32_VERSION to adapt to
>> many kinds of systems.
>> The macro MINGW_AC_CONFIG_SRCDIR is not enough.
>
> Well, *I* wrote that macro, and I resent you glibly calling it buggy,
> without offering any alternative; it does what it says on the tin, and
> it is *your* expectations which are buggy.  (FWIW, I wrote the macro
> to use the format the package maintainer had already chosen for the
> definition of __MINGW32_VERSION; I could have worked with either
> format, and chose not to demand that the maintainer change it.  If
> there is a bug, it is possible that the PACKAGE_VERSION should not be
> incorporated into PACKAGE_TARNAME).

Ok. The bug is that you try to replace internal autoconf variables, but
the second argument of AC_INIT is cached and used later.
The command "grep __MINGW32_VERSION configure" show this.
You may use m4_define([__MINGW32_VERSION], [...]) but before AC_INIT.

>> I would like to check for working strtod in a configure script.
>> Since I would like to check in cross-compilation environment too I
>> think that check for version is enough.
>
> Well, such usage really *is* buggy -- you should test for feature
> support, *not* for versions, (although I accept that in a cross
> compile environment, a version test may be better than nothing, when
> you need a run test, to check the feature).

Yes the issue is from cross-compilation environment where configure
script can't run test program. Also check for feature will overload
configure script especially if is related to mingw wincrypt.h header.
I will address wincrypt.h header further.

For now I would like to get only the name of the macros that we could
use in #if statement.


> Regards,
> Keith.

Roumen

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: definition of mingw version

Keith Marshall
On Monday 15 September 2008 22:40:14 Roumen Petrov wrote:
> > If that's what you see on GNU/Linux, then your glibc has a
> > seriously defective strtod() implementation.
>
> May be is broken, but it pass all python tests,

Really?  Then the python tests aren't much cop, if

  x=%.17g (strtod)

is the expected output, in every case, for that's what appears
throughout the strtod-gcc.log file you attached.

> >> What about printf output ? Is it correct ?
> >
> > Yes, for the MSVCRT implementation.  Try compiling your test case
> > with -ansi, and see the difference, (with 3.15).
>
> According python tests cases {v}snprintf from mingwex is fine.

And, for mingwrt-3.15, if you compile with -ansi, or -posix, or any of
the defines mentioned in the release notes, this should also extend
to {,f,s,v,vf,vs}printf() too.

> > And by the same token, you can just as well test the MAJOR and
> > MINOR versions, perhaps combining them, as Greg suggests.
>
> Multiplication is so fast operation.

We are talking about a compile time operation, which might be done
once or twice in a build cycle, so I would suggest that the overhead
wouldn't be worth worrying about.

> What about a definition like this one:
> ((__W32API_MAJOR_VERSION << 8) | __W32API_MINOR_VERSION )

Well yes, that might have been my choice too; the point was that you
can combine these two in a manner which facilitates a convenient
check for a minimum version number, *if* you need such a check, (and
you really should not be relying on this extensively).

> If the final decision as result of this discussion is don't change
> existing one and to add a new definition I will accept too.

You are free to add whatever extra definitions you wish, in your own
code; I see no pressing need for any more than the system headers
provide at present.  Ultimately, it is down to Chris' discretion,
whether he wishes to pander to your whim, or not; IMO, it isn't
necessary for him to do anything.

> >> ... the autoconf script is buggy:
> >> $ ./configure --help
> >> `configure' configures mingw-runtime __MINGW32_VERSION to adapt
> >> to many kinds of systems.
> >> The macro MINGW_AC_CONFIG_SRCDIR is not enough.
> >
> > Well, *I* wrote that macro, and I resent you glibly calling it
> > buggy, without offering any alternative; it does what it says on
> > the tin, and it is *your* expectations which are buggy.  (FWIW, I
> > wrote the macro to use the format the package maintainer had
> > already chosen for the definition of __MINGW32_VERSION; I could
> > have worked with either format, and chose not to demand that the
> > maintainer change it.  If there is a bug, it is possible that the
> > PACKAGE_VERSION should not be incorporated into PACKAGE_TARNAME).
>
> Ok. The bug is that you try to replace internal autoconf variables,

No, I don't; I replace only public variables...

> but the second argument of AC_INIT is cached

It isn't, in the strict sense of autoconf caching, but it is used at
other places within the configure script, than simply to assign a
value to $PACKAGE_VERSION.  The effect is benign, but I take your
point -- it may not be particularly desirable.  I'll discuss this
with Chris, and we'll agree how to improve the aesthetics, if at all,
possibly for the next release.

> For now I would like to get only the name of the macros that we
> could use in #if statement.

They are __MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSION for
mingwrt; __W32API_MAJOR_VERSION and __W32API_MINOR_VERSION for
w32api.  You can depend on nothing else, unless you wish to make your
own software depend on some future, unknown versions of these two,
which may or may not be released at some time beyond your control.

Regards,
Keith.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: definition of mingw version

Roumen Petrov
In reply to this post by Keith Marshall
Hi Keith,

Keith Marshall wrote:
> On Sunday 14 September 2008 22:48:53 Roumen Petrov wrote:
[SNIP]

>> 2)
>> The next issue (sorry that I post in same email) is about
>> definition of mingw runtime version.
>> It is defined in _mingw.h as : "#define __MINGW32_VERSION
>> 3.15". Note the dot in the string. This definition don't allow to
>> use in code #if __MINGW32_VERSION > xxxx.
>> What about to define it as example to 0x030F ?
>>
>> Also I prefer to use common syntax ("#if __MINGW32_VERSION > xxxx")
>> instead that I see in same file for gnu compiler version "#if
>> __MINGW_GNUC_PREREQ (3, 0)" .
>> I wonder where such definition(__MINGW32_VERSION) is used. It can't
>> be a #if statement. If it is a function like prinf the code can be
>> replaced by: "...%d.%d  " , ... __MINGW32_MAJOR_VERSION,
>> __MINGW32_MINOR_VERSION ... what is backward compatible.
>
> And by the same token, you can just as well test the MAJOR and MINOR
> versions, perhaps combining them, as Greg suggests.
>
>> I found one place where the current definition is used - configure
>> script, but the autoconf script is buggy:
>> $ ./configure --help
>> `configure' configures mingw-runtime __MINGW32_VERSION to adapt to
>> many kinds of systems.
>> The macro MINGW_AC_CONFIG_SRCDIR is not enough.
>
> Well, *I* wrote that macro, and I resent you glibly calling it buggy,
> without offering any alternative; it does what it says on the tin, and
> it is *your* expectations which are buggy.  (FWIW, I wrote the macro
> to use the format the package maintainer had already chosen for the
> definition of __MINGW32_VERSION; I could have worked with either
> format, and chose not to demand that the maintainer change it.  If
> there is a bug, it is possible that the PACKAGE_VERSION should not be
> incorporated into PACKAGE_TARNAME).
[SNIP]

Please find attached file bootstrap.sh (also attached bootstrap.sh.gz is
if mail client/server broke plain text).

As I wrote in a previous email, you may use m4_define.
This shell script create and configure an autoconf demo that set version
from a source file, name of the package, etc.. Based on demo you may
rewrote configure script do not use MINGW_AC_CONFIG_SRCDIR .

Roumen

P.S.: resent

test -d src || mkdir src

cat > src/foo.h <<EOF
#ifndef _FOO_H
#define _FOO_H

#define __FOO_VERSION_STR "1.13"
#define __FOO_VERSIONSUFFIX 0x010C
#define __FOO_MAJOR_VERSION 1
#define __FOO_MINOR_VERSION 13

#endif /*ndef _FOO_H*
EOF

cat > aclocal.m4 <<EOF
AC_DEFUN([FOO_INIT],
[
])
EOF

cat > configure.ac <<EOF
AC_PREREQ([2.61])

m4_define([FOO], [TeeeSssTt])
m4_define([FOO_SRC], [src/foo.h])
m4_define([FOO_VERSION], [m4_esyscmd(awk '$ 2 == "__\$0SUFFIX" {a=strtonum($ 3); printf "%d.%d"[,]a/255[,]a%255}' FOO_SRC)])
m4_define([FOO_TAR], [FOO-FOO_VERSION-fFOoo])

AC_INIT([FOO], [FOO_VERSION], [http://example.net/tracker/foo], [FOO_TAR])
AC_CONFIG_SRCDIR([FOO_SRC])

AC_CONFIG_HEADERS([config.h])
AC_OUTPUT([])
EOF

rm -f configure
autoheader
autoconf
grep PACKAGE configure


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

bootstrap.sh.gz (636 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: definition of mingw version

Roumen Petrov
In reply to this post by Keith Marshall
Keith Marshall wrote:

> On Monday 15 September 2008 22:40:14 Roumen Petrov wrote:
>>> If that's what you see on GNU/Linux, then your glibc has a
>>> seriously defective strtod() implementation.
>> May be is broken, but it pass all python tests,
>
> Really?  Then the python tests aren't much cop, if
>
>   x=%.17g (strtod)
>
> is the expected output, in every case, for that's what appears
> throughout the strtod-gcc.log file you attached.

It was a broken file included in archive before to fix bug in code
(s/%%.17g/%.17g/).
The archive contain correct code, but old output.
Anyway I will not post new file.
Both functions (strtod and atof) output same.
With new mingw runtime(3.15) (if posix is defined) stdout is same.
Only atof return 0 for {+/-}{nan|inf|infinity}.



>>>> What about printf output ? Is it correct ?
>>> Yes, for the MSVCRT implementation.  Try compiling your test case
>>> with -ansi, and see the difference, (with 3.15).
>> According python tests cases {v}snprintf from mingwex is fine.
>
> And, for mingwrt-3.15, if you compile with -ansi, or -posix, or any of
> the defines mentioned in the release notes, this should also extend
> to {,f,s,v,vf,vs}printf() too.

Yes, python define _GNU_SOURCE, so mingw port will use "ANSI STDIO".


>>> And by the same token, you can just as well test the MAJOR and
>>> MINOR versions, perhaps combining them, as Greg suggests.
>> Multiplication is so fast operation.
>
> We are talking about a compile time operation, which might be done
> once or twice in a build cycle, so I would suggest that the overhead
> wouldn't be worth worrying about.
>
>> What about a definition like this one:
>> ((__W32API_MAJOR_VERSION << 8) | __W32API_MINOR_VERSION )
>
> Well yes, that might have been my choice too; the point was that you
> can combine these two in a manner which facilitates a convenient
> check for a minimum version number, *if* you need such a check, (and
> you really should not be relying on this extensively).
>
>> If the final decision as result of this discussion is don't change
>> existing one and to add a new definition I will accept too.
>
> You are free to add whatever extra definitions you wish, in your own
> code; I see no pressing need for any more than the system headers
> provide at present.  Ultimately, it is down to Chris' discretion,
> whether he wishes to pander to your whim, or not; IMO, it isn't
> necessary for him to do anything.
>
[SNIP]

>> For now I would like to get only the name of the macros that we
>> could use in #if statement.
>
> They are __MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSION for
> mingwrt; __W32API_MAJOR_VERSION and __W32API_MINOR_VERSION for
> w32api.  You can depend on nothing else, unless you wish to make your
> own software depend on some future, unknown versions of these two,
> which may or may not be released at some time beyond your control.
>
> Regards,
> Keith.

I think that a simple macro definition is more readable instead
expressions. As example:
#if (WINVER >= 0x0500)
#if (_WIN32_WINNT >= 0x0501)

Roumen

P.S.: mail resent


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: definition of mingw version

Keith Marshall
On Saturday 20 September 2008 22:14:59 Roumen Petrov wrote:

> >> For now I would like to get only the name of the macros that we
> >> could use in #if statement.
> >
> > They are __MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSION for
> > mingwrt; __W32API_MAJOR_VERSION and __W32API_MINOR_VERSION for
> > w32api.  You can depend on nothing else, unless you wish to make
> > your own software depend on some future, unknown versions of
> > these two, which may or may not be released at some time beyond
> > your control.
> >
> > Regards,
> > Keith.
>
> I think that a simple macro definition is more readable instead
> expressions. As example:
> #if (WINVER >= 0x0500)
> #if (_WIN32_WINNT >= 0x0501)

<shrug> It doesn't matter what you think; you've got to work with what
you've been given.  If you want something else, which will work
today, then you have to define it yourself.  If you wait for the
project's package maintainer to give you what you want, you may have
to wait indefinitely.  Something of a no-brainer, really.

Regards,
Keith.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: definition of mingw version

Keith Marshall
In reply to this post by Roumen Petrov
On Saturday 20 September 2008 22:14:49 Roumen Petrov wrote:
> Please find attached file bootstrap.sh (also attached
> bootstrap.sh.gz is if mail client/server broke plain text).
>
> As I wrote in a previous email, you may use m4_define.

I know I *can*; that's how I chose to do it, in the catgets library
package, but it isn't how I want to do it for mingwrt or w32api.

> This shell script create and configure an autoconf demo that set
> version from a source file, name of the package, etc.. Based on
> demo you may rewrote configure script do not use
> MINGW_AC_CONFIG_SRCDIR .

I may, but I won't.  Actually, managing package versions within
autoconf isn't particularly elegant; it requires regenerating
configure every time the version is bumped, and since configure is
maintained within CVS, that can get messy.

Instead, I may simply revert to earlier autoconf syntax, and use:

  AC_INIT
  MINGW_AC_CONFIG_SRCDIR([__MINGW32_VERSION], [include/_mingw.h])
  ...

(I may even extend MINGW_AC_CONFIG_SRCDIR(), to have it also define
the package name).

Problem solved.

Regards,
Keith.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users