I'm not sure about pthread, never used it. There is a "phread.h" file in C:\msys64\mingw64\x86_64-w64-mingw32\include.

If you search for pthread using pacman: "pacman -Ss pthread" you get:
[CODE]
mingw32/mingw-w64-i686-libwinpthread-git 5.0.0.4833.f057c525-1 (mingw-w64-i686-toolchain)
MinGW-w64 winpthreads library
mingw32/mingw-w64-i686-winpthreads-git 5.0.0.4833.f057c525-1 (mingw-w64-i686-toolchain)
MinGW-w64 winpthreads library
mingw64/mingw-w64-x86_64-libwinpthread-git 5.0.0.4833.f057c525-1 (mingw-w64-x86_64-toolchain) [installed]
MinGW-w64 winpthreads library
mingw64/mingw-w64-x86_64-winpthreads-git 5.0.0.4833.f057c525-1 (mingw-w64-x86_64-toolchain) [installed]
MinGW-w64 winpthreads library
msys/mingw-w64-cross-winpthreads-git 5.0.0.4767.34ac6b9-1 (mingw-w64-cross-toolchain mingw-w64-cross)
MinGW-w64 winpthreads library for cross-compiler
[/CODE]

So "[I]mingw-w64-x86_64-winpthreads-git 5.0.0.4833.f057c525-1[/I]" and "[I]mingw-w64-x86_64-libwinpthread-git 5.0.0.4833.f057c525-1[/I]" are already installed at least on my version, but perhaps you need to run some of the additional pacman installations I listed.

Another good thing about MSYS2 is that when you are done upgrading packages, you can move the folder to another computer and use it as it is.

[QUOTE=ATH;460942]I'm not sure about pthread, never used it. There is a "phread.h" file in C:\msys64\mingw64\x86_64-w64-mingw32\include.

If you search for pthread using pacman: "pacman -Ss pthread" you get:
[CODE]
mingw32/mingw-w64-i686-libwinpthread-git 5.0.0.4833.f057c525-1 (mingw-w64-i686-toolchain)
MinGW-w64 winpthreads library
mingw32/mingw-w64-i686-winpthreads-git 5.0.0.4833.f057c525-1 (mingw-w64-i686-toolchain)
MinGW-w64 winpthreads library
mingw64/mingw-w64-x86_64-libwinpthread-git 5.0.0.4833.f057c525-1 (mingw-w64-x86_64-toolchain) [installed]
MinGW-w64 winpthreads library
mingw64/mingw-w64-x86_64-winpthreads-git 5.0.0.4833.f057c525-1 (mingw-w64-x86_64-toolchain) [installed]
MinGW-w64 winpthreads library
msys/mingw-w64-cross-winpthreads-git 5.0.0.4767.34ac6b9-1 (mingw-w64-cross-toolchain mingw-w64-cross)
MinGW-w64 winpthreads library for cross-compiler
[/CODE]

So "[I]mingw-w64-x86_64-winpthreads-git 5.0.0.4833.f057c525-1[/I]" and "[I]mingw-w64-x86_64-libwinpthread-git 5.0.0.4833.f057c525-1[/I]" are already installed at least on my version, but perhaps you need to run some of the additional pacman installations I listed.

Another good thing about MSYS2 is that when you are done upgrading packages, you can move the folder to another computer and use it as it is.[/QUOTE]

Yeah, I did all that yesterday - must say, msys2's package-mgmt setup is very nice indeed. Ended up installing the two x86_64-contained-in-name of your listed quintet, but still no joy re. pthread.h header. I had a peek at the last item, but it's a big download and 'cross-compilation' sounds rather different than 'basic pthread infrastructure.' Will do a bit more searching for "pthreaded build under msys2" on the web later today.

