mingw-w64

I saw that in the project page it is written that: Better-conforming and faster math support compared to Visual Studio's. I was wondering what does it mean? I was under the impression it uses Windows C libary with its math functions. Does MinGW use GCC's libm? If not, what's the difference? Is there a way to use libm on Windows with MinGW64? Thank You.

I need to compile boost-python 1.73.0 with MinGW64 on Fedora's rawhide, so that I can build Python bindings for Windows 10 64bit. And unfortunately the only library missing from Fedora's mingw64-boost package is boost-python, argggh! Actually all dependencies are packaged on Fedora for MinGW64, which is quite nice. So I'm trying to build myself with: wget https://dl.bintray.com/boostorg/release/1.73.0/source/boost_1_73_0.tar.bz2 tar -xjf boost_1_73_0.tar.bz2 && cd boost_1_73_0 ./bootstrap.sh # in...

Hi Thank you for the reply. Why you assume that a local variable va is modified under the hood by a different function? As long as you don't pass reference to it, you are not able to modify its contents for an outer function. That's interresting, as soon as I read that line I was like "what an idiot". But then, I realized that the issue here was actually the misleading gcc/libc/... from my distribution because, well it "works" even though I'm passing the va_list as an argument and not as a reference...

Hi Thank you for the reply. Why you assume that a local variable va is modified under the hood by a different function? As long as you don't pass reference to it, you are not able to modify its contents for an outer function. That's interresting, as soon as I read that line I was like "what an idiot". But then, I realized that the issue here was actually the misleading gcc/libc/... from my distribution because, well it "works" even though I'm passing the va_list as an argument and not as a reference...

Hello, Sorry for telling you, but your assumptions about passing va_list as argument, and how it behalfs is plain wrong. So your test-code is invalid. Why you assume that a local variable va is modified under the hood by a different function? As long as you don't pass reference to it, you are not able to modify its contents for an outer function. int foo(va_list argp) { return va_arg(argp, int); } void zoo(const char *fmt, ...) { va_list argp; argp=va_start(argp, fmt); fprintf(stderr, fmt, foo(argp),...

Hmm, sorry. I mixed your report up. There was another report with code sample, which claimed that va_list would be broken. Sorry about that. Nevertheless you should report this to gcc people too. As it is more a target-library issue in gcc AFAICS. Regards, Kai Am Mo., 28. Sept. 2020 um 15:27 Uhr schrieb Brecht Sanders brechtsanders@users.sourceforge.net: @ktietz70 I'm sorry, but I'm not following where you think this wrong assumtion was made. Is this in both gcc and pkg-config source code? Or are...

For what is worth the OS is Windows 7 Pro, also the quick checking of a textual file shows the GCC binary works "PROPERLY": D:\Satanichi_aka_Nakamichi_2020-Jun-09>dir 06/11/2020 09:16 AM 55,397 lzsse2.cpp 06/11/2020 09:16 AM 1,316,439 Nakamichi_Ryuugan-ditto-1TB_btree.c 09/06/2019 11:50 AM 969,050,128 NCBI_FTP_Homo_sapiens_(human)_GCA_000001405.28_GRCh38.p13_genomic.fna.Nakamichi 06/15/2019 02:37 AM 3,313,087,324 q 01/07/2018 05:26 PM 191,644 Satanichi_GCC730_64bit.exe 06/11/2020 09:16 AM 198,144...

@ktietz70 I'm sorry, but I'm not following where you think this wrong assumtion was made. Is this in both gcc and pkg-config source code? Or are you referring to some other code?

The same said the GCC guy in the link above: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215#c4 (In reply to Andrew Pinski from comment #2) You need b if you don't want \r\n to be turned into just \n. At 11,945th line I use: if ((fp = fopen(argv[1">, "rb")) == NULL) { printf("Nakamichi: Can't open '%s' file.\n", argv[1">); exit(13); } 1"> As far as I investigated, the problem is that fread() reads less (around 860 bytes) than specified. 2"> Also, as I wrote: This bug never appeared with files 1GB...

The same said the GCC guy in the link above: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215#c4 (In reply to Andrew Pinski from comment #2) You need b if you don't want \r\n to be turned into just \n. At 11,945th line I use: if ((fp = fopen(argv[1">, "rb")) == NULL) { printf("Nakamichi: Can't open '%s' file.\n", argv[1">); exit(13); } 1"> As far as I investigated, the problem is that fread() reads less (around 860 bytes) than specified. 2"> Also, as I wrote: This bug never appeared with files 1GB...