Re: [Mingw-w64-public] Strange affect of "-std=c99" on 32-bit gcc
Thanks for the detailed explanation. I now realize that there are many different values that are similarly affected. Cheers, Rob On Wed, May 8, 2024 at 1:09 AM LIU Hao wrote: > 在 2024-05-07 19:05, sisyphus 写道: > > Although I often test 32-bit gcc on Windows, I don't actually rely on > those > > compilers - so I don't personally need a fix. > > I just wanted to mention this issue in case it's in the "public > interest". > > It looks like this is caused by `-fexcess-precision=standard`, as in GCC > manual: > > -fexcess-precision=style > > This option allows further control over excess precision on machines > where floating-point operations occur in a format with more precision > or range than the IEEE standard and interchange floating-point types. > By default, -fexcessprecision=fast is in effect; this means that > operations may be carried out in a wider precision than the types > specified in the source if that would result in faster code, and it is > unpredictable when rounding to the types specified in the source code > takes place. When compiling C or C++, if -fexcessprecision=standard is > specified then excess precision follows the rules specified in ISO C99 > or C++; in particular, both casts and assignments cause values to be > rounded to their semantic types (whereas -ffloat-store only affects > assignments). This option is enabled by default for C or C++ if a > strict conformance option such as -std=c99 or -std=c++17 is used. > -ffast-math enables -fexcess-precision=fast by default regardless of > whether a strict conformance option is used. > > -fexcess-precision=standard is not implemented for languages other > than C or C++. On the x86, it has no effect if -mfpmath=sse or > -mfpmath=sse+387 is specified; in the former case, IEEE semantics > apply without excess precision, and in the latter, rounding is > unpredictable. > > > By default the x87 FPU is used for floating-point arithmetic, so > `1.7976931348623157e+308` is more > precise than `double` and does not equal `0x1.fp+1023` due to > the extra significant bits. > > x86-64 is not subject to this, as SSE registers are exact `double` and > there is no excess precision. > > > -- > Best regards, > LIU Hao > > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Strange affect of "-std=c99" on 32-bit gcc
Hi,
Demo program:
/*** DBL_MAX.c ***/
#include
#define MY_DBL_MAX 0x1.fp+1023
int main(void) {
if(MY_DBL_MAX == 1.7976931348623157e+308) printf("OK1\n");
else printf("%a\n%a\n", MY_DBL_MAX, 1.7976931348623157e+308);
return 0;
}
/*/
If I build the executable with:
gcc -o DBL_MAX.exe DBL_MAX.c
then the executable outputs "OK1" as expected.
But if I build with:
gcc -o DBL_MAX.exe DBL_MAX.c -std=c99
then the output changes to:
0x1.fp+1023
0x1.fp+1023
Why does this happen ?
It happens with:
gcc version 8.3.0 (i686-posix-dwarf, Built by strawberryperl.com project)
gcc version 10.3.0 (MinGW-W64 i686-posix-dwarf, built by Brecht Sanders)
gcc version 11.3.0 (MinGW-W64 i686-posix-dwarf, built by Brecht Sanders)
gcc version 12.2.0 (MinGW-W64 i686-msvcrt-posix-dwarf, built by Brecht
Sanders)
gcc version 13.1.0 (MinGW-W64 i686-msvcrt-mcf-dwarf, built by Brecht
Sanders)
gcc version 13.2.0 (MinGW-W64 i686-ucrt-mcf-dwarf, built by Brecht Sanders,
r3)
Those are the only 32-bit compilers I've tested.
64-bit compilers seem to be unaffected by this issue.
Although I often test 32-bit gcc on Windows, I don't actually rely on those
compilers - so I don't personally need a fix.
I just wanted to mention this issue in case it's in the "public interest".
Cheers,
Rob
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Determine whether a mingw-w64 port of gcc is UCRT or MSVCRT
Given that I have, in my path, a mingw-w64 port of version 13.2.0 of gcc.exe, is there a gcc command that I can run to determine whether this gcc uses UCRT ? I thought that running "gcc --version" would do that - and it does for Brecht Sanders builds ... but niXman's UCRT and MSVCRT builds both report the same for "gcc --version". Is there instead something in "gcc -v" that I should be looking for ? Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] isfinite() is broken under quadmath
On Sat, Jul 15, 2023 at 12:42 AM LIU Hao wrote:[snip > [snip] > Looks like our `fpclassify()` doesn't handle `__float128`: Thank you for explaining. Is there some action I should take in order to improve the chances of this being fixed ? The problem arose in relation to the compilation of a perl module (DateTime). It turns out that Perl's C API provides a 'Perl_isfinite' function that does work with __float128, and which can be used as a drop in replacement of 'isfinite', so it was easy to work around. However, I think it's preferable that the mingw-w64 ports of gcc support 'isfinite' with __float128. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] isfinite() is broken under quadmath
Hi,
I've tested this with 64-bit gcc-11.3.0 and (both 32-bit and 64-bit)
gcc-13.1.0 nad am seeing the same brokenness.
The demo:
//
/* isfinite.c */
#include
#include
#include
int main(void) {
__float128 x = 1.0Q;
if(isfinite(x)) printf("OK\n");
else printf("NOT ok\n");
return 0;
}
/*
Build with:
gcc -o isfinite.exe isfinite.c -lquadmath
*/
/**/
It builds without any warnings being issued, but the resultant executable
takes about 4 seconds to run and produces no output.
It works fine if I cast the variable 'x' to a long double.
That is, it works fine if I replace:
if(isfinite(x)) printf("OK\n");
with:
if(isfinite((long double)x)) printf("OK\n");
Is this a mingw-w64 bug or a gcc bug ?
Cheers,
Rob
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [gcc-13.0.1] Anomalous as.exe behaviour
On Sat, Apr 29, 2023 at 8:36 PM LIU Hao wrote: > 在 2023-04-29 17:20, sisyphus 写道: > > Hi, > > If I fix the "shr" nameclash (by renaming "shr") I still get "invalid > use of register" errors in > > relation to assembler directives that don't involve any symbols from > cpoly.c > > That is, I think there's something else happening as well. > > > > Would you like more detail about this ? > > There is another static variable named `si` which denotes the lower 16-bit > sub-register of RSI. GNU > AS has issues parsing symbols that match register names, instruction names > or keywords [1]. This is > specific to x86_64; i686 doesn't seem to be affected. > > Renaming those variables to longer names can bypass this bug. > > I thought it would have been safe because static variables should have > 'long' names. Your example > surprised me a little. > > > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=12240 > > > > In any case, the "-masm=att" takes care of it but is it ok to > supply that argument when the > > system processor is (say) AMD64, and not Intel ? > > Yes. That only affects the syntax of assembly, not generated code in any > way. > > > > The code that builds the PDL module needs to be portable. > > I can easily shape that code so that the inclusion of "-masm=att" only > happens when the OS is > > Windows && the compiler is a mingw-w64 port of gcc ... but are there > additional considerations > > regarding portability ? > > The AT&T syntax has been default on Unix-like systems for decades - not > just GCC on Linux, but Clang > on Darwin. Clang has only supported Intel syntax since Clang 14 (13.x can > output assembly in Intel > syntax but can't parse input like that). Some modern tools, e.g. the Rust > compiler and YASM > assembler, may support both but default to Intel syntax. > > That is to say, it is widely assumed that AT&T syntax is default when the > compiler looks like GCC > and the target is x86 or x86_64. > > > > BTW LIU, I've just switched from your 13.0.1 compiler to your 13.1.0. > (Nice ;-) > > Thank you for your interest and support. > > > > -- > Best regards, > LIU Hao > > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [gcc-13.0.1] Anomalous as.exe behaviour
Hi, If I fix the "shr" nameclash (by renaming "shr") I still get "invalid use of register" errors in relation to assembler directives that don't involve any symbols from cpoly.c That is, I think there's something else happening as well. Would you like more detail about this ? In any case, the "-masm=att" takes care of it but is it ok to supply that argument when the system processor is (say) AMD64, and not Intel ? The code that builds the PDL module needs to be portable. I can easily shape that code so that the inclusion of "-masm=att" only happens when the OS is Windows && the compiler is a mingw-w64 port of gcc ... but are there additional considerations regarding portability ? BTW LIU, I've just switched from your 13.0.1 compiler to your 13.1.0. (Nice ;-) Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [gcc-13.0.1] Anomalous as.exe behaviour
On Fri, Apr 28, 2023 at 1:36 AM LIU Hao wrote: > > Anyway `-masm=att` will solve this issue. > Indeed it does. Thank you. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [gcc-13.0.1] Anomalous as.exe behaviour
Hi,
I have 2 snapshots of gcc-13.0.1.
One was built by LH_Mouse, the other by Brecht Sanders (https://winlibs.com
).
LH_Mouse's compiler is tripping over some code that Sanders' build handles
without issue.
Attached are 2 files (cpoly.c and cpoly.h) taken from the source of a perl
module named PDL (
https://cpan.metacpan.org/authors/id/E/ET/ETJ/PDL-2.082.tar.gz).
Placing those 2 files together in an otherwise empty directory is
sufficient to demonstrate the issue.
If, using Sanders's build, I run:
gcc -c -v cpoly.c
then all goes well (see attached good.txt) and cpoly.o is created..
But if I run the same command using LH_Mouse's build, then I get a number
of assembler error messages (see attached bad.txt) ... and no cpoly.o..
Comparing the 2 outputs, I see that Sanders' as.exe presents itself as:
GNU assembler version 2.40 (x86_64-w64-mingw32) using BFD version (Binutils
for MinGW-W64 x86_64, built by Brecht Sanders) 2.40
whereas in LH_Mouse's build it announces itself as:
GNU assembler version 2.40 (x86_64-w64-mingw32) using BFD version (GNU
Binutils) 2.40
Is the different behaviour accounted for by the difference between
"Binutils for MinGW-W64 x86_64" and "GNU Binutils" ?
Or is it something else ?
I've been unable to actually catch the temporary ".s" file that as.exe
creates, so I don't know how the respective contents of that file compare.
How do I get to see what that file contains ?
Cheers,
Rob
#ifdef DEBUGMAIN
void prtc(int n, double p[], double q[]);
void prtz(int n,double zr[], double zi[]);
#endif
int cpoly(double opr[], double opi[], int degree,
double zeror[], double zeroi[]);
#if !defined(FALSE)
#define FALSE (0)
#endif
#if !defined(TRUE)
#define TRUE (1)
#endif
/* Translated from F77 to C, rjrw 10/04/2000 */
/* replaced 'bool' by 'boolvar' to get it to compile on my
linux machine, DJB Aug 02 2000 */
/* algorithm 419 collected algorithms from acm.
algorithm appeared in comm. acm, vol. 15, no. 02, p. 097. */
#include
#include
#include
/*
#if !defined(WIN32) && !defined(_WIN32) && !defined(__APPLE__) &&
!defined(__CYGWIN__)
#include
#endif
*/
#include
/* #define DEBUGMAIN */ /* Set up debugging main, etc. */
#include "cpoly.h"
/* Internal routines */
static void noshft(int l1);
static int fxshft(int l2, double *zr, double *zi);
static int vrshft(int l3, double *zr, double *zi);
static int calct(void);
static void nexth(int boolvar);
static void polyev(int nn, double sr, double si, double pr[], double pi[],
double qr[], double qi[], double *pvr, double *pvi);
static double errev(int nn, double qr[], double qi[], double ms, double mp);
static double cauchy(int nn, double pt[], double q[]);
static double scale(int nn, double pt[]);
static void cdivid(double ar, double ai, double br, double bi,
double *cr, double *ci);
static double cmod(double r, double i);
static void mcon(void);
static int init(int nncr);
/* Internal global variables */
static double *pr,*pi,*hr,*hi,*qpr,*qpi,*qhr,*qhi,*shr,*shi;
static double sr,si,tr,ti,pvr,pvi,are,mre,eta,infin,smalno,base;
static int nn;
#ifdef DEBUGMAIN
/* driver to test cpoly */
int main()
{
int fail;
double p[50],pi[50],zr[50],zi[50];
int i;
printf("Example 1. polynomial with zeros 1,2,...,10.\n");
p[0]=1L;
p[1]=-55L;
p[2]=1320L;
p[3]=-18150L;
p[4]=157773L;
p[5]=-902055L;
p[6] = 3416930L;
p[7]=-8409500L;
p[8]=12753576L;
p[9]=-10628640L;
p[10]=3628800L;
for (i=0;i<11;i++)
pi[i]=0;
prtc(11,p,pi);
fail = cpoly(p,pi,10,zr,zi);
if(fail)
printf("cpoly has failed on this example\n");
prtz (10,zr,zi);
printf("Example 2. zeros on imaginary axis degree 3.\n");
p[0]=1;
p[1]=0;
p[2]=-10001.0001L;
p[3]=0;
pi[0]=0;
pi[1]=-10001.0001L;
pi[2]=0;
pi[3]=1;
prtc(4,p,pi);
fail = cpoly(p,pi,3,zr,zi);
if (fail)
printf("cpoly has failed on this example\n");
prtz(3,zr,zi);
printf("Example 3. zeros at 1+i,1/2*(1+i)1/(2**-9)*(1+i)\n");
p[0]=1.0;
p[1]=-1.998046875L;
p[2]=0.0;
p[3]=.7567065954208374L;
p[4]=-.2002119533717632L;
p[5]=1.271507365163416e-2L;
p[6]=0;
p[7]=-1.154642632172909e-5L;
p[8]=1.584803612786345e-7L;
p[9]=-4.652065399568528e-10L;
p[10]=0;
pi[0]=0;
pi[1]=p[1];
pi[2]=2.658859252929688L;
pi[3]=-7.567065954208374e-1L;
pi[4]=0;
pi[5]=p[5];
pi[6]=-7.820779428584501e-4L;
pi[7]=-p[7];
pi[8]=0;
pi[9]=p[9];
pi[10]=9.094947017729282e-13L;
prtc(11,p,pi);
fail = cpoly(p,pi,10,zr,zi);
if (fail)
printf("cpoly has failed on this example\n");
prtz(10,zr,zi);
printf("Example 4. multiple zeros\n");
p[0]=1L;
p[1]=-10L;
p[2]=3L;
p[3]=284L;
p[4]=-1293L;
p[5]=2374L;
p[6]=-1587L;
p[7]=-920L;
p[8]=2204L;
p[9]=-1344L;
p[10]=288L;
pi[0]=0;
pi[1]=-10L;
pi[2]=100L;
pi[3]=-334L;
pi[4]=200L;
pi[5]=1394L;
pi[6] =-3836L;
pi[7]=4334L;
pi[8]=-2352L;
pi[9]=504L;
pi[10]=0;
prtc(11,p,pi);
fail = cpoly(p,pi,10,zr,zi);
if (fail)
print
Re: [Mingw-w64-public] [gcc-13.0.1] weird issue with 32-bit setjmp.h
On Tue, Apr 18, 2023 at 8:26 PM Martin Storsjö wrote: The most robust way forward would, IMO, be to just stop trying to redefine > it, and stop undeffing/overriding the system's setjmp() function, since > that's what it is going to be using in the end anyway. Yes - and the elegance and simplicity of the patch you've so generously provided strongly supports that opinion. > > See the attached patch, that does seem to work for me at least, tested in > an msys2/mingw32 environment. If you've got MSVC build environments for > Perl, please do try it out there as well, I believe it should work the > same there. > The patch has arrived intact and is testing well. Once I've tested it in both 32-bit and 64-bit environments for gcc-12.2.0, gcc-13.01, and VS-2022, I'll submit a PR to the perl github repo (Duly accredited, of course.) Martin, I appreciate that you've gone "well beyond the call of duty" in coming up with this patch - and I thank you for doing that. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [gcc-13.0.1] weird issue with 32-bit setjmp.h
On Mon, Apr 17, 2023 at 8:56 PM Martin Storsjö wrote: > On Mon, 17 Apr 2023, sisyphus wrote: > > > On Mon, Apr 17, 2023 at 1:02 AM Martin Storsjö wrote: > [snip] > > As you can see, the aim is, for 32-bit builds only, to: > > # define setjmp(x) _setjmp(x) > > > > and, while that works fine with the 12.2.0 setjmp.h, it does not work > with > > the 13.0.1 setjmp.h. > > Well, the perl threads.xs header seems to try to fix things in two ways: > - Defining USE_NO_MINGW_SETJMP_TWO_ARGS, which affects what mingw-w64 > setjmp.h does (making setjmp expand to _setjmp() instead of _setjmp3()), > introduced in 2009 > - Manually undeffing setjmp and redefining it to _setjmp(), introduced in > 2006 (for all windows compilers except Borland, i.e. for MSVC too) Agreed. > The mingw-w64 commit that removed use of USE_NO_MINGW_SETJMP_TWO_ARGS > would have affected the former, but I don't see why it would affect the > latter; if the latter works as intended there would be no need for > USE_NO_MINGW_SETJMP_TWO_ARGS in the first place. Yes - in our 32-bit builds the condition: # if defined(USE_NO_MINGW_SETJMP_TWO_ARGS) || (!defined(__BORLANDC__) && !defined(__MINGW64__)) will be true even if USE_NO_MINGW_SETJMP_TWO_ARGS is NOT defined. In that sense, there's no need to define USE_NO_MINGW_SETJMP_TWO_ARGS. But, wrt the 12.2.0 setjmp.h, USE_NO_MINGW_SETJMP_TWO_ARGS still needs to be defined in order to avoid entering the block of code that begins with: #if !defined(USE_NO_MINGW_SETJMP_TWO_ARGS) The 13.0.1 setjmp.h has no such block ... though I haven't yet properly assessed the impact of that absence. (TODO) Apparently, it's quite ok for MSVC to enter that block. I regularly build threaded 32-bit (and 64-bit) perls using VS-2022,and this is not an issue. > Do the headers EXTERN.h, perl.h and XSUB.h include the system setjmp.h? I > guess they do, since otherwise there's little point in doing the undef of > setjmp after including them. Yes, that's right. > Do those headers end up calling setjmp() > themselves, so that the redefine in threads.xs comes too late? > > I don't think so. It's perl.h that includes setjmp.h (but doesn't explicitly call anything else that contains a match for "setjmp"). XSUB.h undefs setjmp, and then defines setjmp to PerlProc_setjmp, but takes no other action (involving either 'setjmp' or 'PerlProc_setjmp'). In threads.xs, setjmp is immediately then undeffed yet again. > In that case it's understandable, but wouldn't the same issue (using the > system's default setjmp instead of the one Perl tries to redefine it to) > hit other compilers like MSVC too? > > So in short, we'd need to know which code, where, ends up calling _setjmp3 > instead of _setjmp, despite threads.xs's attempts to redefine it. > > >> On a lower level, since commit > >> 82347ded0d43a80de68ba6a35a209717bded5f28a in 2009, mingw-w64's setjmp.h > >> has been using _setjmp3 for i386, while setting the > >> USE_NO_MINGW_SETJMP_TWO_ARGS define makes it revert to using _setjmp. > >> > >> We weren't aware of any issues with using _setjmp3 (and if there are, > >> maybe we should revisit that change from 2909?) - ideally user code > >> shouldn't need to know or care about this - the defaults are supposed to > >> work. > >> > > > > Yes - that might be pertinent to the issue > > But the current threads.xs source just undefs that setjmp.h definition > and > > then defines setjmp() back to using _setjmp(). > > So I don't see that reverting 82347ded0d43a80de68b6a35a209717bded5f28a > will > > necessarily help. > > I'm not exactly sure what's going on here, but I'm quite sure that > reverting that commit would fix things again. Didn't you say that picking > the setjmp.h header from your gcc 12 build into your gcc 13 build made > things work again? I believe that's fundamentally what reverting that > commit would do. Best thing would be for me to actually test what you have in mind. What does this reverted setjmp.h exactly look like ? (A patch that I can apply would suffice.) Could I then simply test this reverted header by inserting it into my current gcc-13.0.1 installation, as a replacement for the setjmp.h originally provided ? Or does this reversion require that gcc-13.0.1 be rebuilt ? (I'm not set up to build gcc from source, and would prefer not to.) The 12.2.0 version of setjmp.h caters for a setjmp() function that takes a single jmp_buf argument. It looks to me that the 13.0.1 version of setjmp.h does not provide that option. > In case it's relevant, we use only msvcrt compilers to bui
Re: [Mingw-w64-public] [gcc-13.0.1] weird issue with 32-bit setjmp.h
On Mon, Apr 17, 2023 at 1:02 AM Martin Storsjö wrote: > mingw-w64 never defined USE_NO_MINGW_SETJMP_TWO_ARGS. Do the perl sources > define it? > Yes - and for quite a long time. (But only for 32-bit builds of course.) https://github.com/Perl/perl5/blob/blead/dist/threads/threads.xs begins with ### #define PERL_NO_GET_CONTEXT /* Workaround for mingw 32-bit compiler by mingw-w64.sf.net - has to come before any #include. * It also defines USE_NO_MINGW_SETJMP_TWO_ARGS for the mingw.org 32-bit compilers ... but * that's ok as that compiler makes no use of that symbol anyway */ #if defined(WIN32) && defined(__MINGW32__) && !defined(__MINGW64__) # define USE_NO_MINGW_SETJMP_TWO_ARGS 1 #endif #include "EXTERN.h" #include "perl.h" #include "XSUB.h" /* Workaround for XSUB.h bug under WIN32 */ #ifdef WIN32 # undef setjmp # if defined(USE_NO_MINGW_SETJMP_TWO_ARGS) || (!defined(__BORLANDC__) && !defined(__MINGW64__)) #define setjmp(x) _setjmp(x) # endif # if defined(__MINGW64__) #include #define setjmp(x) _setjmpex((x), mingw_getsp()) # endif #endif ## As you can see, the aim is, for 32-bit builds only, to: # define setjmp(x) _setjmp(x) and, while that works fine with the 12.2.0 setjmp.h, it does not work with the 13.0.1 setjmp.h. On a lower level, since commit 82347ded0d43a80de68ba 6a35a209717bded5f28a in 2009, mingw-w64's setjmp.h has been using _setjmp3 for i386, while setting > the USE_NO_MINGW_SETJMP_TWO_ARGS define makes it revert to using _setjmp. > > We weren't aware of any issues with using _setjmp3 (and if there are, > maybe we should revisit that change from 2909?) - ideally user code > shouldn't need to know or care about this - the defaults are supposed to > work. > Yes - that might be pertinent to the issue But the current threads.xs source just undefs that setjmp.h definition and then defines setjmp() back to using _setjmp(). So I don't see that reverting 82347ded0d43a80de68b6a35a209717bded5f28a will necessarily help. In case it's relevant, we use only msvcrt compilers to build perl. (Perl source currently won't build with ucrt - because of the abundance of msvcrt-specific code in certain places, I expect.) FAIK, it's quite possible that the perl source could be refactored to use _setjmp3(). Should we (ie perl maintainers) be trying to do just that ? Thanks for the explanation, Martin. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [gcc-13.0.1] weird issue with 32-bit setjmp.h
Hi, I was having difficulty building threaded 32-bit perl using gcc-13.0.1. No problem building threaded 64-bit perl with gcc-13.0.1. Also no problem building threaded perls (both 32-bit and 64-bit) with gcc-12.2.0 or earlier. I tried fixing the issue by making a few modifications to dist/threads.xs in the perl source, but to no avail. In desperation, I reverted dist/threads.xs back to its original state and simply replaced the 32-bit gcc-13.0.1 version of setjmp.h with the 32-bit gcc-12.2.0 version of setjmp.h. I was then able to build the 32-bit threaded perl using the gcc-13.0.1 compiler without issue. My question therefore is: If the 32-bit 12.2.0 version of setjmp.h works fine with 32-bit gcc-13.0.1, then why was it altered ? Maybe that's a dumb question - hopefully not sufficiently dumb as to cause offence. As regards the building of 32-bit threaded perl, the main stumbling block seemed to be that setjmp.h in gcc-13.0.1 no longer checks to see if USE_NO_MINGW_SETJMP_TWO_ARGS is not defined. AIUI, the omission of that check for the 64-bit version of setjmp.h is quite ok - as USE_NO_MINGW_SETJMP_TWO_ARGS is only ever defined for 32-bit builds. Hence, it comes as no surprise that it's only the 32-bit builds of perl that are being broken by the omission of the check. If reverting to the older form of 32-bit setjmp.h is really NOT the correct solution here, then I guess we have to modify the perl source - for which I'll seek the assistance of the perl developers. Thoughts and advice are, as always, most welcome. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Weird pthreads anomaly with gcc-13.0.1 and mpfr
Now testing fine for me. Thanks, Rob On Wed, Apr 12, 2023 at 5:40 PM LIU Hao wrote: > 在 2023/4/12 09:56, sisyphus 写道: > > Thanks LIU. > > No urgency, from my point of view. > > When the amended version hits https://gcc-mcf.lhmouse.com/, I'll > download > > it and try it out. > > > This should be fixed now: > > https://github.com/lhmouse/mcfgthread/compare/66326556e26f07872c797bbdbea5e398de32e66d..fa18d75a1762d3a0269ee1566f70aebfb5a36017 > > > > > -- > Best regards, > LIU Hao > > > > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Weird pthreads anomaly with gcc-13.0.1 and mpfr
Thanks LIU. No urgency, from my point of view. When the amended version hits https://gcc-mcf.lhmouse.com/, I'll download it and try it out. Cheers, Rob On Tue, Apr 11, 2023 at 11:24 PM LIU Hao wrote: > 在 2023-04-11 21:14, LIU Hao 写道: > > It's because `__emutls_get_address()` returns two distinct values in > consecutive calls with the same > > descriptor in the same thread, so the second reference to the thread > local > > `__gmpfr_default_fp_bit_precision` (defined in 'set_dfl_prec.c') gets a > fresh object with its > > default value. > > > > This should not happen. Please give me some time to work on this. > > > Looks like emutls could not set the thread-specific value for 'foreign > threads' (those not created > by mcfgthread). Although this is by design, I do think the MPFR > expectation should be reasonably > supported. I will fix this in a couple of days. > > > This works (users should use `std::thread` or C11 `thrd_create()` instead): > > ``` > #include > > (...) > __gthread_t thread1; > iret1 = __gthread_create( &thread1, foo, (void*) message1); > __gthread_join( thread1, NULL); > (...) > ``` > > > -- > Best regards, > LIU Hao > > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Weird pthreads anomaly with gcc-13.0.1 and mpfr
Hi,
The demo program:
#
#include
#include
#include
#include
void *foo( void *ptr );
int main(void) {
pthread_t thread1;
char *message1 = "precision in thread1:";
int iret1;
if(mpfr_buildopt_tls_p()) printf("mpfr was built with TLS support\n");
else printf("mpfr was NOT built with TLS support\n");
iret1 = pthread_create( &thread1, NULL, foo, (void*) message1);
pthread_join( thread1, NULL);
printf("pthread_create() returned: %d\n",iret1);
return 0;
}
void *foo( void * ptr) {
char *message;
message = (char *) ptr;
mpfr_set_default_prec(201);
printf("%s %d\n", message, mpfr_get_default_prec());
pthread_exit (NULL);
}
When built using gcc-12.2.0 (or earlier) this outputs precisely what I
expect:
mpfr was built with TLS support
precision in thread1: 201
pthread_create() returned: 0
However, not so with gcc-13.0.1
I have 2 builds of gcc-13.0.1:
gcc version 13.0.1 20230406 (experimental) (GCC with MCF thread model,
built by LH_Mouse)
and
gcc version 13.0.1 20230402 (experimental) (MinGW-W64
x86_64-msvcrt-mcf-seh, built by Brecht Sanders)
When I build that demo with those 13.0.1 compilers I get:
mpfr was built with TLS support
precision in thread1: 53
pthread_create() returned: 0
That is, the "mpfr_set_default_precision(201)" call made in foo() is
apparently ignored, and the initial default precision of 53 is output.
I've run this by the mpfr developers and they don't think it's an mpfr
issue. (Neither do I.)
Those 2 gcc-13.0.1 compilers enable MCF threads and I wonder if that's part
of the problem.
If someone could point me to a 13.0.1 compiler that is not MFC thread
enabled then I might be able to clarify that.
(All of my gcc-12 and earlier compilers do not enable MCF threads.)
If it's not the MFC threads capability that's the problem, then I'm
thinking that the problem must be elsewhere in gcc-13.0.1.
Should I file a bug report about this ?
Also, is anyone in a position to be able to confirm this behaviour with
gcc-13.0.1 ?
I've established that it doesn't matter whether the gmp/mpfr libs are
static or shared.
I've also established that it doesn't matter whether the gmp/mpfr libraries
I link to were built by gcc-12.2.0 or 13.0.1.
The out[put I get seems to be solely dependent upon whether I compile the
program using gcc-13.0.1 or not.
Cheers,
Rob
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] fix pow() floating point imprecision
On Tue, Jun 14, 2022 at 1:57 AM LIU Hao wrote: > ... > I am putting this on hold for a while, until I have some time to look into > it. > > I think the different results can also be expressed as: (1/3) ^ 5 produces 3f70db20a88f4695 1 / (3 ^ 5) produces 3f70db20a88f4696 The latter is a far less error prone approach, and therefore yields the result that should be provided for (1 / 3) ^ 5. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Detect presence of Windows implementations of inet_ntop and inet_npton
On Fri, Jun 3, 2022 at 2:16 PM LIU Hao wrote: > ... > I still consider it a bad idea to declare functions with the same names as > standard ones. Why not > rename it to `my_inet_ntop` for example? it would be much less error-prone. > > Yes - there's wisdom in what you say. However, "acting wisely" is something I'm rarely accused of ;-) I don't know why it has been done the way it is, but I think I'll just take the easy way out and isolate those 2 functions inside an "#ifndef InetNtopA" block. Thank you, LIU, for the attention you've given to this I appreciate the help. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Detect presence of Windows implementations of inet_ntop and inet_npton
On Fri, Jun 3, 2022 at 12:28 AM sisyphus wrote:
> On Thu, Jun 2, 2022 at 10:47 PM LIU Hao wrote:
>
>> 在 2022/6/2 20:37, sisyphus 写道:
>> > On Thu, Jun 2, 2022 at 12:28 PM sisyphus wrote:
>>
>
>
> What's the error? Is it caused by re-declaration with a different calling
>> convention i.e.
>> `__stdcall` vs. `__cdecl`?
>>
>> Socket.xs:101:12: error: static declaration of 'inet_pton' follows
> non-static declaration
>
>
> Socket.xs:123:20: error: conflicting types for 'inet_ntop' ... details specified>
>
>>
>> This issue is not specific to mingw-w64. If MSVC was used to build Perl,
>> there would be the same
>> error, because we do the same.
>>
>>
> Yes - but the Perl source can direct MSVC and mingw-w64 down different
> paths.
> I don't exactly know why my VS 2019 builds don't need the patch but I
> ought to work out why :-(
>
>
On further investigation, MSVC and mingw-w64 are *not* taking a different
path through the perl source.
There seems to be a difference in behaviour between mingw-w64 and Visual
Studio 2019.
Here is a C demo.
```
/* try.c */
#include
#include
static int inet_pton(int af, const char *src, void *dst);
static const char *inet_ntop(int af, const void *src, char *dst, socklen_t
size);
int main(void) {
#if defined(__MINGW64_VERSION_MAJOR)
printf("mingw runtime version: %d\n", __MINGW64_VERSION_MAJOR);
#endif
#if defined(_MSC_VER)
printf ("MSVC version: %d\n", _MSC_VER);
#endif
#if defined(InetNtopA)
printf("InetNtopA defined\n");
#endif
return 0;
}
```
It contains the very same (troublesome) inet_pton and inet_ntop prototypes
contained in cpan/Socket/Socket.xs (in the perl source).
The executable builds fine on my VS2019 compiler. When executed it outputs:
MSVC version: 1924
InetNtopA defined
It does, however, issue a compile-time warning in relation to the second
(inet_ntop) of the two declarations:
try.c(7): warning C4028: formal parameter 4 different from declaration
But, with my mingw-w64 port of gcc-11.3.0, runtime 10, (obtained from
https://winlibs.com) the build blows up in exactly the same way as the Perl
build blows up:
```
C:\_32\C>gcc -o try.exe try.c
try.c:6:12: error: static declaration of 'inet_pton' follows non-static
declaration
6 | static int inet_pton(int af, const char *src, void *dst);
|^
In file included from try.c:4:
c:\_64\winlibs-gcc-1130\mingw64\x86_64-w64-mingw32\include\ws2tcpip.h:408:32:
note: previous declaration of 'inet_pton' with type 'INT(INT, const CHAR
*, void *)' {aka 'int(int, const char *, void *)'}
408 | WINSOCK_API_LINKAGE INT WSAAPI InetPtonA(INT Family, LPCSTR
pStringBuf, PVOID pAddr);
|^
try.c:7:20: error: conflicting types for 'inet_ntop'; have 'const char
*(int, const void *, char *, socklen_t)' {aka 'const char *(int, const
void *, char *, int)'}
7 | static const char *inet_ntop(int af, const void *src, char *dst,
socklen_t size);
|^
In file included from try.c:4:
c:\_64\winlibs-gcc-1130\mingw64\x86_64-w64-mingw32\include\ws2tcpip.h:401:35:
note: previous declaration of 'inet_ntop' with type 'const CHAR *(INT,
const void
*, CHAR *, size_t)' {aka 'const char *(int, const void *, char *, long
long unsigned int)'}
401 | WINSOCK_API_LINKAGE LPCSTR WSAAPI InetNtopA(INT Family, LPCVOID
pAddr, LPSTR pStringBuf, size_t StringBufSize);
| ^
```
The same problem arises with mingw runtime 9, but earlier runtimes are fine
because InetNtopA does not get defined.
If I comment out the 2 prototypes, then there's (pretty obviously) no issue
with either gcc or msvc.
Is this just a difference in what gcc and MSVC regard as fatal errors ?
AFAICT, this Perl patch I'm trying to get right does not need to be applied
when the compiler is Visual Studio 2019.
However, applying it to Visual Studio 2019 builds doesn't seem to break
anything.
Cheers,
Rob
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Detect presence of Windows implementations of inet_ntop and inet_npton
On Thu, Jun 2, 2022 at 10:47 PM LIU Hao wrote: > 在 2022/6/2 20:37, sisyphus 写道: > > On Thu, Jun 2, 2022 at 12:28 PM sisyphus wrote: > > > >> Hi, > >> In the Perl source, we hard code our own implementation of inet_ntop() > >> and inet_pton(). > >> This results in a fatal compile-time error if the Windows (ws2tcpip.h) > >> implementation is also present. > >> > > What's the error? Is it caused by re-declaration with a different calling > convention i.e. > `__stdcall` vs. `__cdecl`? > > Socket.xs:101:12: error: static declaration of 'inet_pton' follows non-static declaration Socket.xs:123:20: error: conflicting types for 'inet_ntop' ... > > >> I'm therefore looking for a portable way of detecting whether the > compiler > >> is a mingw-w64 one && the Windows implementation of those 2 functions > has > >> been found. > >> > > This issue is not specific to mingw-w64. If MSVC was used to build Perl, > there would be the same > error, because we do the same. > > Yes - but the Perl source can direct MSVC and mingw-w64 down different paths. I don't exactly know why my VS 2019 builds don't need the patch but I ought to work out why :-( > My suggestion is to check for the macro `InetNtopA` like this: > > Yes - that should work, and much cleaner than my attempt. Thanks for the clear thinking !! >``` >#ifdef InetNtopA >/* Windows-specific stuff here. */ >#else >/* Linux, BSD, etc. */ >#endif > ``` > Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Detect presence of Windows implementations of inet_ntop and inet_npton
On Thu, Jun 2, 2022 at 12:28 PM sisyphus wrote: > Hi, > In the Perl source, we hard code our own implementation of inet_ntop() > and inet_pton(). > This results in a fatal compile-time error if the Windows (ws2tcpip.h) > implementation is also present. > > I'm therefore looking for a portable way of detecting whether the compiler > is a mingw-w64 one && the Windows implementation of those 2 functions has > been found. > > #if !defined(__MINGW64_VERSION_MAJOR) || __GNUC__ < 4 || (__GNUC__ == 4 && > __GNUC__ < 8) || _WIN32_WINNT < 0x0600 || !defined(_WS2TCPIP_H_) > /*** the Windows implementation has not been found, and we use the Perl > one ***/ > #else > /*** the Windows implementation has been found; we must hide the Perl one > ***/ > #endif > > Does that look to be a sane way of doing it ? > > Note that I'm concerned only with mingw-w64 compilers. Oddly, this issue > hasn't arisen with MS compilers - though I've tested only with Visual > Studio 2019. > I'm not obliged to care (and I don't) if the compiler in use is neither > mingw-w64 nor non-recent MS. > > I noticed in mingw-w64 ports of gcc-4.7.3, that ws2tcpip.h makes no > mention of the 2 symbols "inet_ntop" and "inet_pton", but that both symbols > are present in gcc-4.8.2. > I'm therefore guessing that the 2 symbols first turned up in the mingw-w64 > port of gcc-4.8.0. > And I notice that even when they are present in ws2tcpip.h, it's only if > _WIN32__WINNT >= 0x600. > > Please let me know if you see corrections or improvements that should (or > could) be made. > > A couple of things have occurred to me since posting: 1) That there's no point in examining the condition "__GNUC__ < 4" where mingw-w64 ports of gcc are concerned. That condition will always be false. 2) That instead of referencing the version of gcc, I should be referencing the version of the mingw-w64 runtime. Which was the first runtime in which ws2tcpip.h defined the symbols inet_pton and inet_ntop ? (Or where might I find the answer ?) Those symbols are found in ws2tcpip.h in runtime 3.1, but not in runtime 2.0 ... so I'm guessing that runtime 3.0 is where they first appeared. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Detect presence of Windows implementations of inet_ntop and inet_npton
Hi, In the Perl source, we hard code our own implementation of inet_ntop() and inet_pton(). This results in a fatal compile-time error if the Windows (ws2tcpip.h) implementation is also present. I'm therefore looking for a portable way of detecting whether the compiler is a mingw-w64 one && the Windows implementation of those 2 functions has been found. #if !defined(__MINGW64_VERSION_MAJOR) || __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC__ < 8) || _WIN32_WINNT < 0x0600 || !defined(_WS2TCPIP_H_) /*** the Windows implementation has not been found, and we use the Perl one ***/ #else /*** the Windows implementation has been found; we must hide the Perl one ***/ #endif Does that look to be a sane way of doing it ? Note that I'm concerned only with mingw-w64 compilers. Oddly, this issue hasn't arisen with MS compilers - though I've tested only with Visual Studio 2019. I'm not obliged to care (and I don't) if the compiler in use is neither mingw-w64 nor non-recent MS. I noticed in mingw-w64 ports of gcc-4.7.3, that ws2tcpip.h makes no mention of the 2 symbols "inet_ntop" and "inet_pton", but that both symbols are present in gcc-4.8.2. I'm therefore guessing that the 2 symbols first turned up in the mingw-w64 port of gcc-4.8.0. And I notice that even when they are present in ws2tcpip.h, it's only if _WIN32__WINNT >= 0x600. Please let me know if you see corrections or improvements that should (or could) be made. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Determining mingw runtime version
On Tue, Mar 8, 2022 at 3:18 AM Stephen Kitt wrote: > > You can ask GCC itself: > > $ x86_64-w64-mingw32-gcc -E -include windows.h - > <<<"__MINGW64_VERSION_MAJOR" | tail -n 1 > 9 > > Nice idea - works fine in a bash shell (cygwin and msys2) for me, but not in a cmd shell. With cmd.exe, there's no guarantee that 'tail' will be present. In the end, I've just gone with a C file that prints out __MINGW64_VERSION_STR (or prints "undef" if __MINGW64_VERSION_STR is not defined). And then the one-line command I've used is CC -o rt.exe rt.c 1>nul 2>&1 && rt It would have been nice to avoid compiling a C source file into an executable ... but the alternatives were beginning to look next to impossible (or worse ;-) Thanks Gisle, Stephen, for presenting the other options. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Determining mingw runtime version
On Mon, Mar 7, 2022 at 6:27 PM Gisle Vanem wrote: > > > A command that displays only the value of __MINGW64_VERSION_MAJOR would > > probably suffice. > > Some .bat-file with: > > setlocal > set %find=%WinDir%\system32\find.exe > if %MINGW32%. == . set MINGW32=f:\MinGW32\TDM-gcc > > type "%MINGW32%\x86_64-w64-mingw32\include\_mingw_mac.h" | ^ >%find% "__MINGW64_VERSION_MAJOR" | %find% "#define") > > -- > Thank you, Gisle - that sounds like a good place to start. Unfortunately that approach gives me output of (eg): #define __MINGW64_VERSION_MAJOR 8 whereas I'm hoping to obtain just the value of __MINGW64_VERSION_MAJOR , and nothing else. (I want to retrieve that value inside a Makefile that will be run in a cmd.exe shell.) According to https://superuser.com/questions/1488014/batch-file-extract-number-from-string-using-regex there is some regex capability with batch files. Not sure if there's a solution for me in that, but I'll investigate that possibility. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Determining mingw runtime version
Hi, Is there a simple command that I can run to see the (mingw-w64) runtime version number - something akin to "gcc -dumpversion" ? A command that displays only the value of __MINGW64_VERSION_MAJOR would probably suffice. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] WIN32_LEAN_AND_MEAN changes from runtime-8 to runtime-9
On Fri, Aug 27, 2021 at 3:56 PM Biswapriyo Nath wrote: > I don't know what the issue is. But to compile perl with mingw-w64 > toolchain, I have to patch some files. You can see the changes here > https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-perl. > > I'm dealing with the issue that is addressed by https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-perl/007-use-winsock-socket-functions.patch My solution ( https://github.com/Perl/perl5/issues/18911#issuecomment-907797056) involves less patching. It works fine with runtime v9, and also with runtime v8 (and presumably earlier versions, too. However, I wouldn't be surprised if it's inferior to your approach. I'll do some checking and testing. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] WIN32_LEAN_AND_MEAN changes from runtime-8 to runtime-9
On Thu, Aug 26, 2021 at 10:12 PM Biswapriyo Nath wrote: > The output from v9 matches with the output of same code compiled with > MSVC. > Thank you - I've since checked that, and found it to be so. (Not that I doubted you ;-) Interestingly, perl builds fine for me straight out of the box with MSVC (Visual Studio-2019). This indicates that MSVC and MinGW-w64 (runtime-v9) must be taking different paths through this particular area of the perl source. I think my best chance is therefore to make the MinGW-w64 (runtime-v9) compilation follow the same path as the MSVC compilation - but, of course, that's OT for this list. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] WIN32_LEAN_AND_MEAN changes from runtime-8 to runtime-9
Hi,
The following script demonstrates a change between runtime version 8 and
runtime version 9.
/***/
#define WIN32_LEAN_AND_MEAN
#include
#ifndef _WINSOCKAPI_
#define NO__WINSOCKAPI_YET
# include
# include
#endif
#include
int main(void) {
#ifdef NO__WINSOCKAPI_YET
printf("_WINSOCKAPI_ not defined by windows.h\n");
#endif
#ifdef _WINSOCKAPI_
printf("_WINSOCKAPI_ now defined\n");
#endif
#ifdef POLLWRBAND
printf("POLLWRBAND defined\n");
#endif
return 0;
}
/***/
With 64-bit gcc-11.1.0, runtime version 8, it outputs:
_WINSOCKAPI_ not defined by windows.h
_WINSOCKAPI_ now defined
With 64-bit gcc-11.1.0, runtime version 9 (and 64-bit gcc-11.2.0, runtime
version 9) it outputs:
_WINSOCKAPI_ not defined by windows.h
_WINSOCKAPI_ now defined
POLLWRBAND defined
This seems odd to me.
Is that as expected and intended ?
I use the mingw-w64 ports provided by https://winlibs.com/
If I don't define WIN32_LEAN_AND_MEAN, then the outputs match - with
POLLWRBAND not being defined for both runtime versions.
This behaviour with v9 breaks builds of recent versions of perl, where we
hit source code like:
#if (defined(HAS_POLL) && defined(I_POLL)) || defined(POLLWRBAND)
# include
This breaks the perl build when POLLWRBAND is defined because there is no
file name poll.h to be found.
The obvious solution is to not define WIN32_LEAN_MEAN, and that's a
solution that works, but I just wanted to first check here that the failure
lies with the perl source and not with version 9.0.0 of the runtime.
There is also one other issue for perl being triggered by runtime-9 (and
for which I do already have a workaround), but I haven't yet worked out
exactly how it's triggered - so I won't ask about it until I have more
complete information.
Cheers,
Rob
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] bug in sin(pi) ?
On Mon, Jun 14, 2021 at 1:33 PM Liu Hao wrote: > 在 6/11/21 12:26 PM, sisyphus 写道: > [snip] > The loss of accuracy itself with sin() annoys me a little - mainly because > > I'm seeing it as being unnecessary. (Perhaps I'm being unfair. Is it > > actually necessary ?) > > With the mpfr library, I can take the double 3.1415926535897931 and > > calculate the sine of that exact double value to 5000-bit precision. > > That value turns out to be 1.224646799147353177226...e-16 which agrees > very > > nicely with the double precision figure of 1.2246467991473532e-16 that > the > > gcc compiler comes up with. > > > > MPFR is a professional math library and it is its obligation to guarantee > such high precision, even > if such an operation may be slow and unacceptable under some circumstances > (e.g. video games). > > My purpose in referring to mpfr was simply to demonstrate that the sin() implementation used by the compiler performs the calculation of sin( 3.1415926535897931) accurately and correctly for 53 bits of precision. > > Anyway ... please let me know if I should file a bug report about this, > and > > I shall oblige. > > > > > > I think you should. It's unlikely that people would agree on a solution, > but that doesn't matter. > Thank you, to all respondents. I've just created https://sourceforge.net/p/mingw-w64/bugs/904/ It's pretty much just a copy'n'paste of my original post, but it does also reference this thread. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] bug in sin(pi) ?
On Fri, Jun 11, 2021 at 1:22 AM LRN wrote: > On 10.06.2021 10:03, Liu Hao wrote: > [snip] > > Before doing that, I would like to ask, does the inaccuracy really > matter? > > I always assumed that when dealing with floating-point math there's no > such > thing as "yielding precisely this number". You get something that is > accurate > to a certain point. If an implementation gives you something that is less > accurate than other implementations, that's not good, but shouldn't have > much > influence on your calculations. > > Why is this suddenly a concern? > > My concern is that sin() is supposed to be returning a 53-bit precision value, and yet, for the given example, it arbitrarily returns a value that has precision of no more than 15 bits. If mingw is prepared to allow such behaviour, then one starts to wonder where else it might be occurring. Does it also happen with cos() ? Why would such behaviour be deemed acceptable for sin() but not for (say) the division operator ? It certainly makes me less confident about the general reliability of mingw's math operations. The loss of accuracy itself with sin() annoys me a little - mainly because I'm seeing it as being unnecessary. (Perhaps I'm being unfair. Is it actually necessary ?) With the mpfr library, I can take the double 3.1415926535897931 and calculate the sine of that exact double value to 5000-bit precision. That value turns out to be 1.224646799147353177226...e-16 which agrees very nicely with the double precision figure of 1.2246467991473532e-16 that the gcc compiler comes up with. I'm not going to get too excited over this, but having this current implementation of the sin() function strikes me as being a bit amateurish and rather unimpressive. Anyway ... please let me know if I should file a bug report about this, and I shall oblige. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] bug in sin(pi) ?
Hi,
The demo:
##
/* trig.c */
#define __USE_MINGW_ANSI_STDIO 1
#include
#include
#include
int main( int argc, char *argv[] ) {
double s1 = sin(strtod(argv[1], NULL));
double s2 = sin(3.1415926535897931);
printf("gcc version: %d.%d.%d\n", __GNUC__, __GNUC_MINOR__,
__GNUC_PATCHLEVEL__);
printf("runtime: %d.%d\n", __MINGW64_VERSION_MAJOR,
__MINGW64_VERSION_MINOR );
printf("%.17g %a\n", s1, s1);
printf("%.17g %a\n", s2, s2);
return 0;
}
##
I build the executable with:
gcc -o try.exe try.c
It outputs:
C:\_32\C>trig 3.1415926535897931
gcc version: 11.1.0
runtime: 9.0
1.2246063538223773e-16 0x8.d3p-56
1.2246467991473532e-16 0x8.d313198a2e038p-56
As you can see, the calculation of s1, which was performed at run time,
has been seriously truncated (down to 12-15 bits).
OTOH, the calculation of s2, which (I assume) was performed at compile
time, is fine.
As we start chopping digits off the end of the argument, the precision of
the value returned during run time starts to increase.
But even when the argument is reduced to 3.1415, we still lose the last bit:
C:\_32\C>trig 3.1415
gcc version: 11.1.0
runtime: 9.0
9.2653589660490244e-05 0xc.24f0465fb0bap-17
9.2653589660490258e-05 0xc.24f0465fb0ba8p-17
AFAICS, it's the same behaviour with:
gcc-8.30, runtime 6
gcc-9.3.0, runtime 7
gcc-10.2.0, runtime 8
Building with optimizations 01, 02, 03 makes no difference to the output.
I just want to check that the bug report should be filed against mingw-w64,
not gcc ?
Cheers,
Rob
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MINGW trademark claims
On Sat, May 8, 2021 at 11:13 PM Zach Bacon wrote: > Because of trademarks, if it has mingw in the name, then it could > constitute as a violation, regardless if it has -w64 in it or not. > Yeah, but that needs to be tested in a court first. Keith has implied that it's "fait accompli", and that's just bullshit. Still ... I guess it pays to be mindful of the possibilities ... Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MINGW trademark claims
On Sat, May 8, 2021 at 9:28 PM Joachim Wuttke wrote: > Keith Marshall argues at https://stackoverflow.com/a/62865466/1017348 > that you are doing illegal things, and that perhaps I am rendering > myself culpable by recommending use of your software. > > What is your position on this? > > :- Sorry ...(I assume that) I'm not one of the people to whom this post is addressed. But it's Sat'dy night over here, I've had half a bottle of wine, and I just couldn't resist the invitation. Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] binary releases
On Tue, Sep 22, 2020 at 9:28 PM wrote: > [snip] > > yes, I plan to continue releasing compiler builds but they will be > hosted here: https://github.com/niXman/mingw-builds/releases Great news !! Cheers, Rob ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] runtime difference between code compiled with VS and gcc
On Wed, Aug 26, 2020 at 7:01 PM Vincent Torri
wrote:
> -
> #include
>
> #include
>
> int main(int argc, char* argv[])
> {
> FILE* f;
> if (argc < 2)
> {
> printf("%s\n", argv[0]);
> return 1;
> }
>
> f = fopen(argv[1], "rb");
> if (!f)
> printf("bad\n");
> else
> printf("good\n");
> return 0;
> }
> -
>
>
Looking at the code, I see no need for the inclusion of windows.h.
I take it that the inclusion of windows.h is merely an oversight, and that
the differing behaviour does not depend on it ?
Cheers,
Rob
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Spam from Steve The Man
Aaaah ... thanks for the info. I've now submitted a bug report about this to the correct place: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756 And I've added a note at https://sourceforge.net/p/mingw-w64/bugs/728 indicating that it doesn't really belong there. Can I close that report myself ? (I couldn't see an obvious way of doing it.) Cheers, Rob On Sat, Apr 25, 2020 at 2:32 PM JonY via Mingw-w64-public < mingw-w64-public@lists.sourceforge.net> wrote: > On 4/24/20 1:30 PM, sisyphus wrote: > > Bloody Hell, > > I know it's not really spam, but could you guys at least address > something > > that I care about (eg https://sourceforge.net/p/mingw-w64/bugs/728 ) > > instead of all the piffle that has been filling this list of late ?? > > > > Or maybe I should just unsubscribe. I'll accept such a view as valid > > advice, and I might even then act upon that recommendation. > > ( I'm bullshitting, of course. I'll stay subscribed, no matter what. ) > > > > It would, however, be really nice if someone could actually do something > > about #728. > > I'm not the sharpest tool in the shed, but #728 does appear to afflict > only > > Windows (including Cygwin, BTW), so I'm thinking it's specific to mingw. > > > > Cheers, > > Robh > > > > I thought it was related to the DFP stuff I did in 2013, but no this is > in gcc libquadmath, so this makes it a gcc issue. > > Unfortunately, I don't know enough about floating points to fix this issue. > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Spam from Steve The Man
Bloody Hell, I know it's not really spam, but could you guys at least address something that I care about (eg https://sourceforge.net/p/mingw-w64/bugs/728 ) instead of all the piffle that has been filling this list of late ?? Or maybe I should just unsubscribe. I'll accept such a view as valid advice, and I might even then act upon that recommendation. ( I'm bullshitting, of course. I'll stay subscribed, no matter what. ) It would, however, be really nice if someone could actually do something about #728. I'm not the sharpest tool in the shed, but #728 does appear to afflict only Windows (including Cygwin, BTW), so I'm thinking it's specific to mingw. Cheers, Robh ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 08/12] math: Properly propagate input NANs in a few functions
Martin,
Thanks for all your work.
I couldn't locate mingw-w64-crt/math/x86/pow.def.h on the internet (URL ?),
but I assume the patch is concerned with raising a NaN to a power.
Given that raising an input NaN to a power does not always result in a NaN,
it seems a little suspicious that this has come up under the subject
"properly propagate input NANs".
In short - I'm simply seeking reassurance that the case of raising a NaN to
the power of zero is still being correctly handled.
Cheers,
Rob
On Wed, Jul 31, 2019 at 7:08 AM Martin Storsjö wrote:
> While the C99 standard doesn't explicitly require this, the standard
> says it is recommended (F.9.13).
>
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-crt/math/arm-common/remquo.c | 4
> mingw-w64-crt/math/arm-common/remquof.c | 4
> mingw-w64-crt/math/erfl.c | 3 +++
> mingw-w64-crt/math/lgammal.c| 2 +-
> mingw-w64-crt/math/tgammal.c| 2 +-
> mingw-w64-crt/math/x86/acosh.def.h | 7 ++-
> mingw-w64-crt/math/x86/log.def.h| 4 ++--
> mingw-w64-crt/math/x86/pow.def.h| 10 +++---
> 8 files changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/mingw-w64-crt/math/arm-common/remquo.c
> b/mingw-w64-crt/math/arm-common/remquo.c
> index 6a97ade22..d8ec534fd 100644
> --- a/mingw-w64-crt/math/arm-common/remquo.c
> +++ b/mingw-w64-crt/math/arm-common/remquo.c
> @@ -9,6 +9,10 @@
>
> double remquo(double x, double y, int *quo)
> {
> + if (isnan(x))
> +return x;
> + if (isnan(y))
> +return y;
>if (isinf(x) || y == 0)
> return NAN;
>double div = x/y;
> diff --git a/mingw-w64-crt/math/arm-common/remquof.c
> b/mingw-w64-crt/math/arm-common/remquof.c
> index c395b2bdd..d92800294 100644
> --- a/mingw-w64-crt/math/arm-common/remquof.c
> +++ b/mingw-w64-crt/math/arm-common/remquof.c
> @@ -9,6 +9,10 @@
>
> float remquof(float x, float y, int *quo)
> {
> + if (isnan(x))
> +return x;
> + if (isnan(y))
> +return y;
>if (isinf(x) || y == 0)
> return NAN;
>float div = x/y;
> diff --git a/mingw-w64-crt/math/erfl.c b/mingw-w64-crt/math/erfl.c
> index 50dcbb350..1408cf542 100644
> --- a/mingw-w64-crt/math/erfl.c
> +++ b/mingw-w64-crt/math/erfl.c
> @@ -254,6 +254,9 @@ long double erfcl(long double a)
> if (isinf (a))
> return (signbit(a) ? 2.0 : 0.0);
>
> + if (isnan (a))
> + return (a);
> +
> x = fabsl (a);
>
> if (x < 1.0L)
> diff --git a/mingw-w64-crt/math/lgammal.c b/mingw-w64-crt/math/lgammal.c
> index 1806750c4..998c6a90d 100644
> --- a/mingw-w64-crt/math/lgammal.c
> +++ b/mingw-w64-crt/math/lgammal.c
> @@ -225,7 +225,7 @@ long double __lgammal_r(long double x, int* sgngaml)
> *sgngaml = 1;
> #ifdef NANS
> if (isnanl(x))
> - return(NANL);
> + return x;
> #endif
> #ifdef INFINITIES
> if (!isfinitel(x))
> diff --git a/mingw-w64-crt/math/tgammal.c b/mingw-w64-crt/math/tgammal.c
> index 18d32441f..eb8994e07 100644
> --- a/mingw-w64-crt/math/tgammal.c
> +++ b/mingw-w64-crt/math/tgammal.c
> @@ -280,7 +280,7 @@ long double __tgammal_r(long double x, int* sgngaml)
> *sgngaml = 1;
> #ifdef NANS
> if (isnanl(x))
> - return (NANL);
> + return x;
> #endif
> #ifdef INFINITIES
> #ifdef NANS
> diff --git a/mingw-w64-crt/math/x86/acosh.def.h
> b/mingw-w64-crt/math/x86/acosh.def.h
> index 329799dca..3a7e07763 100644
> --- a/mingw-w64-crt/math/x86/acosh.def.h
> +++ b/mingw-w64-crt/math/x86/acosh.def.h
> @@ -50,7 +50,12 @@ __FLT_TYPE
> __FLT_ABI(acosh) (__FLT_TYPE x)
> {
>int x_class = fpclassify (x);
> - if (x_class == FP_NAN || x < __FLT_CST(1.0))
> + if (x_class == FP_NAN)
> +{
> + __FLT_RPT_DOMAIN ("acosh", x, 0.0, x);
> + return x;
> +}
> + else if (x < __FLT_CST(1.0))
> {
>__FLT_RPT_DOMAIN ("acosh", x, 0.0, __FLT_NAN);
>return __FLT_NAN;
> diff --git a/mingw-w64-crt/math/x86/log.def.h
> b/mingw-w64-crt/math/x86/log.def.h
> index 9428f90ce..a0d54b73d 100644
> --- a/mingw-w64-crt/math/x86/log.def.h
> +++ b/mingw-w64-crt/math/x86/log.def.h
> @@ -56,6 +56,8 @@ __FLT_ABI(log) (__FLT_TYPE x)
>__FLT_RPT_ERANGE ("log", x, 0.0, -__FLT_HUGE_VAL, 1);
>return -__FLT_HUGE_VAL;
> }
> + else if (x_class == FP_NAN)
> +return x;
>else if (signbit (x))
> {
>__FLT_RPT_DOMAIN ("log", x, 0.0, __FLT_NAN);
> @@ -63,7 +65,5 @@ __FLT_ABI(log) (__FLT_TYPE x)
> }
>else if (x_class == FP_INFINITE)
> return __FLT_HUGE_VAL;
> - else if (x_class == FP_NAN)
> -return __FLT_NAN;
>return (__FLT_TYPE) __logl_internal ((long double) x);
> }
> diff --git a/mingw-w64-crt/math/x86/pow.def.h
> b/mingw-w64-crt/math/x86/pow.def.h
> index 375b02b9d..0cf0739fe 100644
> --- a/mingw-w64-crt/math/x86/pow.def.h
> +++ b/mingw-w64-crt/math/x86/pow.def.h
> @@ -121,9 +121,13 @@ __FLT_ABI(pow) (__FLT_TYPE x, __FLT_TYPE y)
> ret
Re: [Mingw-w64-public] User experience with mingw-w64
Zach, I grabbed https://musl.cc/x86_64-w64-mingw32-native.zip. Just noticed that decimal-float is disabled. (I need --enable-decimal-float). Other than that, it's odd that libgcc_s_seh-1.dll is in the lib folder. Usually, it's in the bin folder as it's often required at runtime. I think libquadmath-0.dll has a runtime dependency on it - the attached 'demo.c' program certainly does. So I copied libgcc_s_seh-1.dll to the bin directory, but then the demo program crashes at runtime, throwing up an "Application Error" pop-up that complainins: "The application was unable to start correctly (0xc005)." IIRC, that usually means that there's an architecture incompatibility. Did I download the wrong compiler ? I'm on 64 bit Windows 7, building demo.exe in the cmd.exe shell. I built demo.exe by running: gcc -o demo.exe demo.c -lquadmath The build works fine - the only problem is the demo.exe runtime crash. Cheers, Rob On Mon, Jun 3, 2019 at 3:34 AM Zach van Rijn wrote: > On Thu, 2019-05-30 at 11:10 +1000, sisyphus wrote: > > Kudos to you, Zach, for providing those !! > > > > FYI: > > Unfortunately, the absence of quadmath is a blocker for me. > > Also, I've never used a compiler that has win32 threads. For > > me, it has always been posix threads. (However, that might not > > be an issue.) > > Quadmath support is now enabled in the MinGW toolchains, and > will be enabled for Linux toolchains during the next rebuild. > > * https://musl.cc/i686-w64-mingw32-cross.tgz > * https://musl.cc/i686-w64-mingw32-native.zip > * https://musl.cc/x86_64-w64-mingw32-cross.tgz > * https://musl.cc/x86_64-w64-mingw32-native.zip > > Other relevant changes: > > * Rebuilt against latest musl (commit ac3042, 2019-05-22) > * Rebuilt against latest MinGW-w64 (commit d8f914, 2019-06-02) > * Binutils bumped from 2.30 to 2.32 (see [1] below) > > I'm having difficulties getting it to build correctly with POSIX > threading, so once I resolve/test that I'll share an update. > > Please let me know if the above works for you. > > > ZV > > > [1] https://www.sourceware.org/ml/binutils/2019-06/msg3.html ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] User experience with mingw-w64
Kudos to you, Zach, for providing those !! FYI: Unfortunately, the absence of quadmath is a blocker for me. Also, I've never used a compiler that has win32 threads. For me, it has always been posix threads. (However, that might not be an issue.) Cheers, Rob On Thu, May 30, 2019 at 7:39 AM Zach van Rijn wrote: > On Wed, 2019-05-29 at 16:59 -0400, Edward Diener wrote: > > ... > > OK, thanks ! I can see that the MingW-W64-builds on the mingw- > > w64 Downloads page is probably at an end and I must choose > > another way to get the latest gcc on Windows distributions, so > > I will try MSYS2. I always thought that mingw-w64-install.exe > > and the MingW-W64-builds were just so convenient, so I am > > sorry they will not continue being so. It was probably too > > much work for the developer(s) who supported that > > methodology. > > This topic (the downloads page) was raised in IRC yesterday. > > I am preparing to maintain a set of packages for various > distributions (and direct download) containing up-to-date Linux > and Windows toolchains (specifically cross-compilers). Version: > > GCC : 9.1.0 > binutils : 2.32 > MinGW-w64 : git- > d793e0 (2019-05-17) > > For example, if you're on 32- or 64- bit Windows and wish to > compile for the same architecture, use one of these: > > * https://musl.cc/i686-w64-mingw32-native.zip > > * https://musl.cc/x86_64-w64-mingw32-native.zip > > Despite the name (they're part of a larger project) they're just > MinGW-w64 toolchains that run on Windows and target Windows. > > And for anyone looking to do Linux development on Windows, these > are also available: https://win.musl.cc/ > > ZV > > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libc bugs in strtof/strtod/strtold?
Hi, I'm aware of problems with strtold's capacity to parse hex strings. See: https://sourceforge.net/p/mingw-w64/bugs/725/ That report provides a demo script and also mentions the workaround (of using __mingw_strtold instead). I *think* it's still unfixed, but I'm unaware of it affecting anything other than strtold. Cheers, Rob On Thu, May 30, 2019 at 4:40 AM EML wrote: > I've just installed MSYS2 and built a C++ project which has been running > for the last 13+ years, on various Linux, Cygwin, and (old) mingw > platforms. Some of the regressions are failing on mingw-w64/x86_64, > which I haven't tried before, and the errors I'm getting are exactly the > same as errors I got when running on Centos 4.4 in 2007. These errors > all disappeared over the next few years as the platforms moved to newer > libc versions. > > I don't have a record of any old test cases, but I do have a commit > message which says: > > > > The 3 failures are caused by a bug in the libc strtof, strtod, and > > strtold routines on my system, which currently have a problem when > > scanning > > hex floats with negative exponents. > > Question - is mingw-w64 actually using an old libc version? It's going > to take me hours to find the old test cases, or write new ones, so I > thought I'd just do a sanity check here first. Thanks. > > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] User experience with mingw-w64
I, too, get the impression that providing up-to-date releases is not of much interest to the developers. IMO that would be a pity and a pathetically weak business model. I recently used msys2's pacman to grab gcc-8.2.1, hoping to use it in a native win32 situation. It seems to have a dependency on libgmp-10.dll (for some tasks, at least) - which can complicate matters when one is wanting to build one's own gmp library. Luckily, I'm always building *static* gmp libraries so it was just a matter of getting rid of msys2's gmp headers and libraries. When building shared gmp libs, one would need to give some thought as to how the PATH is arranged. There was another (unsolved) glitch that made it unsatisfactory for my purposes but it's probably generally ok. I've discarded it in favour of the 8.1.0 compilers as I've got better things to do than investigate mysterious glitches. The Strawberry Perl project provides 8.3.0 native win32 compilers (which I've just started using): For 32 bit: Thread model: posix gcc version 8.3.0 (i686-posix-dwarf, Built by strawberryperl.com project) For 64 bit: Thread model: posix gcc version 8.3.0 (x86_64-posix-seh, Built by strawberryperl.com project) They probably also provide the scripts they use to build those compilers ... not sure. Anyway, the compilers seem fine, and you can download them at: http://strawberryperl.com/package/kmx/32_gcctoolchain/mingw64-w32-gcc8.3.0_20190316.zip and http://strawberryperl.com/package/kmx/64_gcctoolchain/mingw64-w64-gcc8.3.0_20190316.zip I don't know of anywhere that provides gcc-9.1 for windows. Anyone ?? Cheers, Rob On Wed, May 29, 2019 at 2:52 AM Edward Diener < eldlistmaili...@tropicsoft.com> wrote: > There has not been an update to MingW-W64-builds for over a year while > gcc 6.5, 7.4, 8.2, 8.3, and 9.1 have been released. The mingw-w64 > downloads page at https://mingw-w64.org/doku.php/download looks wildly > out of date as far as latest releases are concerned. > > Does nobody care ? > > I realize I am just an end-user and not a mingw-w64 developer, but does > no one of the latter actually care about these things, or has mingw-w64 > just become a platform for mingw-w64 developers where end-users are no > longer very important ? > > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] snprintf() is broken in mingw-w64
Hi,
Alternatively, you can compile the program with -D__USE_MINGW_ANSI_STDIO :
C:\_32\C>type try.c
/* try.c */
#include
int main() {
char buf[5] = "";
int ret = snprintf(buf, 3, "%d", 123456789);
printf("buf=%s ret=%d\n", buf, ret);
return 0;
}
C:\_32\C>gcc -o try.exe try.c -D__USE_MINGW_ANSI_STDIO
C:\_32\C>try
buf=12 ret=9
C:\_32\C>
On Fri, May 10, 2019 at 11:09 PM Pali Rohár wrote:
> Hello!
>
> snprintf() function in mingw-w64 is broken. Seems that it just calls
> MSVC's _snprintf() function which is not same as snprintf(). MSVC until
> ucrt does not provide snprintf() at all, just _snprintf().
>
> Differences are that MSVC's _snrpintf() does not ensure that filled
> buffer would be null-termed and when overflow occurs it returns -1
> instead of length which is needed to fully format string.
>
> See following example:
>
> #include
>
> int main() {
> char buf[5] = "";
> int ret = snprintf(buf, 3, "%d", 123456789);
> printf("buf=%s ret=%d\n", buf, ret);
> return 0;
> }
>
> It prints:
>
> buf=123X ret=-1
>
> So for MSVC's _snprintf() it is needed to write wrapper, e.g. following:
>
> #define snprintf(str, size, format, ...) ( (((size_t)(size) > 0) ?
> (_snprintf((str), (size), (format), __VA_ARGS__), ((char
> *)str)[(size_t)(size)-1] = 0, 0) : 0), _scprintf((format), __VA_ARGS__) )
>
> It is simple inline-able macro so it does not increase executable code
> size too much.
>
> MSVC's _scprintf() function returns length of formatted string, so
> exactly what snprintf() return value should be.
>
> With that snprintf() define, output of above example is:
>
> buf=12 ret=9
>
> Which is correct now.
>
> Would you consider fixing snprintf() in mingw-w64?
>
> Similarly also vsnprintf() can be fixed:
>
> #define vsnprintf(str, size, format, ap) ( (((size_t)(size) > 0) ?
> (_vsnprintf((str), (size), (format), (ap)), ((char *)str)[(size_t)(size)-1]
> = 0, 0) : 0), _vscprintf((format), (ap)) )
>
> --
> Pali Rohár
> pali.ro...@gmail.com
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] set default sysroot
Hi, I don't know if you can reset the default without recompiling gcc - I suspect you can't, but others might know better. Closest I can get to satisfying your spec is to create a batch file called "gcc.bat" that contains the following 2 lines: @echo off C:/_64/gcc-mingw-810/mingw64/bin/gcc.exe --sysroot=C:/_64/gcc-mingw-810/mingw64 %* Then place that file so that it is found in the path *before* gcc.exe. When I do that, I get: C:\_64>gcc --print-sysroot C:/_64/gcc-mingw-810/mingw64 If I remove that "gcc.bat" file, I get (like you): C:\_64>gcc --print-sysroot C:/mingw810/x86_64-810-posix-seh-rt_v6-rev0/mingw64 HTH. Cheers, Rob On Sun, Dec 16, 2018 at 4:40 AM Maarten Verhage wrote: > Hi all, > > This might be a naive question. I have Windows 7. I downloaded MinGW-W64 > GCC-8.1.0 x86_64-posix-seh. And extracted in to my harddisk. I added the > bin > folder to my PATH. > > now when I do: gcc --print-sysroot > I'm getting: > C:/mingw810/x86_64-8.1.0-posix-seh-rt-_v6-rev0/mingw64 > > This is not the path I installed mingw and gcc into. > > How would I be able to set the *default* sysroot path on my system? > > I prefer not to msys(2) tools if possible. > > Thanks, best regards, > Maarten Verhage > > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] i686 gcc version 8.2?
Hi, All of those https://musl.cc links are currently unreachable for me (with both Internet Explorer and Firefox). I'll try again later today. IMO, it's a great pity that the Win32/Personal Builds/mingw-builds directory is not updated more regularly. Where does one locate the instructions on how to build these compilers from source ? Cheers, Rob On Wed, Dec 12, 2018 at 2:13 AM Zach van Rijn wrote: > On Tue, 2018-12-11 at 13:05 +, RK via Mingw-w64-public > wrote: > > Hi, > > Is it possible to access compiled versions of the i686 gcc > > version 8.2 toolchain? I can see version 7.4 via pacman and > > version 8.1 under the Toolchains targeting Win32/Personal > > Builds/mingw-builds directory. > > I would rather not build my own i686 toolchain. > > There are a few available at https://musl.cc/ -- > > GCC_VER = 8.2.0 > BINUTILS_VER = 2.31.1 > MUSL_VER = git-39ef612aa193cc6e954ac5a01574300ccd4b7ef9 > GMP_VER = 6.1.2 > MPC_VER = 1.1.0 > MPFR_VER = 4.0.1 > MINGW_VER= v6.0.0 > > > https://musl.cc/i686-w64-mingw32-cross.tgz > https://musl.cc/i686-w64-mingw32-native.tgz > https://musl.cc/x86_64-w64-mingw32-cross.tgz > https://musl.cc/x86_64-w64-mingw32-native.tgz > > The '-cross' ones are intended to be run on x86_64 Linux, and > are fully static (no dependencies), and produce Win32 code. > > The '-native' ones can run on Windows (i686 and x86_64 > respectively) but require one small extra step once they're > extracted: see Footnote #7 at https://musl.cc/#refs (To use > native MinGW32 toolchains, append ;E:\x86_64-w64-mingw32- > native\x86_64-w64-mingw32-native\bin (or similar) to %PATH%, > then copy ./include to ./TRIPLE/include) > > On my to-do list is to port all of the current Linux-targeted > toolchains to run on a Win32 host. But this takes time. > > > > Thanks!RK > > ZV > > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] -ffloat-store not needed with 64-bit compiler
- Original Message - From: "Lajos Foldy" To: Sent: Wednesday, September 12, 2012 12:29 AM Subject: Re: [Mingw-w64-public] -ffloat-store not needed with 64-bit compiler > On Tue, Sep 11, 2012 at 3:01 PM, Sisyphus > wrote: >> >> Is there a way to get the same output with the 64-bit mingw compiler ? > > i686 uses the x87 FPU (80 bit internal precision), x86_64 uses SSE2 > (64 bit precision). -ffloat-store enforces 64 bit precision through > memory stores/loads. You can use the -mfpmath=... option to > enable/disable x87 or SSE2. Thanks Lajos - things start to fall into place. I gather, however (and probably incorrectly), that if I build demo.exe with: gcc -o demo.exe -mfpmath=387 demo.c then demo.exe should ouptut the same result, irrespective if whether I used the 32-bit gcc or the 64-bit gcc. With 32-bit gcc: # C:\_32\C>gcc -o demo.exe -mfpmath=387 demo.c C:\_32\C>demo 1..1 # a = [ 0 1 2 2 4 5 5 6 8 9 10 ] # b = [ 0 1 2 2 4 4 5 6 8 8 9 ] # a - b = [ 0 0 0 0 0 1 0 0 0 1 1 ] not ok 1 - lists are equal C:\_32\C> # With 64-bit gcc: # C:\_32\C>gcc -o demo.exe -mfpmath=387 demo.c C:\_32\C>demo 1..1 # a = [ 0 1 2 2 4 5 5 6 8 9 10 ] # b = [ 0 1 2 2 4 5 5 6 8 9 10 ] # a - b = [ 0 0 0 0 0 0 0 0 0 0 0 ] ok 1 - lists are equal C:\_32\C> # Cheers, Rob -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] -ffloat-store not needed with 64-bit compiler
- Original Message - From: "Ruben Van Boxem" > I feel compelled to say that if you are subtracting floats to check for > equality, you should be smacked in the face. No, I'm not doing that :-) But I should have provided a brief description of what it *is* demonstrating. It demonstrates that convert(divide1(a, b)) and divide2(a, b) yield different results even though they do the same thing. (Of course, under the hood, they're doing different things - unless the -ffloat-store option is supplied, whereupon the 2 methods *do* provide identical results) Note that convert(), divide1() and divide2() are 3 simple functions defined in demo.c (which was attached to my original post). But with the 64-bit compiler, convert(divide1(a, b)) and divide2(a, b) *always* produce *identical* results. I'm wondering what accounts for this difference between the 32-bit and 64-bit compilers (answer provided in this thread by Lajos), and if/how I can force the 64-bit compiler to produce the same anomaly that the 32-bit compiler can produce. I have no practical need that calls for the 64-bit compiler to produce the anomaly ... I'm just curious to know if it can be done. Cheers, Rob -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] -ffloat-store not needed with 64-bit compiler
- Original Message - From: "Kai Tietz" To: Sent: Monday, September 10, 2012 10:15 PM Subject: Re: [Mingw-w64-public] -ffloat-store not needed with 64-bit compiler > 2012/9/8 Sisyphus : >> Hi, >> >> Attached is a small demo program (demo.c). >> >> With 32-bit mingw compilers (both mingw.org's 4.5.2 and mingw64's 4.6.3) >> the >> output of that program differs, depending upon whether I build it with >> -ffloat-store or not. >> I've no problem with that - I think I understand what's going on. >> To get the output I desire I build *with* -ffloat-store. >> >> When I switch to 64-bit mingw64 compilers (I've tried both 4.6.3 and >> 4.7.0) >> I get the desired output *without* having to invoke -ffloat-store. >> And if I do invoke -ffloat-store, I still get the same output. >> >> Why the different behaviour with the 64-bit compilers ? > > This is caused by x64 ABI and used optimization. I tested your demo > by x64 compiler with option -O2 and I noticed a code difference with > option -ffloat-store -O2 vs -fno-float-store -O2 (default). Did the output of the program change ? With 32-bit mingw, when I run gcc -o demo.exe demo.c the output I get is: 1..1 # a = [ 0 1 2 2 4 5 5 6 8 9 10 ] # b = [ 0 1 2 2 4 4 5 6 8 8 9 ] # a - b = [ 0 0 0 0 0 1 0 0 0 1 1 ] not ok 1 - lists are equal Is there a way to get the same output with the 64-bit mingw compiler ? (I admit, this is a different question to the one that I originally asked.) With my 64-bit compilers, I've (now) tried different optimisations with both -fno-float-store and -ffloat-store, but I always seem to get output of: 1..1 # a = [ 0 1 2 2 4 5 5 6 8 9 10 ] # b = [ 0 1 2 2 4 5 5 6 8 9 10 ] # a - b = [ 0 0 0 0 0 0 0 0 0 0 0 ] ok 1 - lists are equal >> And a second question: >> Is -fno-float-store a valid option ? > Yes, it is. Ok - thanks. > It is a valid option and documented by gcc's documentation. See for > more details either invoke.texi or 'gcc info'. How does one invoke either of these in mingw ? (Or msys.) For reference, the documentation that I looked at was http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/Option-Summary.html#Option-Summary http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Option-Summary.html#Option-Summary http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Option-Summary.html#Option-Summary Thanks Kai. I appreciate that you take the time to answer my dumb questions. Cheers, Rob -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] -ffloat-store not needed with 64-bit compiler
Hi,
Attached is a small demo program (demo.c).
With 32-bit mingw compilers (both mingw.org's 4.5.2 and mingw64's 4.6.3) the
output of that program differs, depending upon whether I build it
with -ffloat-store or not.
I've no problem with that - I think I understand what's going on.
To get the output I desire I build *with* -ffloat-store.
When I switch to 64-bit mingw64 compilers (I've tried both 4.6.3 and 4.7.0)
I get the desired output *without* having to invoke -ffloat-store.
And if I do invoke -ffloat-store, I still get the same output.
Why the different behaviour with the 64-bit compilers ?
And a second question:
Is -fno-float-store a valid option ?
I can find no documentation for it - yet using it on the command line does
not produce the "unrecognized command line option" error that I would expect
from an invalid option.
Cheers,
Rob
#include
#define N 11
double x[N] = { 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0 };
inta[N], b[N], diff[N];
char *success_message = "ok 1 - lists are equal";
char *failure_message = "not ok 1 - lists are equal";
static void
print( int *v, char *title )
{
int i;
printf( "%s = [", title );
for( i = 0; i < N; i++ ) printf( "%2d ", v[i] );
printf( "] \n" );
}
static int
ok( int *v )
{
int i;
for( i = 0; i < N; i++ ) if( v[i] ) return 0;
return 1;
}
double divide1( double a, double b ) { return a/b; }
intdivide2( double a, double b ) { return a/b; }
intconvert( double a ) { return a; }
int
main( int argc, char **argv )
{
int i;
char *msg;
printf( "1..1\n" );
for( i = 0; i < N; i++ ) a[i] = convert( divide1( x[i], .1 ) );
for( i = 0; i < N; i++ ) b[i] = divide2( x[i], .1 );
for( i = 0; i < N; i++ ) diff[i] = a[i] - b[i];
print( a,"# a" );
print( b,"# b" );
print( diff, "# a - b" );
msg = ok( diff ) ? success_message : failure_message;
printf( "%s\n", msg );
return 0;
}
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] _Decimal64 nan
Thanks JonY, http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=8cf166fedd1aa110VgnVCM10a360ea10RCRD is a handy reference. Naturally, the "%De" (and friends) format doesn't work, as the MSC runtime doesn't accomodate it. (It seems there's quite a few places where those formats are not supported.) To do it properly, I guess I'd have to roll my own 'printf' formulation of the _Decimal64 type. I've taken a quick look at how the mpfr library goes about it, and it looks rather complex. Cheers, Rob -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] _Decimal64 nan
Hi,
I'm using a mingw64 port of gcc-4.7.0 on Windows Vista64:
#
C:\_32\C>x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=c:/_64/alt/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with:
../../../build/gcc/src/configure --target=x86_64-w64-mingw32
--prefix=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root
--with-sysroot=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root
--enable-languages=all,obj-c++
--enable-fully-dynamic-string --disable-multilib
Thread model: win32
gcc version 4.7.0 20110410 (experimental) (GCC)
I'm just starting to play with the _Decimal64 type.
First thing I'm wondering is how we reliably print out the _Decimal64 values
in our programs. Is there a formatter we can use with printf() ?
For the moment, I've simply been casting the _Decimal64 variable to a double
and formatting with %f:
printf("%f\n", (double)decimal64);
That's good enough to show me that I'm getting sane values - though I think
I ought to find out how to do it correctly.
I did, however, come across something that appears to me to be *not* so
sane:
#include
#include
int main(void) {
_Decimal64 inf_d64, nan_d64;
double inf_d, nan_d;
inf_d64 = 1.0DD/0.0DD;
inf_d = 1.0/0.0;
nan_d64 = inf_d64/inf_d64;
nan_d = inf_d/inf_d;
printf("%f %f\n", (double)nan_d64, nan_d);
nan_d64 = -nan_d64;
nan_d = -nan_d;
printf("%f %f\n", (double)nan_d64, nan_d);
return 0;
}
/**
Outputs:
1.#QNAN0 -1.#IND00
-1.#IND00 1.#QNAN0
Expected:
-1.#IND00 -1.#IND00
1.#QNAN0 1.#QNAN0
***/
Whereas the "positive" nan is usually represented as -1.#IND00 and the
"negative" nan as 1.#QNAN0, the _Decimal64 nans are (it seems) being
represented the other way about.
Is this just a consequence of my improper way of printing those _Decimal64
values ?
What ought we see when we print a _Decimal64 nan on Windows?
Cheers,
Rob
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] dll files in mingw/lib andx86_64-w64-mingw32\lib
- Original Message - From: "Kai Tietz" To: Sent: Tuesday, June 26, 2012 11:03 PM Subject: Re: [Mingw-w64-public] dll files in mingw/lib andx86_64-w64-mingw32\lib > Hello Rob, > > 2012/6/26 Sisyphus : >> Hi, >> >> When we unzip the mingw-w64-bin_i686-mingw_MMDD.zip cross-compilers >> we >> find a number of dll files (including libgcc_s_sjlj-1.dll and >> libstdc++-6.dll) in mingw/lib and x86_64-w64-mingw32/lib, but not in the >> 'bin' folder. >> >> Are we supposed to : >> a) copy those dll's to the 'bin' folder ? >> or >> b) add one/both of those lib folders to the path ? > > For cross-compiler they are placed in target's bin folder (mingw > folder is normally just a symbolic link to the target-triplet-folder). > For native toolchains the .dll files are copied into bin folder, > which is for none-multilib setup ok. > To copy for cross-compiler into corresponding lib-folder instead of > bin-folder is caused by multilib-setup. As here .dll files need > different location for not overwriting each other. > > Variant b) is the proper one. > >> Why are they not already in the 'bin' folder ? > > See description about multilib-scenario and dll-file-name collision. > >> Cheers, >> Rob > > Regards, > Kai Thanks for explaining, Kai. Cheers, Rob -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] dll files in mingw/lib and x86_64-w64-mingw32\lib
Hi, When we unzip the mingw-w64-bin_i686-mingw_MMDD.zip cross-compilers we find a number of dll files (including libgcc_s_sjlj-1.dll and libstdc++-6.dll) in mingw/lib and x86_64-w64-mingw32/lib, but not in the 'bin' folder. Are we supposed to : a) copy those dll's to the 'bin' folder ? or b) add one/both of those lib folders to the path ? Why are they not already in the 'bin' folder ? Cheers, Rob -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Switching versions of libgcc_s_sjlj-1.dll
- Original Message - From: "Mark Dootson" To: Sent: Tuesday, March 20, 2012 6:28 PM Subject: Re: [Mingw-w64-public] Switching versions of libgcc_s_sjlj-1.dll > Hi Rob, me again :-) > > On 20/03/2012 02:04, Sisyphus wrote: > >> Better if someone knows of a way to have Strawberry Perl stick to loading >> the correct (4.4.7) libgcc_s_sjlj-1.dll, but still allow these perl dll >> files to load the 4.7.0 libgcc_s_sjlj-1.dll . > > I think this is possible with manifests. I've certainly used manifests > in the past at the application level to point executables at a specific > libgcc_s_sjlj-1.dll so I can have 64 bit and 32 bit executables in the > same path keeping the dependent dll's ( libgcc_s_sjlj-1.dll etc ) in sub > folders. (and for any other reason I don't want multiple > libgcc_s_sjlj-1.dll etc versions on the path). > > I think it is meant to work for assemblies (dll's) too. I'll check it out. I've asked about this on perlmonks, too (where it's really quite OT): http://www.perlmonks.org/index.pl?node_id=960506 In response to that post BrowserUk also raised the possibility of using manifests ... which only served to send me scurrying for the nearest sandpile into which I could bury my head ;-) Having posted there, it then occurred to me that I could frame the question in such a way that it wasn't OT here ... which is what I then proceeded to do. (I don't usually go posting willy-nilly all over the place.) If it *can* be done using manifests, then I think that's *the* solution to use. (I do have a 64-bit version of mt.exe, if that's any use. So far, all I've really ascertained is that none of these dll files have a resource section. As regards manifest files themselves, I still haven't really got past the "Huh ?" stage.) Cheers, Rob -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Switching versions of libgcc_s_sjlj-1.dll
- Original Message - From: "kmx" >>> Better if someone knows of a way to have Strawberry Perl stick to >>> loading >>> the correct (4.4.7) libgcc_s_sjlj-1.dll, but still allow these perl dll >>> files to load the 4.7.0 libgcc_s_sjlj-1.dll . >>> >> Yes, this issue is caused by the fact that libgcc isn't versioned in >> name (as other DLLs are). So by system-caching of DLLs with same >> names causes this side-effect. >> >> > > Will the situation be better with gcc 4.6.3 (which is likely to be used > with next strawberry perl version) - I mean would gcc-4.6.3's > libgcc_s_sjlj-1.dll work together with rob's binaries built with gcc-4.7.0 > ? If it's relevant, the missing procedure entry point is __addtf3. (I guess that's just the first one that was found, and that there could be others.) It's interesting that there would be no problem at all with my binaries on Strawberry Perl if only 4.4.7 and 4.7.0 had different names for the dll. (What a difference a name makes. ;-) (And thanks to Kai for the reply - I find it encouraging that the hack of switching dll's might not be the sleeping death-trap I feared.) kmx (or anyone else), if it's ok to send me a 4.6.3 libgcc_s_sjlj-1.dll, I'll stick it in strawberry/perl/bin and see how it behaves. Cheers, Rob -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Switching versions of libgcc_s_sjlj-1.dll
Hi, I have a C app (Strawberry Perl) built using the 64-bit gcc-4.4.7 compiler. Whenever that perl starts up it loads libgcc_s_sjlj-1.dll. If I were to replace that 4.4.7 version of libgcc_s_sjlj-1.dll that it loads with a 4.7.0 version of libgcc_s_sjlj-1.dll, would that be something that: a) only an idiot or a moron would even contemplate doing; b) will probably cause problems at some stage; c) you might just get away with; d) won't cause any problems at all because 4.7.0 is later than 4.4.7. By way of brief explanation: I have some x64 perl binaries, and their perl dll's need to load the 4.7.0 libgcc_s_sjlj-1.dll - but they always use the 4.4.7 libgcc_s_sjlj-1.dll (because it has already been loaded by Strawberry perl itself). This results in an unfound entry point error. Having Strawberry perl instead load the 4.7.0 libgcc_s_sjlj-1.dll seems to work ... but at what risk, I wonder. I keep thinking that, even though it works ok for the things I've been doing, there's probably something nasty just waiting to bite. Better if someone knows of a way to have Strawberry Perl stick to loading the correct (4.4.7) libgcc_s_sjlj-1.dll, but still allow these perl dll files to load the 4.7.0 libgcc_s_sjlj-1.dll . Cheers, Rob -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] printf issues...
- Original Message - From: "David Cleaver" >>> He has informed me that he is not in a cygwin environment. However, I >>> forgot to >>> ask what OS he was using. He *is* watching - but a bit pressed for time. The OS is Windows Vista64 - so I expect we're seeing a difference in msvc runtimes, as suggested elsewhere in this thread. (Dammit ... I keep on forgetting about this !!) Cheers, Rob -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Mingw-users] GMP windows64 porting effort
- Original Message - From: "Ruben Van Boxem" Hi Ruben, > Please note that far from all tests run when you run make check. I > tried reporting it to the gmp-bugs list, but I was a bit too > unfriendly to their liking. Be sure to go to all the mpz/mpn/... > subdirectories and run make check, you'll find that some tests aren't > run from a top-level make check. This needs o be fixed as well, > because most (if not all) passed when I last tried that. Couldn't reproduce that problem. I went through each of the tests subdirectories running 'make check' as I went. In all cases the number of tests run was the same as when I first ran 'make check'. Here's my tally: cxx: 18 tests misc: 3 tests mpf: 27 tests mpn: 31 tests mpq: 11 tests mpz: 58 tests rand: 7 tests I wonder what's making it different for you. Here's some details from my (ageing) setup: ## Rob@DESKTOP2 /c/_64/comp/gmp-5.0.90-20110706 $ make -v GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i686-pc-msys Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to . Rob@DESKTOP2 /c/_64/comp/gmp-5.0.90-20110706 $ uname -a MINGW32_NT-6.0 DESKTOP2 1.0.11(0.46/3/2) 2007-07-29 17:16 i686 unknown ## Cheers, Rob -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Mingw-users] GMP windows64 porting effort
- Original Message - From: "Torbjorn Granlund" > Oops, one patch had been omitted (although the change log claimed it was > there). You should have more luck with this snapshot: > > ftp://gmplib.org/pub/snapshot/gmp-5.0.90-20110706.tar.bz2 > Yes, that's better - all tests pass. Here's a copy'n'paste of the configure commands I ran. For the 32-bit build (gcc-3.4.5): $ ./configure && make && make check For the 64-bit build (gcc-4.7.0): $ ./configure CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ AR=x86_64-w 64-mingw32-ar LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm RANLIB=x86_64- w64-mingw32-ranlib OBJDUMP=x86_64-w64-mingw32-objdump STRIP=x86_64-w64-mingw32 -strip && make && make check > I need help with: > > * Making sure the new snapshot works for the various mingw and cygwin > 32-bit and 64-bit installs. Does asm get properly included for 32-bit > builds, and properly *excluded* for 64-bit builds? Yep - I get some asm files for the 32-bit build, but not the 64-bit build. (Haven't tried Cygwin - just concentrating on mingw/msys.) > Is the exact CPU > used for the host (i.e., not generic things like i386, i686, x86_64)? Not sure. Is there something in the config.log that will answer that question ? In both the 32-bit and 64-bit config.log files I see: configure:3233: checking host system type configure:3246: result: k8-pc-mingw32 > * Understanding why --enable-cxx fails. It is related to the absense of > iostream as a shared libtrary. But what can be done about that? So I then did 'make distclean' and rebuilt, adding --enable-cxx to the above configure commands. All goes well for the 32-bit build. All tests pass (including the 18 cxx tests). For the 64-bit build, we strike a familiar looking problem with the building of tests/cxx/t-locale.exe: c:/_64/alt/bin/../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(digcs01031.o):(.text+0x0): multiple definition of `localeconv' clocale.o:clocale.c:(.text+0x0): first defined here collect2: ld returned 1 exit status If I then run 'make check -i' it culminates with: ## PASS: t-assign.exe PASS: t-binary.exe PASS: t-cast.exe PASS: t-constr.exe PASS: t-headers.exe PASS: t-iostream.exe PASS: t-istream.exe /bin/sh: ./t-locale.exe: No such file or directory FAIL: t-locale.exe PASS: t-misc.exe PASS: t-mix.exe PASS: t-ops.exe PASS: t-ops2.exe PASS: t-ops3.exe PASS: t-ostream.exe PASS: t-prec.exe PASS: t-rand.exe PASS: t-ternary.exe PASS: t-unary.exe == 1 of 18 tests failed Please report to gmp-b...@gmplib.org, see http://gmplib.org/manual/Reporting-Bugs.html == ## Apart from that 'locale' problem re-surfacing, all looks fine to me wrt '--enable-cxx'. Cheers, Rob -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Mingw-users] GMP windows64 porting effort
- Original Message - From: "Torbjorn Granlund" Dropping mingw-users from the CC's. > I have tested this on an Intel Nehalem, running windoze 7 with cygwin and > the mingw compilers. It would be great if people could test > > configure && make && make check During make check: libtool: link: x86_64-w64-mingw32-gcc -O2 -pedantic -m64 -std=gnu99 -mtune=k8 -march=k8 -o t-locale.exe t-locale.o ../../tests/.libs/libtests.a /c/_64/comp/gmp-5.0.90-20110704/.libs/libgmp.a ../../.libs/libgmp.a c:/_64/alt/bin/../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(digcs01031.o):(.text+0x0): multiple definition of `localeconv' t-locale.o:t-locale.c:(.text+0x0): first defined here collect2: ld returned 1 exit status make[4]: *** [t-locale.exe] Error 1 make[4]: Leaving directory `/c/_64/comp/gmp-5.0.90-20110704/tests/misc' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/c/_64/comp/gmp-5.0.90-20110704/tests/misc' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/c/_64/comp/gmp-5.0.90-20110704/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/c/_64/comp/gmp-5.0.90-20110704' make: *** [check] Error 2 # That's the same error as I get with gmp-5.0.2. > You should get assembly code for any 32-bit build, but no assembly code > for any 64-bit build. Checking if assembly code was inclded is most > easily done with an "ls -l mpn/*.asm" after configure. With assembly, > you should see dozens of files, else you should see nothing. No asm files to be found. I'm on Vista64 and I use a 64-bit compiler that was built by the mingw64 team as one of the "automated builds". It's executables (gcc, g++, ar, nm, etc.) are all prefixed with "x86_64-w64-mingw32-". Therefore, my configure command becomes: $ ./configure CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ AR=x86_64-w64-mingw32-ar LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm RANLIB=x86_64-w64-mingw32-ranlib OBJDUMP=x86_64-w64-mingw32-objdump STRIP=x86_64-w64-mingw32-strip (That's the same as the 'configure' command I've been running on recent gmp releases, where all has worked fine ... apart from the "locale" issue, which I've simply ignored.) Here's my "gcc -v": # $ x86_64-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=c:\_64\alt\bin\x86_64-w64-mingw32-gcc.exe COLLECT_LTO_WRAPPER=c:/_64/alt/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../build/gcc/src/configure --target=x86_64-w64-mingw32 --prefix=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root --with-sysroot=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root --enable-languages=all,obj-c++ --enable-fully-dynamic-string --disable-multilib Thread model: win32 gcc version 4.7.0 20110410 (experimental) (GCC) # BTW, I'm delighted that you are working on providing some assembler routines for the Win64 build of gmp. Thank you for doing that. Cheers, Rob -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] __uint128 puzzles
Hi,
I have a mingw64 4.6.0 cross-compiler (20100414) which I'm in the process of
phasing out, as it doesn't comply with MSVC standards regarding the
decoration of library symbols.
With that compiler, I inserted into both mingw/include/_mingw.h and
x86_64-w64-mingw32/include/_mingw.h the following line of code:
typedef unsigned int __uint128 __attribute__ ((__mode__ (TI)));
Having done that, the following simple program then compiles and runs fine
(reporting '16 16'):
###
#include
int main(void) {
printf("%d %d\n", sizeof(__int128), sizeof(__uint128));
}
###
Upon upgrading to my new 20110410 (4.7.0) compiler I again made the same
amendment to both of those _mingw.h files. But, this time, it's not working
for me ... on attempting to compile the above program I'm getting:
C:\_64\c>x86_64-w64-mingw32-gcc -o try.exe try.c
try.c: In function 'main':
try.c:5:48: error: '__uint128' undeclared (first use in this function)
try.c:5:48: note: each undeclared identifier is reported only once for each
function it appears in
What accounts for the difference ?
Cheers,
Rob
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [mpir-devel] Re: MinGW64 -undefinedreference to gmpn symbols.
- Original Message -
From: "Sisyphus"
> Apart from 'gcc -v' or 'gcc --version' there's apparently nothing - and I
> have at least one mingw64 64-bit compiler that doesn't report the date
> even
> then.
But on the mingw64 mailing list (where I asked about this, in the thread
"Compiler incompatibilities") Ozkan presented this possible alternative:
###quote###
In that case, if mpir is using autotools a configury check
can be done. I have the following in one of my projects
which can be adapted to their needs I guess:
dnl === Check for underscore on external symbols =
AC_MSG_CHECKING(whether external symbols need an underscore prefix)
AC_TRY_LINK(
[asm(".long _bar");
int bar;],
[],
AC_DEFINE(HAVE_SYM_PREFIX_UNDERSCORE, 1, [Define this if C symbols
are prefixed with an underscore]) AC_MSG_RESULT(yes),
AC_MSG_RESULT(no)
)
###end quote###
Thanks again, Ozkan.
Cheers,
Rob
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiler incompatibilities
- Original Message - From: "Ruben Van Boxem" >> Is there a simple way for a program to determine the date that the > compiler >> was built ? >> (A #define that tells us would be ideal, if such exists.) > > I hope you're not planning on using the old compilers with wrong > underscore > prefixing rules? Please don't; it will cause a lot of trouble for people > trying to use libraries distributed by you. An ifdef for that would be > one > of the worst hacks possible :-( No - that wasn't the plan. The mpir library won't build with the old compilers (as MSVC-compliance relating to the underscores is expected, and non-compliance not catered for.) The thought was that if the mpir build process could easily and reliably detect that the compiler was too old, the build could be aborted with a message along the lines of "this compiler is too old, and is incapable of building mpir - you need a compiler that was built after 28/04/2010". I was just making the enquiry on their behalf. Cheers, Rob -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [mpir-devel] Re: MinGW64 - undefinedreference to gmpn symbols.
- Original Message - From: "Jason" >> > That's the secret then - just use a compiler later than 20100428. (If >> > only I'd waited another fortnight before I downloaded that compiler :-) >> > > Our configure system can reject bad compilers , but for the test to work > our > assembler yasm would have to be built before it was configured , so the > easiest way would be to test for the define __MINGW64__ and test on a > define > on the date when the compiler was built , if there is one , if not then I > wont > bother Apart from 'gcc -v' or 'gcc --version' there's apparently nothing - and I have at least one mingw64 64-bit compiler that doesn't report the date even then. As time goes by there should be fewer and fewer pre-20100428 compilers kicking about anyway. Cheers, Rob -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiler incompatibilities
- Original Message - From: "Ozkan Sezer" > Win64-targeting builds from mingw-w64 up to 2010-04-27 didn't > follow MSVC x64 convention and did *not* prepend an undersocore > to the symbols: this is why you are seeing the incompatibilities > with the newer toolchains. > > All win64-targeting toolchains created after 2010-04-28, including > the sezero's gcc-4.4-based personal builds follow the MS convention. Just a quick follow-up question on that. Is there a simple way for a program to determine the date that the compiler was built ? (A #define that tells us would be ideal, if such exists.) I know we can peruse the output of 'gcc -v' or 'gcc --version', though even that doesn't show us the date for the 2 sezero builds I looked at. Cheers, Rob -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiler incompatibilities
- Original Message - From: "Ozkan Sezer" > Win64-targeting builds from mingw-w64 up to 2010-04-27 didn't > follow MSVC x64 convention and did *not* prepend an undersocore > to the symbols: this is why you are seeing the incompatibilities > with the newer toolchains. > > All win64-targeting toolchains created after 2010-04-28, including > the sezero's gcc-4.4-based personal builds follow the MS convention. > > You should not be using those old toolchains. Thanks Ozkan. (Bloody hell have I got some work ahead of me :-) Cheers, Rob -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Compiler incompatibilities
Hi, On Windows Vista I have been using the 64-bit 4.6.0 cross-compiler (automated build 20100414) for close on 12 months. I'm now finding that the static and import libraries built using it are unusable by any of the recent 64-bit compilers (and vice versa). Looks like they require different global symbols prefixes, as I keep getting undefined references whenever I try to mix these libraries and compilers ? The "recent" compilers I've tried are automated builds 20110207, 20110408 (both 4.5.3) and 20110410 (4.7.0). Yet, in the past, I've had no trouble mixing libraries between that 4.6.0 compiler and an (equally old) 4.4.3 compiler. So I'm thinking the incompatibility has nothing to do with the fact that they have different gccversion numbers - rather that something changed in the way these compilers are now built. If I'm wrong about that, can anyone point me to a "recent" build of 4.6.0 that *would* be compatible with the 4.6.0 that I already have ? My interest in "recent" compilers is that they seem to be the only ones capable of building mpir. My old 4.6.0 compiler certainly can't ... with me at the helm, anyway. But I have no trouble at all using 20110410 (4.7.0)... if only I could then use the resultant static library with the 4.6.0 compiler Cheers, Rob -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] netCDF with MSYS/mingw-w64
- Original Message - From: "Ruben Van Boxem" To: "Ralf Tautenhahn" Cc: "mingw64" Sent: Tuesday, April 19, 2011 8:55 PM Subject: Re: [Mingw-w64-public] netCDF with MSYS/mingw-w64 >I am forwarding this to the mingw-w64 mailing list as well. > I have built netcdf-4.0.1, and I find the following notes that I kept: ### netcdf == First (for x64 build only), immediately below the first bunch of #includes near the beginning of libsr/v2i.c, insert: #include "nc.h" #include "rename.h" #include #include #include "rnd.h" #include "utf8proc.h" That's needed to get the NC struct defined. Then build 4.0.1 with: ./configure --disable-shared --enable-static --enable-netcdf-4 --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ AR=x86_64-w64-mingw32-ar LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm RANLIB=x86_64-w64-mingw32-ranlib --prefix=/usr/local CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib && make To build 4.1.1 we apparently need a TeX utility. The "--build" and "--host" arguments specified in the above are possibly unnecessary. The CPPFLAGS and LDFLAGS are set to /usr/local as that's where I generally install libraries that I've built. (I've since read that installing them there is not recommended practice.) No guarantees as to the accuracy of those notes, btw :-) HTH. Cheers, Rob -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MPFR 3.0.1: 3 tests fail
- Original Message - From: "Ruben Van Boxem" > > Three tests of MPFR 3.0.1 fail on mingw-w64, (sezero's 4.5.2 x64 > build). The "make check" log is attached. > If your build is seen as a cross-compilation (which, I think, happens if you provide --build and --host arguments to configure) then the configure script skips the tests that would have determined that "%td" and "%Lf" are unsupported with your compiler - and you end up with the errors you have reported. At least, that's what I found when I configured with "--build=i686-pc-mingw32 --host=x86_64-w64-mingw32". The solution, in my case, was to simply drop the "--build=i686-pc-mingw32 --host=x86_64-w64-mingw32" from the configure command. Configure then determined that "%td" and "%Lf" were unsupported, and modified the testing accordingly. Cheers, Rob -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] projects using MinGW64
- Original Message - From: "Jason" > Did "make check" pass OK? No - same problem when 'make check' tried to compile t-bswap.exe. > You need to link with -lmpir and include "mpir.h" , or configure with -- > enable-gmpcompat to get librarys and headers called -lgmp and include > "gmp.h" Yes, I used --enable-gmpcompat. And 'make install' installed both gmp.h and libgmp.h, in addition to mpir.h and libmpir.h. Including mpir.h (instead of gmp.h) and linking to libmpir.a (instead of libgmp.a) results in the same problem. > anyone can post to > > thempirt...@gmail.com Ok - I'll try posting there. (Sorry, my email to this list was short on detail - not sure that the "details" would be on topic here.) Thanks, Jason. Cheers, Rob -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] projects using MinGW64
- Original Message - From: "Jason" To: Sent: Monday, April 11, 2011 3:47 AM Subject: [Mingw-w64-public] projects using MinGW64 > Hi > > MPIR a fork of GMP now fully runs under MinGW64 see > > http://www.mpir.org/ Doesn't build for me actually, it builds ok (ie 'make' works), but the library that's built is unusable because of undefined references to the gmpn symbols. I've spent the last couple of hours trying to post to their google forum (as sprecified in the docs). What's the secret to getting thru ? All I can see at http://groups.google.com/group/mpir-devel is an option to post an email to the group - but my emails bounce, even after having joined the group. Christ, I hate google.groups !! Looks like mpir provides better assembly support for mingw64 than gmp - hence my interest in getting it to work. Cheers, Rob -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Issue with complex.h
Hi,
On Windows Vista 64, the demo program:
#
C:\_64\c>type try.c
#include
#include
int main(void) {
double _Complex rop, op, power;
__real__ op = 3.0;
__imag__ op = 0.0;
__real__ power = 2.0;
__imag__ power = 0.0;
rop = cpow(op, power);
printf("%f %f\n", creal(rop), cimag(rop));
return 0;
}
##
The result:
##
C:\_64\c>gcc -o try.exe try.c
c:/_64/mingw_straw/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.4.4/../../../../x86_64-w64-mingw32/lib/libmingwex.a(lib64_libmingwex_a-cpow.o):
In function `cpow':
/W64_157253-src/build-crt/../mingw-w64-crt/complex/cpow.c:39: undefined
reference to `_imp__pow'
collect2: ld returned 1 exit status
##
The version of gcc:
##
C:\_64\c>gcc -v
Using built-in specs.
Target: x86_64-w64-mingw32
Configured with:
../gcc44-svn/configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--disable-multilib --enable-checking=release --prefix=//mingw64
--with-sysroot=//mingw64
--enable-languages=c,c++,fortran,objc,obj-c++ --with-gmp=//mingw64
--with-mpfr=//mingw64
--disable-nls --disable-win32-registry
Thread model: win32
gcc version 4.4.4 20100306 (prerelease) [svn/rev.157253 - mingw-w64/oz]
(GCC)
#
Is there a "personal build" I should be trying instead of the one that I
have ?
I know that the 4.6.0 cross-compiler that I have doesn't suffer from this
problem - its handling of the _Complex data types and functions is
excellent.).
I currently have:
#
C:\_64\c>x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=c:/_64/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/l
to-wrapper.exe
Target: x86_64-w64-mingw32
Configured with:
../../../build/gcc/gcc/configure --target=x86_64-w64-mingw32
--prefix=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root
--with-sysroot=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root
--with-gmp=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/gmp/install
--with-mpfr=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/mpfr/install
--with-mpc=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/mpc/install
--enable-languages=all,obj-c++
--enable-fully-dynamic-string --disable-multilib
Thread model: win32
gcc version 4.6.0 20100414 (experimental) (GCC)
#
Is there a later build of that compiler ?
>From the "automated builds" section I just grabbed:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-1.0-bin_i686-mingw_20110207.zip/download
Is it 64-bit or 32-bit ? (In any case it's 4.5.3, not 4.6.x.)
Cheers,
Rob
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Looking for unsigned __int128
- Original Message - From: "Jim Michaels" > > 128-bit constants are not allowed in mingw-w64 apparently. they must be > designed into the language. > > I don't know why there isn't a 128-bit data type - there are UUID's on > UNIX, the > MAC, and the equivalent GUID on windows (a 128-bit number). > seems to me that a 128-bit number would be an ideal storage place for > this. All > you would need is some conversion stuff maybe - I guess that's up the > programmer. > All I know is that I couldn't find a way to directly assign 128-bit literals ... nor could I find a (s)printf formatter for 128-bit values. Initially, I just built my 128-bit values from __int64's, and then checked they were as expected by printf'ing the high 64 bits and low 64 bits. Since then, a Math::Int128 perl module has been written, which allows me to further verify that the 128-bit stuff is functioning correctly. (But I still haven't come across a way to either directly assign or printf 128-bit values in C with my compiler.) Cheers, Rob -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Looking for unsigned __int128
- Original Message - From: "Jim Michaels" > cool! I've been wanting to work with a 128-bit data type for a while > now... > now I can work with GUIDs easier. > is this available under stdint.h as uint128_t and int128_t? Not in my version (4.6.0 20100414) of the compiler - I can't speak for more recent editions. All I have is the (signed) __int128, and now the (unsigned) __uint128. However, I guess I could typedef them to int128_t and uint128_t if I wanted to use those symbols instead. Cheers, Rob -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Looking for unsigned __int128
- Original Message - From: "Kai Tietz" > > for an unsigned variant you can create an new type __uint128 as following: > > #ifdef _WIN64 > #ifndef __SIZEOF_INT128__ > typedef unsigned int __uint128 __attribute__ ((__mode__ (TI))); > #endif > #endif > #endif /* __GNUC__ */ > > Hope this helps. Seems to work fine. Thanks Kai. Cheers, Rob -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Looking for unsigned __int128
Hi , I'm running Vista64, and I have a build of mingw64 from last year that has the signed __int128 type, but (apparently) no unsigned __int128. Do we have a (pre-built) mingw64 compiler that provides the unsigned __int128 type ? Cheers, Rob -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] undefined reference to __GSHandlerCheck
- Original Message - From: "Dock, Dion" > Any thoughts on where `__GSHandlerCheck' and `__security_check_cookie' are > defined? There has to be > a way to link with a Visual Studio created > lib. When I build programs with my (64-bit) "Microsoft Platform SDK for Windows Server 2003 R2" compiler, I have to explicitly link to bufferoverflowu.lib (otherwise I get the "undefined reference to `__security_check_cookie'" error). I was also once plagued by the __GSHandlerCheck problem, too. A friend of mine sent me a file called 'gshandler.obj' from somewhere within his (64-bit) VC 8 compiler, and linking to it took care of the problem. I forget the details of how that problem arose - I think I might have been using a library he had compiled using VC 8 with the above-mentioned SDK compiler. Try linking to AMD64/runtmchk.lib (or any other runtmchk.lib you can find) - that might resolve the symbol. I think I still have that gshandler.obj (12kb). If you're wanting to use those libs with mingw-64, then all bets are off. Cheers, Rob -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] 64-bit dynamic libxml2
- Original Message - From: "Ozkan Sezer" To: "Sisyphus" >> That failure I reported happens when using the cross-compiler. >> Ozkan, I've just now finished building 2.7.8 with one of your builds and >> it >> went fine. > Well, I did test with a cross-compiler on linux. If it is fine with a > native compiler, then it still is a bug. Can you please report that > to their bugzilla? Done: https://bugzilla.gnome.org/show_bug.cgi?id=635123 Thanks again for the help. Cheers, Rob -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] 64-bit dynamic libxml2
- Original Message - From: "Ozkan Sezer" To: "Sisyphus" Cc: "mingw64" Sent: Wednesday, November 17, 2010 9:00 PM Subject: Re: [Mingw-w64-public] 64-bit dynamic libxml2 On Wed, Nov 17, 2010 at 11:31 AM, Sisyphus wrote: Reposting to list - last message blocked. - Original Message - From: "Ozkan Sezer" These issues should be fixed in libxml2-2.7.8, please try it, instead. -- O.S. Or, if you insist on using 2.7.7, see this bugzilla entry: https://bugzilla.gnome.org/show_bug.cgi?id=614087 Thanks O.S. No objection to switching to 2.7.8 - I would have done that anyway had I been aware of its existence (and I'm not really sure how I missed noticing it). Anyway, 2.7.8 takes care of the zlib problem but not the -lws2_32 issue so I'm still only getting a static build which, ironically, fails to define all symbols (such as '_imp__xmlFree', for obvious reasons). Here's the relevant section of output: ## *** Warning: linker path does not have real file for library -lws2_32. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libws2_32 and none of the candidates passed a file format test *** using a file magic. Last file checked: /c/Windows/system32/libws2_32.dll *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. libtool: link: x86_64-w64-mingw32-ar cru .. ## What needs to be done here ? Btw, that "Last file checked" (ie /c/Windows/system32/libws2_32.dll) doesn't even exist. Well, sorry that I responded without trying to compile myself. This seems like another libtool screwup to me. Pinging for autotools/libtool gurus out there please? That failure I reported happens when using the cross-compiler. Ozkan, I've just now finished building 2.7.8 with one of your builds and it went fine. See the attached v.txt for the 'gcc -v' output of both compilers. Cheers, Rob Here's the 'gcc -v' for the compiler (sezero build) that builds 2.7.8 fine: # $ gcc -v Using built-in specs. Target: x86_64-w64-mingw32 Configured with: ../gcc44-svn/configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --disable-multilib --enable-checking=release --prefix=//mingw64 --with-sysroot=//mingw64 --enable-languages=c,c++,fortran,objc,obj-c++ --with-gmp=//mingw64 --with-mpfr=//mingw64 --disable-nls --disable-win32-registry Thread model: win32 gcc version 4.4.4 20100306 (prerelease) [svn/rev.157253 - mingw-w64/oz] (GCC) # And here's the 'gcc -v' for the failing cross-compiler: # $ x86_64-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=c:\_64\mingw64\bin\x86_64-w64-mingw32-gcc.exe COLLECT_LTO_WRAPPER=c:/_64/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../build/gcc/gcc/configure --target=x86_64-w64-mingw32 --prefix=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root --with-sysroot=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root --with-gmp=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/gmp/install --with-mpfr=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/mpfr/install --with-mpc=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/mpc/install --enable-languages=all,obj-c++ --enable-fully-dynamic-string --disable-multilib Thread model: win32 gcc version 4.6.0 20100414 (experimental) (GCC) # -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] 64-bit dynamic libxml2
Reposting to list - last message blocked. - Original Message - From: "Ozkan Sezer" >> These issues should be fixed in libxml2-2.7.8, please try >> it, instead. >> >> -- >> O.S. >> > > Or, if you insist on using 2.7.7, see this bugzilla entry: > https://bugzilla.gnome.org/show_bug.cgi?id=614087 Thanks O.S. No objection to switching to 2.7.8 - I would have done that anyway had I been aware of its existence (and I'm not really sure how I missed noticing it). Anyway, 2.7.8 takes care of the zlib problem but not the -lws2_32 issue so I'm still only getting a static build which, ironically, fails to define all symbols (such as '_imp__xmlFree', for obvious reasons). Here's the relevant section of output: ## *** Warning: linker path does not have real file for library -lws2_32. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libws2_32 and none of the candidates passed a file format test *** using a file magic. Last file checked: /c/Windows/system32/libws2_32.dll *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. libtool: link: x86_64-w64-mingw32-ar cru .. ## What needs to be done here ? Btw, that "Last file checked" (ie /c/Windows/system32/libws2_32.dll) doesn't even exist. With these 64-bit libraries, should they load the System32 dll's, or should they load the SysWOW64 dll's ? (Or doesn't it matter ?) Cheers, Rob -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] 64-bit dynamic libxml2
Hi, Trying to build a 64-bit dynamic libxml2-2.7.7 and, during the make stage, I keep getting hammered by: *** Warning: linker path does not have real file for library -lz. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libz and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/local_dyn/lib/libz.dll.a *** Warning: linker path does not have real file for library -lws2_32. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libws2_32 and none of the candidates passed a file format test *** using a file magic. Last file checked: /c/Windows/system32/libws2_32.dll *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. libtool: link: ar cru ... I can build a 32-bit dynamic libxml2-2.7.7 library - same source, same shell, just different compiler. As the 32-bit build needs to find a 32-bit libz, and the 64-bit build needs to find a 64-bit libz, the configure args (namely LDFLAGS and CPPFLAGS) are a little different, and if I use the cross-compiler then I have to provide args for CC etc. /usr/local_dyn/lib/libz.dll.a (referred to in the above excerpt from the 'make' process) is, of course, the 64-bit import lib for the 64-bit zlib dll. As regards the system library (ws2_32) I'm sure that I once got around a similar problem with gdi32.dll by creating a copy of it called libgdi32.dll but I can't get the same "fix" to work re ws2_32.dll. Just to re-iterate - if the compiler is 32-bit (be it from mingw.org or from the mingw64 team) there's no problem, but if the compiler is 64-bit (be it one of sezero's builds or the cross-compiler) then there's seemingly no way I can build a dynamic libxml2 library in the msys shell. Does anyone here have a clear understanding of what this arcane procedure is doing, and of how to get it to realize that the dynamic libs are all there ? I did look at instead using the win32/Makefile.mingw that ships with the libxml2 sources, but it contains (in part): # There should never be a need to modify anything below this line. # AUTOCONF = .\config.mingw include $(AUTOCONF) and, of course, config.mingw doesn't even exist afaict. (Maybe I should explore this avenue further instead of trying to get configure to do the job properly.) Cheers, Rob -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] strtod and 'nan' and 'inf' strings
Hi,
The demo:
##
#include
#include
int main(void) {
double x;
char * ptr;
x = strtod("nan", &ptr);
printf("%f\n", x);
x = strtod("INf", &ptr);
printf("%f\n", x);
return 0;
}
##
With the mingw.org compilers that I've tested, the output of that program
is:
-1.#IND00
1.#INF00
But, on the same machine, with the mingw64 compilers that I've tested, the
output is:
0.00
0.00
Why the difference ?
Cheers,
Rob
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Installing MinGW 64-bit and MSYS
- Original Message - From: "Chris Saunders" To: "MinGW 64-bit" Sent: Monday, August 09, 2010 9:30 AM Subject: [Mingw-w64-public] Installing MinGW 64-bit and MSYS I had the 64-bit version installed before but had to re-install my OS. I downloaded the file mingw-w64-v1.0-snapshot-20100730.tar.bz2 but this doesn't seem to extract to the same directory structure I had before. == I think that was a source tarball that you downloaded - you're after an x64 pre-built mingw64 binary. But geez, it's currently hard to find such a beast at http://sourceforge.net/projects/mingw-w64/files/ . I was thinking, maybe: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-1.0-bin_i686-mingw_20100702.zip/download But that might be a 32-bit compiler ? (I'm thinking that the "i686-mingw" part denotes 32-bit, and that you're looking for "x86_64-mingw" instead which I don't see anywhere.) Better wait for some better advice :-) Cheers, Rob -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Change from 4.4.4 to 4.6.0
- Original Message - From: "Ozkan Sezer" >> you're supposed to include winsock2.h before windows.h, as windows.h by >> default includes the incompatible and older winsock.h. >> >> Plenty of software packages make this mistake. You'll need to fix up >> this assumptions. > > Well, I think he is using an old header-set, obviously. That's possible, I guess, though the "problem" compiler is a more recent build than the 4.4.4 that works fine. Is there a simple way of installing a recent set of headers into this 4.6.0 compiler ? I don't see any current cross-compiler binaries under automated builds that I can try out - they're all source distros. Making sure that winsock2.h gets included first worked fine, btw. (In libssh2_priv.h I simply included winsock2.h instead of windows.h.) In any case, I can stick with 4.4.4 for the time being. I don't have any *need* to use 4.6.0, and I can keep this particular glitch in mind if I ever do switch to that compiler. (Yeah right . "keep this particular glitch in mind" for about a week ... if that :-) Thanks guys. Cheers, Rob -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Change from 4.4.4 to 4.6.0
Hi, I have binaries for gcc-4.4.4 20100208 and gcc-4.6.0 20100414 (cross-compilers). The former builds libssh2-1.2.6 fine (in msys shell), but the latter doesn't. The errors produced by 4.6.0 (during the 'make' stage) are attached in m.txt. Any ideas on how this change of behaviour from one compiler to the other has come about ? The first error is: libssh2_priv.h: In function 'writev': libssh2_priv.h:121:24: error: 'LPWSABUF' undeclared (first use in this function) libssh2_priv.h:121:24: note: each undeclared identifier is reported only once for each function it appears in I can get rid of that error by #include'ing winsock2.h near the beginning of libssh2_priv.h (immediately after windows.h has been #include'd) ... but that doesn't help with the subsequent "redefinition" and "conflicting types" errors. Cheers, Rob Making all in src make[1]: Entering directory `/c/_32/comp/libssh2-1.2.6/src' make all-am make[2]: Entering directory `/c/_32/comp/libssh2-1.2.6/src' if /bin/sh ../libtool --tag=CC --mode=compile x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I../include -I../src -I/usr/local/include -I/usr/local/ssl/include -DWINSOCK_VERSION=0x0200 -MT channel.lo -MD -MP -MF ".deps/channel.Tpo" -c -o channel.lo channel.c; \ then mv -f ".deps/channel.Tpo" ".deps/channel.Plo"; else rm -f ".deps/channel.Tpo"; exit 1; fi libtool: compile: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I../include -I../src -I/usr/local/include -I/usr/local/ssl/include -DWINSOCK_VERSION=0x0200 -MT channel.lo -MD -MP -MF .deps/channel.Tpo -c channel.c -o channel.o In file included from channel.c:41:0: libssh2_priv.h: In function 'writev': libssh2_priv.h:121:24: error: 'LPWSABUF' undeclared (first use in this function) libssh2_priv.h:121:24: note: each undeclared identifier is reported only once for each function it appears in libssh2_priv.h:121:33: error: expected ')' before 'iov' In file included from libssh2_priv.h:138:0, from channel.c:41: c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h: At top level: c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:50:18: error: redefinition of 'struct fd_set' c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock.h:24:16: note: originally defined here c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:53:5: error: conflicting types for 'fd_set' c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock.h:27:3: note: previous declaration of 'fd_set' was here c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:55:21: error: conflicting types for '__WSAFDIsSet' c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock.h:33:21: note: previous declaration of '__WSAFDIsSet' was here In file included from libssh2_priv.h:138:0, from channel.c:41: c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:96:10: error: redefinition of 'struct hostent' c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock.h:78:8: note: originally defined here c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:104:10: error: redefinition of 'struct netent' c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock.h:86:8: note: originally defined here c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:111:10: error: redefinition of 'struct servent' c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock.h:93:8: note: originally defined here c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:123:10: error: redefinition of 'struct protoent' c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock.h:105:8: note: originally defined here c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:236:10: error: redefinition of 'struct sockaddr_in' c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock.h:199:8: note: originally defined here c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:246:18: error: redefinition of 'struct WSAData' c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock.h:209:16: note: originally defined here c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:262:5: error: conflicting types for 'WSADATA' c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock.h:225:3: note: previous declaration of 'WSADATA' was here c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:262:14: error: conflicting types for 'LPWSADATA' c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock.h:227:18: note: previous declaration of 'LPWSADATA' was here c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:349:10: error: redefinition of 'struct sockaddr' c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock.h:327:8: note: originally defined here c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:369:10: error: redefinition of 'struct sockproto' c:/_64/mingw64
Re: [Mingw-w64-public] Multiple definitions of __do_global_ctors, __do_global_dtors and __main
- Original Message - From: "Kai Tietz" To: "Sisyphus" Cc: "mingw64" Sent: Monday, May 31, 2010 8:59 PM Subject: Re: [Mingw-w64-public] Multiple definitions of __do_global_ctors, __do_global_dtors and __main > "Sisyphus" wrote on 31.05.2010 11:40:36: > >> Hi, >> >> I'm on Windows Vista64, using the x64 crosscompiler. >> >> The command being run (it's part of a build of a perl extension named > PDL) : >> >> ### >> x86_64-w64-mingw32-g++ -o >> ..\..\blib\arch\auto\PDL\Minuit\Minuit.dll -Wl,--base-file -Wl,dll.base > -mdll >> -s -L"c:\_64\perl512_M\lib\CORE" -L"C:\_64\mingw64\mingw\lib" Minuit.o >> minuitlib/futils.o minuitlib/minuit.o >> minuitlib/intracfalse.o -Wl,--image-base,0x241d >> C:\_64\perl512_M\lib\CORE\libperl512.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libgfortran.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libm.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\libgcc.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libmoldname.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libkernel32.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libuser32.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libgdi32.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libwinspool.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libcomdlg32.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libadvapi32.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libshell32.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libole32.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\liboleaut32.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libnetapi32.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libuuid.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libws2_32.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libmpr.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libwinmm.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libversion.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libodbc32.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libodbccp32.a >> c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\.. >> \x86_64-w64-mingw32\lib\libcomctl32.a >> dll.exp >> ### [snip] > > Well, if you are specifying runtime library to command line, you should > use -nostdlib, or don't add default libraries added by gcc driver itself. > Thanks Kai. The simplest way to get this working was to remove the link to libgcc. Someone please let me know if that's not sane. Cheers, Rob -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Multiple definitions of __do_global_ctors, __do_global_dtors and __main
Hi, I'm on Windows Vista64, using the x64 crosscompiler. The command being run (it's part of a build of a perl extension named PDL) : ### x86_64-w64-mingw32-g++ -o ..\..\blib\arch\auto\PDL\Minuit\Minuit.dll -Wl,--base-file -Wl,dll.base -mdll -s -L"c:\_64\perl512_M\lib\CORE" -L"C:\_64\mingw64\mingw\lib" Minuit.o minuitlib/futils.o minuitlib/minuit.o minuitlib/intracfalse.o -Wl,--image-base,0x241d C:\_64\perl512_M\lib\CORE\libperl512.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libgfortran.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libm.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\libgcc.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libmoldname.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libkernel32.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libuser32.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libgdi32.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libwinspool.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libcomdlg32.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libadvapi32.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libshell32.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libole32.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\liboleaut32.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libnetapi32.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libuuid.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libws2_32.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libmpr.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libwinmm.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libversion.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libodbc32.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libodbccp32.a c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..\x86_64-w64-mingw32\lib\libcomctl32.a dll.exp ### The '.o' files in the above command are compiled using gfortran at an earlier stage of the same build process. I've tried using both 'gcc version 4.4.4 20100208 (prerelease) (GCC)' (which is the compiler that built perl) and 'gcc version 4.6.0 20100414 (experimental) (GCC)'. In both cases the same errors occur. The errors generated by the above command: ### C:\_64\mingw64\mingw\lib/libmingw32.a(lib64_libmingw32_a-gccmain.o): In function `_do_global_ctors': g:\buildbot\vista64-mingw32\mingw-x86-x86_64\build\build\mingw\obj/../../../build/mingw/mingw-w64-crt/crt/gccmain.c:46: multiple definition of `__do_global_ctors' c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\libgcc.a(__main.o):g:\buildbot\vista64-mingw32\mingw-x86-x86_64\build\build\gcc\obj\x86_64-w64-mingw32\libgcc/../../../../../build/gcc/gcc/libgcc/../gcc/libgcc2.c:2160: first defined here C:\_64\mingw64\mingw\lib/libmingw32.a(lib64_libmingw32_a-gccmain.o): In function `_main': g:\buildbot\vista64-mingw32\mingw-x86-x86_64\build\build\mingw\obj/../../../build/mingw/mingw-w64-crt/crt/gccmain.c:80: multiple definition of `__main' c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\libgcc.a(__main.o):g:\buildbot\vista64-mingw32\mingw-x86-x86_64\build\build\gcc\obj\x86_64-w64-mingw32\libgcc/../../../../../build/gcc/gcc/libgcc/../gcc/libgcc2.c:2184: first defined here C:\_64\mingw64\mingw\lib/libmingw32.a(lib64_libmingw32_a-gccmain.o): In function `_do_global_dtors': g:\buildbot\vista64-mingw32\mingw-x86-x86_64\build\build\mingw\obj/../../../build/mingw/mingw-w64-crt/crt/gccmain.c:28: multiple definition of `__do_global_dtors' c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\libgcc.a(__main.o):g:\buildbot\vista64-mingw32\mingw-x86-x86_64\build\build\gcc\obj\x86_64-w64-mingw32\libgcc/../../../../../build/gcc/gcc/libgcc/../gcc/libgcc2.c:2131: first defined here C:\_64\mingw64\mingw\lib/libmingw32.a(lib64_libmingw32_a-gccmain.o):gccmain.c:(.text+0x7a): undefined reference to `_imp__GetModuleHandleA' collect2: ld returned 1 exit status dmake: Error code 129, while making '..\..\blib\arch\auto\PDL\Minuit\Minuit.dll' dmake: Error code 255, while making 'subdirs' dmake: Error code 255, while making 'subdirs' ##
Re: [Mingw-w64-public] openssl
- Original Message - From: "Brian Lewis" > Have you built DLLs, though? Alas, no. Assuming you're gcc executable is named 'gcc.exe', you should be able to start with './config shared no_asm'. Then, in the resultant top level Makefile, remove the one occurrence of '-march=i486'. I think there will also be a need to remove the word 'static' from the definition of OPENSSL_IMPLEMENT_GLOBAL in e_os2.h. (That file is to be found in the top level folder and also in openssl/include - I amended both copies.) The changes that were made to store.h, pem.h and e_aep.c are probably still required, though the '-lws2_32 -lgdi_32' link should no longer be needed. But the problem I'm faced with is that 'no-asm' does not (afaict) actually provide 'no-asm' - because, if you look in the top level Makefile, you find: # CPUID module collects small commonly used assembler snippets CPUID_OBJ= uplink.o uplink-cof.o And, sure enough, very early into the 'make' process I get assembler errors: uplink-cof.s: Assembler messages: uplink-cof.s:5: Error: suffix or operands invalid for `push' uplink-cof.s:6: Error: suffix or operands invalid for `push' [snip] uplink-cof.s:173: Error: suffix or operands invalid for `push' uplink-cof.s:174: Error: suffix or operands invalid for `push' That's a show stopper for me. (That doesn't mean it can't be worked around - it just means that I don't know *how* to work around it. I'll ask about that on the openssl mailing list.) Cheers, Rob -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] openssl
- Original Message - From: "Sisyphus" > Then, in the test/Makefile, add ' -lws2_32 -lgdi32' to LIBDEPS (wherever I > find an assignment to 'LIBDEPS' in that Makefile). Same applies to apps/Makefile. (Seems to be the only detail I missed.) Cheers, Rob -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] openssl
- Original Message - From: "Brian Lewis" To: Sent: Tuesday, May 18, 2010 7:57 AM Subject: [Mingw-w64-public] openssl > Has anyone built openssl 0.9.8n? Been bangin' my head against the same wall for more hours than I care to admit. Here's how I've hacked my way through it. I've persevered with the MSYS shell, where I'm trying to build a static lib. Because I'm using the mingw64 cross-compiler (where the gcc executable is called 'x86_64-w64-mingw32-gcc.exe') I need to use the os/compile switch with ./config. I don't yet know how to tell the build processs to use 'x86_64-w64-mingw32-ar.exe' instead of 'ar.exe' (which doesn't exist), so I've cheated and copied 'bin/x86_64-w64-mingw32-ar.exe' to 'bin/ar.exe'. Here's the ./config command I start with: ./config no-shared no-asm os/compiler:x86_64-w64-mingw32-gcc -DDSO_WIN32 -mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -D_WIN32_WINNT=0x333 All of those compiler defines and switches are the same as used by the 32-bit gcc-3.4.5 from mingw.org (which builds openssl-0.9.8n just fine for me, btw). I've dropped the '-march=i486' switch, but kept the rest. Does anyone know what should be specified for '-march' when using this compiler ? After running that, I place the following near the beginning (before any #includes) of include/openssl/store.h and include/openssl/pem.h: #if defined(OPENSSL_SYS_WINDOWS) #include #undef X509_NAME #undef X509_EXTENSIONS #undef X509_CERT_PAIR #undef PKCS7_ISSUER_AND_SERIAL #undef OCSP_REQUEST #undef OCSP_RESPONSE #endif And, at the start of engines/e_aep.c: #ifndef NO_OLDNAMES #define NO_OLDNAMES #endif (The former was based on a posting at http://rt.openssl.org/Ticket/Display.html?id=2182&user=guest&pass=guest and the latter just fixes a pid_t redefinition error. If NO_OLDNAMES is defined, then sys/types.h doesn't typedef the 'pid_t' and there's no problem. I first tried a -DNO_OLDNAMES switch in the ./config command, but there are other files in the openssl source that want that symbol to be undefined.) 'store.h' (and perhaps also 'pem.h') gets re-generated when running the initial ./config command - so don't modify those files until after running ./config. Then, in the test/Makefile, add ' -lws2_32 -lgdi32' to LIBDEPS (wherever I find an assignment to 'LIBDEPS' in that Makefile). Thne run 'make', and it's all built !! 'make test' runs fine. As a final hurdle, 'make install' croaks with: chmod: changing permissions of `/usr/local/ssl/bin/openssl.new': Bad file number The files is actually called `/usr/local/ssl/bin/openssl.new.exe'. For the moment, I'll just manually rename it to 'openssl.exe' and complete the installation by hand - there's only a handful of files yet to be installed. `/usr/local/ssl/bin/openssl.new'If there's something there that helps, that's good. I'll just go back to a fresh install and check that it builds as I've stated above (in case I've missed a detail or two). Then I can look at how these fixes *ought* to be implemented. (Advice on how that might be done is most welcome.) Cheers, Rob -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Repost] LIBRARY_PATH environment variable not honoured.
- Original Message - From: "NightStrike" To: "Doug Semler" >> LIBRARY_PATH is ignored in cross compilers. > > The toolchain in question is host=win32 target=win64. So it is meant > to cross compile from a 32-bit windows generating binaries for a > 64-bit windows. It just so happens that you can run this on win64, > since win64 can run win32 programs. But that doesn't mean that we > should treat it like it's not a cross compiler. > Ok - I think I get the picture. If I want ot make use of the LIBRARY_PATH environment variable I should grab sezero's binary (which is not a cross-compiler) and use it instead. I've just checked, and sezero's build does honour the LIBRARY_PATH setting. Thanks Doug, NightStrike. Cheers, Rob -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Repost] LIBRARY_PATH environment variable not honoured.
- Original Message - From: "Doug Semler" To: "Sisyphus" Cc: "mingw64" Sent: Wednesday, April 21, 2010 2:45 AM Subject: Re: [Mingw-w64-public] [Repost] LIBRARY_PATH environment variable not honoured. Oops, should have qualified that - i meant the output during compileIOW make CFLAGS=-v If I run 'x86_64-w64-mingw32-gcc -c try.c -v' (where try.c is a simple "hello" script), will that give you all you need ? (Ouptut attached.) It occurred to me later at work (where I had no internet connection) that you were probably after that. If that's still not right, just yell at me and I'll do as you asked above :-) I see a LIBRARY_PATH specified in the output - that has nothing to do with my LIBRARY_PATH env var. (If I remove that environment variable, I still get the same result.) Cheers, Rob Using built-in specs. Target: x86_64-w64-mingw32 Configured with: ../../../build/gcc/gcc/configure --target=x86_64-w64-mingw32 --prefix=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root --with-sysroot=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root --with-gmp=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/gmp/install --with-mpfr=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpfr/install --with-mpc=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpc/install --enable-languages=all,obj-c++ --enable-fully-dynamic-string --disable-multilib Thread model: win32 gcc version 4.4.4 20100208 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' c:/_64/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.4.4/cc1.exe -quiet -v -iprefix c:\_64\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.4/ try.c -quiet -dumpbase try.c -mtune=generic -auxbase try -version -o C:\Users\Rob\AppData\Local\Temp\ccoUbhzT.s ignoring nonexistent directory "g:/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/rootg:/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root/include" ignoring duplicate directory "c:/_64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.4.4/include" ignoring duplicate directory "c:/_64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.4.4/include-fixed" ignoring nonexistent directory "g:/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root/mingw/include64" #include "..." search starts here: #include <...> search starts here: C:\_64\msys\1.0\local\include c:\_64\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.4/include c:\_64\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.4/include-fixed c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include End of search list. GNU C (GCC) version 4.4.4 20100208 (prerelease) (x86_64-w64-mingw32) compiled by GNU C version 4.3.0 20080305 (alpha-testing) mingw-20080502, GMP version 4.3.2, MPFR version 2.4.2. GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130914 Compiler executable checksum: 3fab9df8484568e7a7a6ed21212fa369 COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' c:/_64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.4.4/../../../../x86_64-w64-mingw32/bin/as.exe -o try.o C:\Users\Rob\AppData\Local\Temp\ccoUbhzT.s COMPILER_PATH=c:/_64/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.4.4/;c:/_64/mingw64/bin/../libexec/gcc/;c:/_64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.4.4/../../../../x86_64-w64-mingw32/bin/ LIBRARY_PATH=c:/_64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.4.4/;c:/_64/mingw64/bin/../lib/gcc/;c:/_64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.4.4/../../../../x86_64-w64-mingw32/lib/ COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Repost] LIBRARY_PATH environment variable not honoured.
- Original Message - From: "Doug Semler" To: "Sisyphus" Cc: "mingw64" Sent: Monday, April 19, 2010 10:30 PM Subject: Re: [Mingw-w64-public] [Repost] LIBRARY_PATH environment variable not honoured. Can you post the output of gcc -v so I can see what the search path actually ends up being on that link attempt ( without the -L param that is). Attached - I think a copy'n'paste would only get mangled by my mail program. I'm using (cross-compiler) binaries I downloaded from http://sourceforge.net/projects/mingw-w64/files/ The actual package I downloaded was mingw-w64-1.0-bin_i686-mingw_20100208.zip. Cheers, Rob Using built-in specs. Target: x86_64-w64-mingw32 Configured with: ../../../build/gcc/gcc/configure --target=x86_64-w64-mingw32 --prefix=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root --with-sysroot=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root --with-gmp=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/gmp/install --with-mpfr=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpfr/install --with-mpc=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpc/install --enable-languages=all,obj-c++ --enable-fully-dynamic-string --disable-multilib Thread model: win32 gcc version 4.4.4 20100208 (prerelease) (GCC) -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Repost] LIBRARY_PATH environment variable not honoured.
- Original Message - From: "Doug Semler" >> With mingw64, is there currently some way I can avoid having to use >> the -L >> switch in relation to libraries in that location ? >> If not, are there any plans to introduce such a feature ? > This is an environment/gcc thing, and not a mingw64 thing. Yes, I believe so - and since the mingw64 project is providing a port of gcc, I thought that port of gcc would honour the LIBRARY_PATH. All I really want to know is whether the current behaviour regarding LIBRARY_PATH is intentional (and it will stay as it is) or an oversight (that will be addressed in the future). What should I do in order to get that question answered ? Is there some other way of adding C:/_64/msys/1.0/local/lib to the default library search path so that I can avoid using the -L switch all the time ? Cheers, Rob -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [Repost] LIBRARY_PATH environment variable not honoured.
Hi, I asked about this on 14 Oct last year (http://sourceforge.net/mailarchive/forum.php?thread_name=A00A469F7EBE4419992A92CBC29D03F5%40desktop2&forum_name=mingw-w64-public) and didn't get any replies - so I thought I'd ask again and see what information I can glean this time. With mingw32 (from mingw.org), I have built and installed a number of libraries (eg gmp) in C:\_32\msys\1.0\local\lib. Because I have set the LIBRARY_PATH environment variable to 'C:\_32\msys\1.0\local\lib', I can link to those libraries without having to use the -L switch. That is, I can build gmp apps by running: gcc -o gmp_app.exe gmp_app.c -lgmp With mingw64, the corresponding libs are in C:\_64\msys\1.0\local\lib and, again, I've set the LIBRARY_PATH environment variable to that directory. But the same command can't find the gmp library, and therefore fails. Instead, I have to run gcc -o gmp_app.exe gmp_app.c -LC:\_64\msys\1.0\local\lib -lgmp With mingw64, is there currently some way I can avoid having to use the -L switch in relation to libraries in that location ? If not, are there any plans to introduce such a feature ? Cheers, Rob -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Problem building a static gsl-1.14
- Original Message - From: "DougS" To: "Sisyphus" Cc: "mingw64" Sent: Thursday, March 25, 2010 1:48 PM Subject: Re: [Mingw-w64-public] Problem building a static gsl-1.14 > Well. You now know why we can't reproduce in a cross compiler. I don't > recall offhand but does windows come with a sort program???Maybe the > msys one is not early enough in the path??? Bah!! That's it: r...@desktop2 /c/_64/comp/gsl-1.14 $ which sort /c/Windows/SysWOW64/sort My fault for having /c/Windows/SysWOW64 at the beginning of the path. With that taken care of, all works well. (I'll update the gsl bug report that I sent.) Thanks Doug. Cheers, Rob -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Problem building a static gsl-1.14
- Original Message - From: "Doug Semler" > Actually, the command that's failing is: > > x86_64-w64-mingw32-ar t > "/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a" | sort | sort -uc > > (The error message is misleading because it prepends the extract > directory onto the archive name, and it is not the actual command > that's failing). > > if you run that command, what happens? > I get: ## r...@desktop2 /c/_64/comp/gsl-1.14 $ x86_64-w64-mingw32-ar t "/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a" | sort | sort -uc -ucThe system cannot find the file specified. r...@desktop2 /c/_64/comp/gsl-1.14 $ x86_64-w64-mingw32-ar t "/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a" init.o file.o block.o r...@desktop2 /c/_64/comp/gsl-1.14 $ x86_64-w64-mingw32-ar t "/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a" | sort block.o file.o init.o r...@desktop2 /c/_64/comp/gsl-1.14 $ x86_64-w64-mingw32-ar t "/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a" | sort -uc -ucThe system cannot find the file specified. ## I don't know what the '-uc' is supposed to do, but it apparently gets interpreted as a filename (which doesn't exist, of course). The 3 files (block.o, file.o and init.o) are to be found in the gsl-1.14/.libs/libgsl.lax/libgslblock.a/ folder, as is supposed to happen I believe. (They were there at the time the 'make' process errored out.) I've just had a quick look at 'man sort' on my linux box. I can't successfully apply any of the switches there to the sort command in the msys shell. They all seem to produce "The system cannot find the file specified" error, even if I use the longhand form (ie --unique instead of -u). Cheers, Rob -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Problem building a static gsl-1.14
Hi, I've posted to gsl-bugs about this ... without success. I'm not even sure that it's a gsl bug - there's a thread at http://www.mail-archive.com/bug-libt...@gnu.org/msg00374.html where the error is of a very similar type. In that particular instance it turned out to be a libtool (ltmain.sh) bug. However, I've been unable to adapt the ltmain.sh patch that worked there to my particular situation. No problems with a dynamic build of gsl-1.14, btw ... it's just the static build that's being uncooperative. When trying to build a static gsl-1.14 library with mingw64 in the MSYS shell, I start with: $ ./configure --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ AR=x86_64-w64-mingw32-ar LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm RANLIB=x86_64-w64-mingw32-ranlib --disable-shared --enable-static && make (For the dynamic build I use the same, except that it's "--disable-static --enable-shared".) Everything is fine until we get near the end of the make process, when this happens: ## /bin/sh ./libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -g -O2 -version-info 15:0:15 -no-undefined -o libgsl.la -rpath /usr/local/lib version.lo block/libgslblock.la blas/libgslblas.la bspline/libgslbspline.la [SNIP lots of other.la files] wavelet/libgslwavelet.la cblas/libgslcblas.la -lm libtool: link: (cd .libs/libgsl.lax/libgslblock.a && x86_64-w64-mingw32-ar x "/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a") libtool: link: object name conflicts in archive: .libs/libgsl.lax/libgslblock.a//c/_64/comp/gsl-1.14/block/.libs/libgslblock.a make[2]: *** [libgsl.la] Error 1 make[2]: Leaving directory `/c/_64/comp/gsl-1.14' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/_64/comp/gsl-1.14' make: *** [all] Error 2 ### The 'cd .libs/libgsl.lax/libgslblock.a && x86_64-w64-mingw32-ar x "/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a"' command apparently succeeds - the 3 object files in libgslblock.a are to be found in the .libs/libgsl.lax/libgslblock.a/ folder. Does that error mean anything to anyone here ? Any advice on something I could try to get around it ? My "x86_64-w64-mingw32-gcc -v" is provided below my sig. Cheers, Rob r...@desktop2 ~ $ x86_64-w64-mingw32-gcc -v Using built-in specs. Target: x86_64-w64-mingw32 Configured with: ../../../build/gcc/gcc/configure --target=x86_64-w64-mingw32 --prefix=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root --with-sysroot=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root --with-gmp=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/gmp/install --with-mpfr=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpfr/install --with-mpc=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpc/install --enable-languages=all,obj-c++ --enable-fully-dynamic-string --disable-multilibThread model: win32gcc version 4.4.4 20100208 (prerelease)(GCC) -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Available downloads
Hi, At http://sourceforge.net/projects/mingw-w64/files/ I see mingw-w64-bin_i686-linux_20100307.tar.bz2 but no mingw-w64-bin_i686-mingw_20100307.zip. Are the "mingw" cross compiler builds no longer being made available ? Cheers, Rob -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Bulding gmp-5.0.0 with MinGW64 (in MSYS shell).
- Original Message - From: "JonY" To: "Ozkan Sezer" Cc: "Sisyphus" ; Sent: Wednesday, January 20, 2010 1:06 AM Subject: Re: [Mingw-w64-public] Bulding gmp-5.0.0 with MinGW64 (in MSYS shell). > On 1/19/2010 21:55, Ozkan Sezer wrote: >> On Tue, Jan 19, 2010 at 3:50 PM, JonY >> wrote: >>> On 1/19/2010 20:03, Sisyphus wrote: >>>> >>>> - Original Message - >>>> From: "Ozkan Sezer" >>>> >>>>>> Firstly, the command I'm running to build and test gmp-5.0.0 is: >>>>>> >>>>>> ./configure --disable-shared --enable-static --host=none-none-none >>>>>> CC="x86_64-w64-mingw32-gcc -std=gnu99" CXX=x86_64-w64-mingw32-g++ >>>>>> AR=x86_64-w64-mingw32-ar LD=x86_64-w64-mingw32-ld >>>>>> NM=x86_64-w64-mingw32-nm >>>>>> RANLIB=x86_64-w64-mingw32-ranlib ABI=longlong&& make&& make >>>>>> check -i >>>>>> >>>>> >>>>> I would have suggested using configure --build=x86_64-w64-mingw32 >>>>> --target=x86_64-w64-mingw32 >>>> >>>> Unfortunately that doesn't get me very far: >>>> >>>> # >>>> r...@desktop2 /c/_32/comp/gmp-5.0.0 >>>> $ ./configure --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 >>>> configure: error: --target is not appropriate for GMP >>>> Use --build=CPU-VENDOR-OS if you need to specify your CPU and/or system >>>> explicitly. Use --host if cross-compiling (see "Installing GMP" in the >>>> manual for more on this). >>>> >>>> r...@desktop2 /c/_32/comp/gmp-5.0.0 >>>> >>>> # >>> --target is only valid for GCC/Binutils, use --build/--host instead. >> >> Oops, really meant --host, not --target when I wrote that. >> I guess people can't read mind, don't they ;) I don't even know what *I* am thinking half the time ;-) Ok ... I've now tried by running: $ ./configure --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ AR=x86_64-w64-mingw32-ar LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm RANLIB=x86_64-w64-mingw32-ranlib I still get the same failures, plus 2 additional failures - both misc/t-printf.exe and misc/t-scanf.exe now fail to build because of some undefined references to __gmp_replacement_vsnprintf, __gmp_sscanf and __gmp_vfscanf. I notice that __GMP_CFLAGS has changed from "-O2 -pedantic -std-gnu99" to "-O2 -pedantic -m64 -std=gnu99 -mtune=k8 -march=k8". Does this constitute some improvement in the gmp library that I've built ? I notice also that the latest build (unlike my earlier builds) did not define "NO_ASM" ... but it's still a "generic C" build, isn't it ? (There were no .asm files mentioned in the linking at the end of the 'configure' step.) >>> The localeconv error is a known problem for win32/win64 target, you can >>> ignore it. >>> >> >> The thing is, that particular problem doesn't show up >> with mingw.org compiler (I had tested with their >> gcc-3.4.5 based toolchain in the past, don't know about >> the behavior with their newer 4.4-based compilers). > iiuc, it will fail on modern mingw.org too. I just tried with gcc-4.4.0 from mingw.org and there were no test failures. (I'm not sure if it's the latest gcc-4.4.x available from them - had a quick look and couldn't find a gcc-4.4.x distro anywhere at http://sourceforge.net/projects/mingw/files/ , so I just used the one I already had from a few months back.) > libmsvcrt.a now exports localeconv, but t-locale is trying to use its > own implementation, hence the multiple definition error. Yep - it was stated above that this is a "known issue". Does that mean there's no need to report it to gmp-bugs ? As regards the t-perfpow.exe problem, I'm still wondering whether that should that be reported to gmp-bugs ? Thanks for the replies, guys ! Cheers, Rob -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