By way of an epilog to this thread - the issue of multithreaded builds inside Linux emulation in Windows has been neatly solved: MSFT finally did something right and [url=http://www.mersenneforum.org/showthread.php?t=22468]built such emulation into Win10[/url], complete with many or most standard libs, including pthreads. Finally a good reason to upgrade to Win10, IMO, with the obligatory "if you must use Windows" caveat.

[QUOTE=ATH;460789]It is really easy to use MSYS2: Download the msys2-x86_64 package and install: [URL]http://www.msys2.org/[/URL]

Run these commands in MSYS2:
pacman -Syu
(restart MSYS2)
pacman -Su
(restart MSYS2)

To install the packages needed to compile GMPECM i usually download these packages:

pacman -S mingw-w64-x86_64-gcc
pacman -S mingw-w64-x86_64-make
pacman -S mingw-w64-x86_64-make
pacman -S autoconf
pacman -S automake
pacman -S mingw-w64-x86_64-python3

and then you are ready to go and everything is located inside the C:\msys64 folder, there is no additional c:\mingw64 folder installation needed like in MSYS.[/QUOTE]


Cher

I would be very grateful if you can help me.


Windows 10 Mingw64
gc -v

gcc version 10.2.0 (Rev5, Built by MSYS2 project)


gcc -c -O3 -DUSE_SSE2 -DUSE_THREADS ../src/*.c >& build.log
grep error build.log
gcc -o Mlucas *.o -lm -lpthread -lrt



~/mlucas_v19/src

build.log

../src/platform.h:1307:12: fatal error: sys/sysctl.h: No such file or directory
1307 | #include <sys/sysctl.h>
Antonio Donato Filho

Hi, Antonio --

[QUOTE=Donato;562648]../src/platform.h:1307:12: fatal error: sys/sysctl.h: No such file or directory
1307 | #include <sys/sysctl.h>
Antonio Donato Filho[/QUOTE]

I no longer have access to a Windows system - can you find out the main directory where the header files are located under your Linux shell, and see if perhaps there is a sysctl.h file in a different-named subdirectory than /sys?

On my ArchLinux installation, I could not find sysctl.h at all. The reason: [URL="http://sourceware.org/pipermail/glibc-cvs/2020q2/069366.html"]it is discontinued[/URL].

After simply commenting out the #include, it had problems with some file pointer (called fp) which was present in more than one source file, so it could not compile. I had to remove all fprintf's by hand, since the preprocessor directives were not as consequently used as I hoped.

[QUOTE=kruoli;562854]On my ArchLinux installation, I could not find sysctl.h at all. The reason: [URL="http://sourceware.org/pipermail/glibc-cvs/2020q2/069366.html"]it is discontinued[/URL].

After simply commenting out the #include, it had problems with some file pointer (called fp) which was present in more than one source file, so it could not compile. I had to remove all fprintf's by hand, since the preprocessor directives were not as consequently used as I hoped.[/QUOTE]

Thanks, Oliver - would you be so kind as to provide a snippet of the first few errors your mention you got after commenting out the include?

Firstly, I'm on a Raspberry Pi 2 with "Arch Linux ARM".
I think I described my problems a bit weirdly, so let's start from scratch…

The error is:
[CODE]../src/platform.h:1307:12: fatal error: sys/sysctl.h: No such file or directory
1307 | #include <sys/sysctl.h>[/CODE]

As mentioned, I cannot install that file because it is discontinued. So I tried to simply comment out all occurences of it:
[CODE]$ grep -Rn sysctl.h .
./platform.h:1307: #include <sys/sysctl.h>
./platform.h:1664: #include <sys/sysctl.h>
./platform.h:1681: #include <sys/sysctl.h>[/CODE]

So it's only in that file. The last two occurences are in some sort of mail from George which is included as a multiline comment. After commenting out, the error changes (it succeeds in building with [C]gcc -c -O3 -DUSE_SSE2 -DUSE_THREADS ../src/*.c >& build.log[/C], but fails at [C]gcc -o Mlucas *.o -lm -lpthread -lrt[/C]):
[CODE]/usr/bin/ld: Mlucas.o:(.bss+0xd58): multiple definition of `fp'; gcd_lehmer.o:(.bss+0x45c): first defined here[/CODE]

I'm sure that's not because of removing the header. My next step was trying to set [C]#define GCD_DEBUG 0[/C] in the file gcd_lehmer.c (line 45), but that only procuded more errors:
[CODE]gcd_lehmer.c: In function ‘test_gcd’:
gcd_lehmer.c:3333:5: error: ‘gcd_debug’ undeclared (first use in this function); did you mean ‘fft_gcd_debug’?
3333 | if(gcd_debug) {
| ^~~~~~~~~
| fft_gcd_debug
gcd_lehmer.c:3333:5: note: each undeclared identifier is reported only once for each function it appears in[/CODE]

Here, the last line is important. I cannot simply replace the [C]gcd_debug[/C] with [C]0[/C], since it occurs many times, but is only reported once. After that, I commented out or erased every line in gcd_lehmer.c, where the fp variable was used, since it looked like it was only used for debugging purposes and reverted the chance of [C]#define GCD_DEBUG[/C]. Now it built successfully.

Thanks, Oliver - your duplicate-symbol issue following commenting-out the sysctl.h include appears unrelated to said header, so let me take each issue in turn:

1. Digging through my PMs of the past year, I spotted this note from Kriesel, who often does builds of Mlucas or the undocumeted TF-code udner Windows using various kinds of Linux emulation:
[i]
"Missing <sys/sysctl.h> is a fatal error on Windows msys2/mingw64, no such obstacle in WSL/Ubuntu."
[/i]
Donato, suggest you try commenting out the #include <sys/sysctl.h> in platform.h -- just the first 'live' one, not the 2 at bottom of the file in commentary -- and retry your build to see what happens.

I also note that you seem to have mised this note in the Download & Build section of the Mlucas README page:
[i]
[b]Windows (pre-Win10) Users:[/b] Assuming you successfully installed MSYS2 as described above, everything below should work for you, except that the MSYS2/MINGW emulation environment [b]does not support multithreaded builds.[/b] Thus just select the appropriate SIMD vector-mode for your x86 processor using the /proc/cpuinfo-based procedure described below (or none if non-x86), and omit -DUSE_THREADS from your compile statement.
[/i]
That hints strongly that multithreaded builds simply are not possibly under MSYS2, but let's see what your sysctl-commented-out attempt tells us.

2. Re. Oliver's duplicate-symbol linker error: FILE *fp is declared as an extern (global) in Mdata.h and defined in Mlucas.c It is also defined in factor.c, but that is the undocumented-TF-code stuff I mentioned above - factor.c is given a '.txt' extension in releases because it has its own main(), i.e. Mlucas.o and factor.o cannot be linked in the same build. So far, so good. BUT, I see another 'FILE *fp' definition near top - outside of any specific function, i.e. global to the entire file - of gcd_lehmer.c. This is apparently not an issue in my various platforms, because I've never hit kruoli's gcd_lehmer error. But as long as one has either compiled Mlucas.c or factor.c, the definition of that same-named file pointer in gcd_lehmer.c is redundant - comment it out if you hit the duplicate-symbol error, and I will delete it from that file in my v20 development branch.