Pigz Windows Download
Audie Reints
The C99 standard specifies the j specifier for printf(). (Note that the 99 refers to 1999. It is now 2018.) You can force the pigz compilation to not assume C99 by changing __STDC_VERSION__-0 >= 199901L __GNUC__-0 >= 3 to 0. Then it won't try to use j.
To follow up on comments above that I had with @varro and matzeri, I can now answer my own question: my suspicion was correct: RTools was the culprit. I found that if I temporarily removed all RTools elements from my Windows Path env var (for me: c:\Rtools\bin and c:\Rtools\mingw_32\bin), then I was able to get pigz make to work.
After doing this Path edit, I uninstalled my existing cygwin, reinstalled cygwin, installed my usual extra packages (chere, openssh, subversion, zip, unzip) and all their dependencies, installed make and all its dependencies, installed gcc-core (is the C compiler) and all its dependencies. At that point, I was able to make pigz perfectly.
There is a much easier way than compiling yourself. I had the same problem, and with a little bit of research found multiple ready-made .exe files (pigz.exe) for direct usage in Windows. I am using this one:
The OP's main concern was: "I would like to use pigz to compress massive tar archives.", and I hope that this is a useful answer to that concern, although it does not explain how to get around the compiling problems.
The interesting thing that some folks may not be aware of is that nothing keeps us from using normal Windows binaries from within Cygwin, and vice versa. That is, even if the OP had sophisticated Cygwin / bash (or whatever) scripts which drive pigz and the whole process of compressing, he could use the ready-made pigz native Windows version linked above.
Personally, I am using the native Windows pigz version from within Cygwin since a while. AFAIK, pigz has no progress bar, which is somehow inconvenient for me (from time to time I have to compress a single huge file (around 60 GB)). A convenient way to get around this is the pv utility. Since I haven't found a native Windows version of it, and since I am too lazy to compile it for Windows myself, I am using Cygwin's pv to display the progress when I let the native Windows pigz compress those huge files.
With the p switch, you can limit pigz to only use a specific number of processors/cores. This will leave the rest of the cores free for your other tasks and interactivity. To do so, add the number of processors/cores right after the switch:
I just now got word of these multithreaded ports and would like to know if theres anyway to replace their single threaded brethren? pigz is already in AUR and it wouldn't take much to put pbzip2 into it either.
You're using pigz as a drop-in replacement of gzip. If pigz behaves same as gzip i.e. 'pigz --foo' does the same as 'gzip --foo', everything's fine, but when the apps interpret options in a different way or the new app has some mandatory options you could skip with the previous one - things will break.
I would very much like to see the packages for pbzip2 and pigz marked with provide/conflict/replace bzip2/gzip, and provide symlinks to where bzip2/gzip live. Is there any reason not to do this? I would think that most (if not all) people installing pbzip2/pigz would want to always use the parallel versions, so replacing the 'original' bzip2 and gzip would not be an issue. It would require some effort to do (for example, all the shell scripts, /usr/bin/bzdiff, etc), and a bit of testing (it appears that /bin/bzcat, and /bin/zcat, which are symbolic links, still work properly with the parallel versions).
So, if you have a contemporary multi-processor, multi-core machine and want to compress larger files as quickly as possible while utilizing all of your CPU cores, pigz is an excellent option! Give it a shot and let us know what you think of the Pigz compression application in the comments below.
Used these roads :
Staying on Linux
1) Lutris (wine bottle manager - with Directx to Vulkan API translation support) many games works even faster ..
2) Windows with cygwin on VmWare Player
3) Windows on qemu kvm with and without gpu passthrough --> virtual gpu and gpu passtrough so that you can open it on a windows with spice or connect it via reminna (RDP) or any vnc (teamviewer etc)
3.b) There is also LookingGlass in github for using accelerated passedthrough hw in windowed mode
4) Docker on both ... Works very good since first quarter of 2019
5) I connected some mainboards via pci-e and configured device lending so share cpu and gpu dynamically with some kernel virtual machines and trying communicate two system at very low level these days to use some microservices....They call it elastic cloud or something. I just want to make a giant machine with Linux windows and osx dynamically using hw as needed ...
Best Solution in my opinion:
1) Keep your machine dual boot with 2 seperate hard drivers and keep a mac vm or a real mac laptop which can also triple boot all 3 os ... and take regular backups with dd pigz and cp with cloud drives and use gits...
I meant it did not supported file watcher and also it was highly recommended to not modify the files under the linux mounts in WSL with windows processes (IDE), which beats the purpose of WSL for a dev.
If it didn't work for you I have no interest in trying to convert you but I've had nothing but success developing using WSL for the past few years. It's true that you shouldn't access anything under WSL "/" from windows but I'm able to work exclusively out of the Windows space (/mnt/c) for everything. I can read and write those files from Windows VScode, etc. and from my Linux utilities running in WSL. And you can create symlinks in WSL-land to conveniently access My Documents, Downloads, etc. in Windows. Obviously your success will depend on the kind of work you're doing but for my needs I'm 100% satisfied with WSL
df19127ead