Need Win7 install CD
 

I need to test whether the standard linux-style install of the soon-to-be-released Mlucas v17 works under at least one popular free Linux emulator. I have a vintage 2008 Core2Duo Lenovo Thinkpad with a 32-bit Winstall on it which I no longer use, so it seems it could serve nicely as a testbed for this, needing only a 64-bit Win install to replace the Win32 one. Retaining any of the data on the HD is not required. I prefer to stay miles away from any of the newer Win releases, with their ever-greater levels of auto-update insanity and such. Win7 seems like a decent stable legacy version. Security against hackerzzz not really an issue since I do not intend to let the machine anywhere near the Internet except perhaps for some very brief tests of the python script I use for primenet assignments management - just install needed stuff from a thumb drive and do my testing.

Anyone willing to part with a spare Win7 install CD around here? (If there's a better way to do this, let me know.)

Any suggestions re. a freeware linux emulator also welcome - here are the desiderata:

o Support for GCC configure/make and reasonably recent versions of GCC (I'd like to be able to compile AVX/AVX2/AVX-512-mode binaries even if I can't run anything beyond SSE2 on the machine in question, obviously).
o Support for multithreaded builds using pthreads (and preferably also standard core-affinity-setting protocols).
o Support for networking, for the aforementioned quicktests of primenet-via-.py-script.

I have an unused syringe of Coollaboratory LiquidPro thermal compound by way of something to trade, if that helps incentives-wise.

If you have a Win7 product key, you should be able to download an ISO from directly Microsoft:
[SIZE=2]
[/SIZE][B][URL="https://www.microsoft.com/en-us/software-download/windows7"][SIZE=2]Download Windows 7 Disc Images (ISO Files)[/SIZE][/URL][/B]

[QUOTE=EdH;460179]If you have a Win7 product key, you should be able to download an ISO from directly Microsoft:
[SIZE=2]
[/SIZE][B][URL="https://www.microsoft.com/en-us/software-download/windows7"][SIZE=2]Download Windows 7 Disc Images (ISO Files)[/SIZE][/URL][/B][/QUOTE]

Thanks, but I've never owned a Win7 install in any form.

Don't you get 30 days of nag screens on a new install before it locks down?

[QUOTE=kladner;460185]Don't you get 30 days of nag screens on a new install before it locks down?[/QUOTE]

The first thing I see at the above-linked Win7 download page is a request for a 25-digit product key. My Lenovo (WinXP) has a sticker with that on bottom, but alas the sticker is torn and the last 10 chars are missing. When I look at ControlPanel -> System, I see a 20-digit product key including the string 'OEM', but none of that matches the 15 chars on the partial sticker. No idea what may have happened to the original MSFT media discs that came with the laptop - been almost 10 years, may well have tossed 'em.

[QUOTE=ewmayer;460187]The first thing I see at the above-linked Win7 download page is a request for a 25-digit product key. My Lenovo (WinXP) has a sticker with that on bottom, but alas the sticker is torn and the last 10 chars are missing. When I look at ControlPanel -> System, I see a 20-digit product key including the string 'OEM', but none of that matches the 15 chars on the partial sticker. No idea what may have happened to the original MSFT media discs that came with the laptop - been almost 10 years, may well have tossed 'em.[/QUOTE]

Are you saying that the Lenovo was originally XP but is now Win7 7 32-bit? I would expect the product key to not match the sticker then.
The 20 digit code you are seeing is the product id not the product key.
You can get the key from the registry. Unfortunately it is in hex. [url]http://www.nirsoft.net/utils/product_cd_key_viewer.html[/url] does it for you. This even works to get a win 10 key after a free upgrade.

[QUOTE=henryzz;460191]Are you saying that the Lenovo was originally XP but is now Win7 7 32-bit? I would expect the product key to not match the sticker then.
The 20 digit code you are seeing is the product id not the product key.
You can get the key from the registry. Unfortunately it is in hex. [url]http://www.nirsoft.net/utils/product_cd_key_viewer.html[/url] does it for you. This even works to get a win 10 key after a free upgrade.[/QUOTE]

Lenovo was and remains original 32-bit XP install. I did some further digging using Search -> product registration, and turns out the 20-char ...-OEM-... string is the format MSFT used for XP - so that's what I'd need to download a copy of XP, not that MSFT still supports it. Not sure what the partial number on the little sticker on bottom of the unit is for.

Time to have a gander at Win7 4sale on eBay - dang, most are surprisingly pricy, and all the sellers were savvy enough to mask off the 25-digit product code in their item photos.

[spoiler]Well, OK, *most* of the sellers were. :P[/spoiler]

From memory the Windows 7 download page from Microsoft only works on retail keys, not OEM. If OEM, they refer you to the system builder for support. If you know anyone with a retail Win7 key, it could be used to download the ISO. Of course, if already used it can't be used for the install.

As much as there is hate for it, for testing purposes Win10 is easy to obtain from MS. You can get the install media creator for free without needing any codes. You can also run it unactivated with only some minor limitations (activation watermark on screen, can't change some user customisation settings). I find this handy to have a throw-away install for testing things. The caution I'd have on an older machine is that Win10 is more disk intensive than ever, and if you don't have a SSD, it will hurt.

If you don't care about security, you can disable the Windows Update service and it wont restart. I have to use this workaround myself, and only manually enable it once a month after 2nd Tuesday of each month when they release routine security updates.

[QUOTE=ewmayer;460192]Lenovo was and remains original 32-bit XP install. I did some further digging using Search -> product registration, and turns out the 20-char ...-OEM-... string is the format MSFT used for XP - so that's what I'd need to download a copy of XP, not that MSFT still supports it. Not sure what the partial number on the little sticker on bottom of the unit is for.

Time to have a gander at Win7 4sale on eBay - dang, most are surprisingly pricy, and all the sellers were savvy enough to mask off the 25-digit product code in their item photos.

[spoiler]Well, OK, *most* of the sellers were. :P[/spoiler][/QUOTE]

How about a [URL="http://www.ebay.co.uk/itm/Microsoft-Windows-7-Professional-32-64bit-Genuine-License-Key-Product-Code-/272692262714?hash=item3f7db9b73a:g:6Z0AAOSwZKBZLDBl"]licence key for $4 ?[/URL]

[QUOTE=Gordon;460238]How about a [URL="http://www.ebay.co.uk/itm/Microsoft-Windows-7-Professional-32-64bit-Genuine-License-Key-Product-Code-/272692262714?hash=item3f7db9b73a:g:6Z0AAOSwZKBZLDBl"]licence key for $4 ?[/URL][/QUOTE]

As it turns out, ran into my roomie - a longtime AMD+Win guy - on our ways out this a.m., he says he's pretty certain he still has a set of Win7 install media, just needs to find them in his Hoarders!-style junkpile. Failing that, I'll be happy to take you up on your kind offer, which would allow me to use a downloaded .iso, once I do all the [url=http://softlay.net/operating-system/create-windows-7-bootable-usb-install-disk-drive-iso.html]associated create-a-bootable-USB[/url] fvckery.

With a "retail" Windows 7 ISO file you can "evaluate" the install, without a key, for 30 days.

This can be extended for up to a year with a cool little trick.

We have posted about this before.

If you desire help with this, just let us know.

:mike:

[QUOTE=ewmayer;460268]…which would allow me to use a downloaded .iso, once I do all the [URL="http://softlay.net/operating-system/create-windows-7-bootable-usb-install-disk-drive-iso.html"]associated create-a-bootable-USB[/URL] fvckery.[/QUOTE][url]https://www.microsoft.com/en-us/download/windows-usb-dvd-download-tool[/url]

First step was a Thinkpad mem-upgrade from the original 512MB to the Win7-minimum 2GB - turns out I had all I needed at home already. The ddr2 dimms are same standard kind as in my vintage macbook, so looked thru the 3 defunct macbooks in my e-cycle box, found one of them still had a pair of 1GB dimms. Got Win7 install DVD + license code from housemate, OS upgrade - or more accurately, clean install - underway.

Win7 install complete - on to the posix/gcc/pthreads support layer - first 2 options that spring to mind are [url=mingw-w64.org]mingw-w64[/url] and [url=cygwin.com]cygwin[/url], but been years since I used the older mingw64, and never used cygwin. Any suggestions to help me make my choice are welcome.

This is an easy way to create bootable USB drives for almost any OS:
[url]https://rufus.akeo.ie/[/url]

[QUOTE=ewmayer;460322]Win7 install complete - on to the posix/gcc/pthreads support layer - first 2 options that spring to mind are [url=mingw-w64.org]mingw-w64[/url] and [url=cygwin.com]cygwin[/url], but been years since I used the older mingw64, and never used cygwin. Any suggestions to help me make my choice are welcome.[/QUOTE]

I would recommend avoiding cygwin. When you compile in that environment, you (generally) add a dependency to all of your executabels that require cygwin.dll in order to run. You can use an msys shell to compile with mingw64 and not have any such additional dependency. I wrote up a post a while back describing how I compile GMP and GMP-ECM. It tells where I got msys and mingw64, and how I switched between different versions of the mingw64 compiler, ie by editing the \etc\profile file. I just checked the links and they are all still relevant. Mingw64 has gcc versions from 4.8.1 up to 7.1.0. Hopefully this will be helpful for you, too.

[url]http://www.mersenneforum.org/showpost.php?p=431359[/url]

Which is post 416 of this thread:
[url]http://www.mersenneforum.org/showthread.php?t=4087&page=38[/url]

[QUOTE=Gordon;460238]How about a [URL="http://www.ebay.co.uk/itm/Microsoft-Windows-7-Professional-32-64bit-Genuine-License-Key-Product-Code-/272692262714?hash=item3f7db9b73a:g:6Z0AAOSwZKBZLDBl"]licence key for $4 ?[/URL][/QUOTE]

I may need such a key after all - my Win7 install was fine but I did not attempt to register it because it turns out that while my housemate is running Win10, that is via upgrade-install from his Win7, i.e. based on the same license key. (That is as he described it.)

Q: The eBay item is for Win7Pro - will that also cover Win7 Home Edition (which is what I installed)?

----------------------

WraithX, thanks for the notes and links - I need to first finish upgrading the basic linux auto-config setup to work with the v17 codebase and test in under genuine linux, then I will move on to the mingw64-based setup under Win7, will post updates as they warrant it.

[QUOTE=ewmayer;460462]I may need such a key after all - my Win7 install was fine but I did not attempt to register it because it turns out that while my housemate is running Win10, that is via upgrade-install from his Win7, i.e. based on the same license key. (That is as he described it.)

Q: The eBay item is for Win7Pro - will that also cover Win7 Home Edition (which is what I installed)?

----------------------

WraithX, thanks for the notes and links - I need to first finish upgrading the basic linux auto-config setup to work with the v17 codebase and test in under genuine linux, then I will move on to the mingw64-based setup under Win7, will post updates as they warrant it.[/QUOTE]
I don't think the pro key will cover it as such although you may be able to upgrade an inactivated version of windows using the key. The inbuilt way to upgrade windows is "Windows anytime upgrade" for windows 7. Hopefully that will accept your pro key and do what you want.

[QUOTE=henryzz;460556]I don't think the pro key will cover it as such although you may be able to upgrade an inactivated version of windows using the key. The inbuilt way to upgrade windows is "Windows anytime upgrade" for windows 7. Hopefully that will accept your pro key and do what you want.[/QUOTE]

Think for now I'll just do what I need to do in terms of testing the Mlucas v17 release build under Win64, then bug Mike/Xyzzy to share his "you can extend the 30-day trial up to a year" sekrit trick with me.

-------------------------------------

[QUOTE=WraithX;460334]I would recommend avoiding cygwin. When you compile in that environment, you (generally) add a dependency to all of your executabels that require cygwin.dll in order to run. You can use an msys shell to compile with mingw64 and not have any such additional dependency. I wrote up a post a while back describing how I compile GMP and GMP-ECM. It tells where I got msys and mingw64, and how I switched between different versions of the mingw64 compiler, ie by editing the \etc\profile file. I just checked the links and they are all still relevant. Mingw64 has gcc versions from 4.8.1 up to 7.1.0. Hopefully this will be helpful for you, too.

[url]http://www.mersenneforum.org/showpost.php?p=431359[/url]

Which is post 416 of this thread:
[url]http://www.mersenneforum.org/showthread.php?t=4087&page=38[/url][/QUOTE]

OK, I downloaded this:

MinGW-W64 GCC-7.1.0 / x86_64-posix-seh

also the 7zip package for Win, installed the latter and used it to unpack the former, as well as the xzipped tarball of my code. gcc -v shows what appears to be a properly configured gcc setup, but test-compilation (without even enabling multithreading in the target code) gives this error dialog:
[i]
cc1.exe - System Error
The program can't start because libwinpthread-1.dll is missing from your computer. Try reinstalling the program to fix this problem.
[/i]
Is there some mingw64-configuration step I need to do after unpacking the package, or some set of runtime libs I need to download separately?

Note I have no MSFT-build-tools installation, nor do I want to require potential Mlucas-on-Win users to have such. I want to keep the number-of-things-you-need-to-download-and-unzip-and/or-install to an absolute minimum - we're already up to 3 items [Mlucas tarball, mingw64 tarball, 7zip auto-installer.]

[b]Edit:[/b] I downloaded a copy of the above pthread dll from [url=http://dllyes.com/libwinpthread-1-dll/]here[/url], followed the copy-dll-to-both-\Windows\System32-and-\Windows\SysWOW64 instructions, rebooted system, retried simple single-file compile, now get error dialog with
[i]
cc1.exe - Application Error
The application was unable to start correctly (0xc000007b). Click OK to close the application [/i]

[QUOTE=ewmayer;460600]Think for now I'll just do what I need to do in terms of testing the Mlucas v17 release build under Win64, then bug Mike/Xyzzy to share his "you can extend the 30-day trial up to a year" sekrit trick with me.

-------------------------------------



OK, I downloaded this:

MinGW-W64 GCC-7.1.0 / x86_64-posix-seh

[b]Edit:[/b] I downloaded a copy of the above pthread dll from [url=http://dllyes.com/libwinpthread-1-dll/]here[/url], followed the copy-dll-to-both-\Windows\System32-and-\Windows\SysWOW64 instructions, rebooted system, retried simple single-file compile, now get error dialog with
[i]
cc1.exe - Application Error
The application was unable to start correctly (0xc000007b). Click OK to close the application [/i][/QUOTE]

Hmmm, does your mingw64 download have the following file: c:/path/to/mingw64/bin/libwinpthread-1.dll
That should be included with your mingw64 download. Also, when you edit the profile file for msys, you are including the mingw64/bin folder as part of the path. Then, once you've saved your changes to the profile file, you can open an msys shell and do all of your compiling inside of the msys shell. What does your path inside msys look like? You can check with [c]echo $PATH[/c]

Once compiled, you will only need your executable and (if necessary) the pthread.dll to run your code on another computer.

[QUOTE=ewmayer;460600]…then bug Mike/Xyzzy to share his "you can extend the 30-day trial up to a year" sekrit trick with me.[/QUOTE][URL]https://www.techsgig.com/extend-windows-7-trial-period-up-to-one-year/[/URL]

:mike:

You can also try running Msys2 as a no-worries unix development layer on windows. It also comes with the pacman package manager, so keeping it up to date is pretty easy.

After fighting mingw64 for years it was refreshingly easy to switch to this.

Anyone from UK, is this site trustful? I can buy [url]http://www.techee.co.uk/windows-7-professional-64-bit-oem[/url] and send across the product key.

[QUOTE=WraithX;460637]Hmmm, does your mingw64 download have the following file: c:/path/to/mingw64/bin/libwinpthread-1.dll
That should be included with your mingw64 download. Also, when you edit the profile file for msys, you are including the mingw64/bin folder as part of the path. Then, once you've saved your changes to the profile file, you can open an msys shell and do all of your compiling inside of the msys shell. What does your path inside msys look like? You can check with [c]echo $PATH[/c]

Once compiled, you will only need your executable and (if necessary) the pthread.dll to run your code on another computer.[/QUOTE]

I see what is probably the issue - I incorrectly assumed that msys was something needed specifically for the gmp-ecm build under Win - my RTFM bad. Will install that, double-check the rest of the guidelines, and update this post with the results.

[b]Edit:[/b] OK, same version of msys as described in WraithX's [url=]gmp-ecm post[/url] installed in my C: drive. Only difference is that since I just have a single version of each of mingw64 and msys installed, I used the simpler path here:

export PATH=".:/c/mingw64/bin:/usr/local/bin:/bin:$PATH"

Now, is there something besides attempting to compile a .c source file I should do to make sure both msys and mingw64 installs are copacetic and playing nice with each other? And should I be doing my gcc compilation from within an msys or a mingw64 shell?

[QUOTE=pinhodecarlos;460678]Anyone from UK, is this site trustful? I can buy [URL]http://www.techee.co.uk/windows-7-professional-64-bit-oem[/URL] and send across the product key.[/QUOTE]
Don't know about that site, but you can buy a key from Amazon for less, [URL]https://www.amazon.co.uk/dp/B01FDOW0YG/ref=wl_it_dp_o_pd_nS_ttl?_encoding=UTF8&colid=1IP0K5R3HCPMJ&coliid=I3I0M0YEXQL66G[/URL]

[QUOTE=ewmayer;460691]export PATH=".:/c/mingw64/bin:/usr/local/bin:/bin:$PATH"

Now, is there something besides attempting to compile a .c source file I should do to make sure both msys and mingw64 installs are copacetic and playing nice with each other? And should I be doing my gcc compilation from within an msys or a mingw64 shell?[/QUOTE]

Once the msys profile file is setup correctly, then you should be good to go.

One note about the difference between the two packages. Mingw64 is just the compiler toolchain, it provides things like gcc, g++, ar, as, ld, etc. Msys is the linux like environment, it provides things like grep, gunzip, make, autoconf, sed, awk, cat, head, tail, etc. So, to answer your last question, you'll compile everything inside an msys shell, as there is no mingw64 shell.

[QUOTE=WraithX;460718]Once the msys profile file is setup correctly, then you should be good to go.

One note about the difference between the two packages. Mingw64 is just the compiler toolchain, it provides things like gcc, g++, ar, as, ld, etc. Msys is the linux like environment, it provides things like grep, gunzip, make, autoconf, sed, awk, cat, head, tail, etc. So, to answer your last question, you'll compile everything inside an msys shell, as there is no mingw64 shell.[/QUOTE]

Yep - before checking into the m-forum for first time today just now, I composed this offline:

In answer to own question, opened an MSYS terminal last night ... ah, Linux, I'd hardly left you and still I missed you so. Then did 'which gcc', that correctly pointed to c:\mingw\bin\gcc.exe (may have the slashes wrong-way, I'm typing this from memory on my macbook), and trial-compilation of a small file worked, in the sense that I need to modify my platform-related preprocessing code to allow Win builds and make gcc-or-compatible-compiler (e.g. clang) the only gating requirement.

Will be especially interested to see if all the multithreading and core-affinity stuff works in this emulation environment.

Thanks for the tips, WraithX et al!

Unthreaded 64-bit SSE2 build looks good - I just had a gander at the mingw32 predefine list and then used defined(__MINGW32__) to override the 'is windows?' preprocessing section in favor of yes-it's-linux, but it appears that pthreaded build is gonna be more of a challenge - get multiple missing-include-file errors during preprocessing, e.g. files like these are not in the various mingw32 include-dirs:

#include <sys/resource.h>
#include <sys/sysctl.h>
#include <linux/unistd.h>
#include <asm/unistd.h>

Has any of the readership done pthreaded code building under msys/mingw32?

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-libtool
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=ATH;460789]It is really easy to use MSYS2: Download the msys2-x86_64 package and install: [url]http://www.msys2.org/[/url][/QUOTE]

Thanks! All is installed - for now I just grabbed gcc and python3, since I don't use config/make for my Mlucas builds - maintenance effort not worth it, as I set things up so 1-line-to-compile, 1-line-to-link is all one needs [check-build-log-for-errors is intervening step].

But even after restarting msys2 after those installs, 'which gcc' comes up empty - but I do see gcc inside the /c/msys64/mingw64/bin folder, and [path to that] -v shows it's version 6.3.0. Is there a path file somewhere which I need to edit?

Also, doing [path-to-gcc] -c of a small sample C file returns (sans errors) almost immediately, but I see no resulting object file.

Yes, sorry. It is a while since I installed it from scratch, so I forgot I edited the path line:
c:\msys64\etc\profile

Changed the line:
MSYS2_PATH="/usr/local/bin:/usr/bin:/bin"

to

MSYS2_PATH="/usr/local/bin:/usr/bin:/bin:/mingw64/bin"

I did a reinstall now of my MSYS2 just to make sure there was nothing else I forgot. There was one more thing:

If you install "make" at a later stage, the file is called "mingw32-make.exe" for some reason in the folder "C:\msys64\mingw64\bin". So you just need to make a copy of the file and call it "make.exe" otherwise it does not work for GMPECM at least.

[QUOTE=ATH;460859]Yes, sorry. It is a while since I installed it from scratch, so I forgot I edited the path line:
c:\msys64\etc\profile

Changed the line:
MSYS2_PATH="/usr/local/bin:/usr/bin:/bin"

to

MSYS2_PATH="/usr/local/bin:/usr/bin:/bin:/mingw64/bin"[/QUOTE]

Looks good - I just needed to close and restart msys2 for the change to take effect. I suppose one could save one of the multiple close/reopen steps by combining one of the install-packages steps with the above manual path-edit one.

As with the separate msys+mingw method, though, no pthread support - looks like users will be limited to unthreaded mode.

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.