I installed Go 1.6.2 on Windows but in my bin directory I now have only 3 files:
go.exe
godoc.exe
gofmt.exe
I wonder if that's normal or my installation didn't go quite well.
That's normal. If you're looking for all the other executables (like linker, compiler etc.), check the:
%GOROOT%/pkg/tool/windows_amd64
(or similar) folders. These are not placed in the bin folder because you don't need to call these (they are called by the go.exe tool). bin contains only the tools you interact with, and is recommended to add %GOROOT%/bin to your PATH.
For example in my pkg/tool/windows_amd64 folder I have the following additional binaries:
addr2line.exe
api.exe
asm.exe
compile.exe
cover.exe
dist.exe
doc.exe
fix.exe
link.exe
nm.exe
objdump.exe
pack.exe
pprof.exe
tour.exe
trace.exe
vet.exe
yacc.exe
Related
I've just installed Golang on my machine, and I set up GOPATH.
But when I navigate to my go/src I see that src folder contains ./sourcegraph.com, ./golang.org and ./github.com. Also GOPATH/bin and GOPATH/pkg also no empty.
So I have several questions:
1) I know how to use ./github.com folder for pushing my code to github, but why it contains , from box, some other not mine projects inside such as acroca, cweil ... and other ? Can I clear this folder?
2) What I should do with golang.org folder, can I remove it ?
3) What I should do with sourcegraph.com folder, can I remove it ?
4) Can I clear bin and pkg from preinstalled binaries and packages?
I think you not only installed the Golang but also install/configure Visual Studio Code IDE with Go Extension. Those alien repositories were created when the extension installs needed tools. The full list of tools can be found here. Or probably other similar IDE/extension which depends on those tools.
Yes you can clear the sources, since the IDE depends only on the compiled binary, and the sources are only needed during compilation.
Same as (1). Refers to Golang SubRepositories
Same as (1)
For now, you can clear the content of pkg directory but don't remove the directory. In the future, when you install some packages/libraries, the compiled version may be created under the directories, so don't remove it. For bin directory, don't remove the files inside it, because the IDE (Go Extension) depends on them.
But, since I don't know exactly what else you've done, I think before you completely remove them, try just to move them outside your GOPATH or take a backup and see whether your dev environment works as expected.
I have 2 questions regarding NGINX:
Is there any one who had already compile NGINX with Visual Studio? I want create a VS9 Project for compiling NGINX.
It's my veritable need, is there any way to compile NGINX as Lib or DLL?
I just finished building a Visual Studio 2010 project for nginx. The process wasn't entirely straight-forward, so I will attempt to detail everything I've learned. This is a several-hour to several day process, depending on your experience.
Step 1: You must first follow the Guide for building nginx on windows. This not only builds nginx, but also creates .c and .h files that you will use when creating your Visual Studio project. It won't work without these files. (For more information, see here.)
If you are less experienced with Unix like me, the guide above leaves some unanswered questions. So I'll first flesh out that guide with tips of my own, and then later, tell you more about creating a project for Visual Studio.
Part I: Compiling nginx for windows using MSYS
First, follow all the steps given above. Install MSYS, Strawberry Perl, Mercurial, and download the PCRE, zlib, and OpenSSL libraries. Then follow these steps:
1) Open a command prompt As Administrator. Then run your Visual Studio vc\vcvarsall.bat file to set
your environment variables to use VC as the compiler. Your paths will be different, but the command I used was:
"C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
I found that even though the Strawberry Perl added 3 paths (which you can verify by examining your PATH variable), it still was using the wrong Perl.
2) Launch MSys by running msys.bat. For me, MSys was installed inside of the MinGW directory, so my path was:
C:\MinGW\msys\1.0\msys.bat
If successful, you should see something like this in green:
JensenV#AVWMA047LB ~
(except with your username#networkaddress instead) in a window called something like MINGW32:~
You might be wondering where your 'home folder is. It's under msys\1.0\home. So on my system, it's here:
C:\MinGW\msys\1.0\home\JensenV
If you do "ls" or "dir" this is the directory you're in initially.
3) Assuming you installed Mercurial as instructed above, you should now be able to check out ngynx source:
hg clone http://hg.nginx.org/nginx
This will go into the directory mentioned above.
4) You need to make sure the version of perl being used is strawberry perl, NOT the version that comes with msys. Type:
which perl
If you get something like "/bin/perl.exe" that's the wrong perl and you need to fixing your paths. You can either mess with this (as I did, unsuccessfully) OR you can just disable the version of perl that comes with msys. I just renamed
perl.exe to perl_UNUSED.exe in my msys install:
C:\MinGW\msys\1.0\bin
Whatever you do, make sure "which perl" shows the path to Strawberry Perl before proceeding.
5) Also renamed "link.exe" in my msys\1.0\bin directory:
C:\MinGW\msys\1.0\bin
so that it's unused. (i.e. rename it to "link_UNUSED.exe")
I believe this is because, in Step 1 above, your "vcvarsall.bat" set everything to use Microsoft C's compiler/linker, but then in Step 2, the linker was changed to use the Msys one instead. You need to use the Microsoft one.
To verify renaming as "link_UNUSED.exe" was successful, type:
which link
and ensure it points to your Visual Studio 10 link, not the link.exe that came with msys.
6) First "cd nginx" then create an objs/lib folder tree inside of the nginx folder. Untar/unzip pcre, zlib, and openssl in here as mentioned in the guide.
7) While your current directory is still nginx, run nginx's autoconfigure script, but first modify the command below to change the paths for
sopenssl, pcre, and zlib to be correct for what you installed in objs/lib (your version numbers may be different). The command I used was:
auto/configure --with-cc=cl --builddir=objs --prefix= \
--conf-path=conf/nginx.conf --pid-path=logs/nginx.pid \
--http-log-path=logs/access.log --error-log-path=logs/error.log \
--sbin-path=nginx.exe --http-client-body-temp-path=temp/client_body_temp \
--http-proxy-temp-path=temp/proxy_temp \
--http-fastcgi-temp-path=temp/fastcgi_temp \
--with-cc-opt=-DFD_SETSIZE=1024 \
--with-pcre=objs/lib/pcre-8.33 \
--with-zlib=objs/lib/zlib-1.2.8 \
--with-openssl=objs/lib/openssl-1.0.1f \
--with-select_module --with-http_ssl_module --with-ipv6
If you want to change any configuration options, NOW IS THE TIME. These options affect the generated .c and .h files that you will use later in creating your Visual Studio project, and trust me, you don't want to have to redo that later when you realize you need different options.
7) Make it.
nmake -f objs/Makefile
If successful, your freshly compiled nginx.exe should be inside your home\YourUsername\nginx\objs folder. i.e. something like:
C:\MinGW\msys\1.0\home\JensenV\nginx\objs
In addition, these files will now be in the same folder as nginx.exe:
ngx_auto_config.h
ngx_auto_headers.h
ngx_modules.c
ngx_pch.c
You will use these in creating your Visual Studio project.
8) Have a beer.
**
Part II: Creating the Visual Studio nginx Project
**
Create an empty Visual Studio project for Command Line application. Save the project inside your nginx folder (root level). Note that before this step you can move your nginx folder outside of msys to wherever you want to keep it.
1) Go to Properties -> VC++ Directories and add these Include Directories:
$(MSBuildProjectDirectory)\src\core
$(MSBuildProjectDirectory)\src\event
$(MSBuildProjectDirectory)\src\event\modules
$(MSBuildProjectDirectory)\src\http
$(MSBuildProjectDirectory)\src\http\modules
$(MSBuildProjectDirectory)\src\http\modules\perl
$(MSBuildProjectDirectory)\src\mail
$(MSBuildProjectDirectory)\src\misc
$(MSBuildProjectDirectory)\src\mysql
$(MSBuildProjectDirectory)\src\os
$(MSBuildProjectDirectory)\objs
$(MSBuildProjectDirectory)\src\os\win32
$(MSBuildProjectDirectory)\objs\lib\openssl\ssl\include
$(MSBuildProjectDirectory)\objs\lib\zlib
$(MSBuildProjectDirectory)\objs\lib\pcre
NOTE: Before this step I went into objs/lib and removed the version numbers from the zlib, pcre, and ssl folders. Either you should do this to, OR you should modify the paths above to match your installed versions. I removed the version numbers so that I can update to newer versions of these libraries in the future without breaking my project.
Click on the "Macros >>" button and verify that the MSBuildProjectDirectory path is a path to your nginx folder.
2) Likewise add these paths to your Library Directories:
$(MSBuildProjectDirectory)\objs\lib\openssl\ssl\lib\
$(MSBuildProjectDirectory)\objs\lib\pcre\
$(MSBuildProjectDirectory)\objs\lib\zlib\
Again, modify these paths to include version numbers if your objs/lib folder's contents still have version numbers.
3) Change these Project Properties as follows:
C/C++
General: Set "Treat warnings as errors" to No (WX-)
Preprocessor: Add these Preprocessor Definitions:
WIN32
NGX_WIN32
NGX_MAIL_SSL
NO_SYS_TYPES_H
FD_SETSIZE=1024
Linker:
Input: Add the following to Additional Dependencies:
ws2_32.lib
pcre.lib
ssleay32.lib
libeay32.lib
crypt32.lib
zlib.lib
4) Close your Visual Studio solution. Open up the project file (ends in .vcxproj) with a good text editor, such as Notepad++. (Make a backup copy of it first, in case anything goes wrong.) Also open up nginx\objs\makefile with a text editor.
In the makefile, not too far from the top, you'll see a section that starts something like this:
objs/nginx.exe: objs/src/core/nginx.obj \
objs/src/core/ngx_log.obj \
objs/src/core/ngx_palloc.obj \
objs/src/core/ngx_array.obj \
....
objs/ngx_modules.obj \
objs/nginx.res \
objs/lib/pcre-8.33/pcre.lib \
objs/lib/zlib-1.2.8/zlib.lib
$(LINK) #<<
Likewise, in the Visual Studio file, if you've added any source code (add any files you want prior to this step, so you can see what I'm talking about) you'll see something like this:
Create a new document containing just the .obj files from the makefile. Use Search & Replace in a text editor to modify them to match the format of the Visual Studio project file instead (so ending in .c /> instead of with .obj \, and starting with
Also don't forget to change the forward slashes to backslashes. Don't include the zlib.lib or pcre.lib lines. I forget if you should include nginx.res. (Probably not.)
Once you're sure the format is right, save your Visual Studio project and try opening it. If all the files from the makefile show up in your project, you did it correctly.
5) Remember those special .c and .h files that nginx created when you built the exe? You want to add them to your project now, too. Add these guys:
ngx_modules.c
ngx_pch.c
6) Now you're ready to compile!
I've honestly probably forgotten something along the way, so you might still have some linker or compile errors to fix, but this should give you a good start!
NOTE: If you want to change which options are included in nginx, you'll have to do a new auto/configure in Part I above, a new nmake, and then include additional source code in you Visual Studio project, and use the newly generated ngx_modules.c and ngx_pch.c files in your Visual Studio project.
I've successfully built a demo app using opencv on windows with the MSYS shell environment.
I did NOT use the prebuilt opencv installer, I downloaded and compiled the source locally (this is the recommended method).
After building opencv and running make install, all the files are happily in:
/e/deps/libopencv/build/install/
I can successfully build a sample application against this using cmake directives along the lines of:
find_package(OPENCV REQUIRED)
link_directory(${OpenCV_LIB_DIR})
include_directories(${OpenCV_INCLUDE_DIRS})
target_link_libraries(target ${OpenCV_LIBS})
To be completely clear here: building the binary is successful.
Now, when I run it from the shell I get the message:
The program can't start because libopencv_core231.dll is missing from your computer.
Try reinstalling the program to fix this problem.
So... I know where the libraries are:
$ ls /e/deps/libopencv/build/install/lib/
libopencv_calib3d231.dll.a libopencv_features2d231.dll.a libopencv_highgui231.dll.a libopencv_ml231.dll.a libopencv_video231.dll.a
libopencv_contrib231.dll.a libopencv_flann231.dll.a libopencv_imgproc231.dll.a libopencv_objdetect231.dll.a
libopencv_core231.dll.a libopencv_gpu231.dll.a libopencv_legacy231.dll.a libopencv_ts231.a
What now?
I guess I could try to make cmake build a static binary, but that seems pretty extreme.
How can I somehow make either 1) windows, or 2) the MSYS environment happy. Something like LD_LIBRARY_PATH on windows?
Or is this not the problem, and I've actually (despite appearances) somehow messed up the way the binary was compiled?
Edit:
NB. For whatever reason it seems that my libraries are .dll.a files, not .dlls (see the ls result) if that's remotely relevant.
windows searches the same directory as the exe, any directory in the %PATH% (Windows) or $PATH (msys) directories, as well as a few special ones in the windows folder
You could add /e/deps/libopencv/build/install/lib to your $PATH. I am not sure if this will work for msys, you may need to add E:\deps\libopencv\build\install\lib to %PATH% in windows instead.
The typical solution for this if you are giving the program to others is to include a copy of the DLL in the same directory as the EXE. you can get this same effect by making a symbolic link to it with the command
ln -s /e/deps/libopencv/build/install/lib/libopencv_core231.dll libopencv_core231.dll
while in the /e/deps/libopencv/build/install/ directory
I can't find any information on how to install Qt built on Windows.
In wiki article How to set up shadow builds on Mac and Linux there's description of -prefix option in configure script but this option is not available on Windows.
I know I can use Qt right from the build folder but it does not seem the right thing not to perform an install step. One problem with this approach is size; Qt's build folder takes about 4GB space whereas after installing using binary installer Qt takes about 1GB space. I guess the difference is due to temporary files created during building. I hope some install procedure would install (copy) only needed files leaving temporary files in the build folder.
As İsmail said there's no install step for Qt on Windows.
However one can try to approximate it by performing the following operations.
Cleaning
Run make clean in the build folder to remove all temporary files.
Moving
Copy build folder to the place where you want Qt "installed". Let's call it INSTALL_DIR.
Fixing paths hardcoded in the qmake.exe executable
Run qmake -query to see what paths are compiled (hardcoded) into qmake and
a. Fix paths containing the build folder by replacing it with the INSTALL_DIR using qmake -set (1).
or
b. Create a qt.conf file in the bin subfolder of the INSTALL_DIR specifing new Qt paths inside it.
Adding current directory to include path
In Qt's provided binary distributions, the pwd is included in the QMAKE_INCDIR and thus ends up in your projects include path as ".". This does not happen by default in a custom built Qt, so you have to add the following line to mkspecs/YOUR-PLATFORM-HERE/qmake.conf file:
QMAKE_INCDIR += "."
Fixing prl files
When you add a Qt component to a project file (such as CONFIG += uitools), Qt looks in %QTDIR%/lib/QtUiTools.prl to find the library dependencies of that component. These files will have the hard coded path of the directory in which Qt was configured and built. You have to replace that build directory with the one to which you moved Qt for all lib/*.prl files.
Making source available
If you made a shadow build (build made inside folder other than the one containg sources), headers in the include subfolder only forward to the original headers. For example; BUILD_DIR\include\QtCore\qabstractanimation.h looks like this
#include "SRC_DIR/src/corelib/animation/qabstractanimation.h"
If you don't want to depend on the existence of the folder containg sources you have to copy SRC_DIR/src subfolder to your destination folder and fix all headers in the include folder so that they forward to the new location of src subfolder.
The bottom line:
The build process of Qt under Windows makes it really akward to move (install) Qt after building. You should do this only if ... well I can't find any good reason to go through all this trouble.
Remember
The easy way is to place Qt's sources in the folder where you want Qt to stay after building and make a build in this folder. This makes all steps but 1 and 4 above unnecessary.
1)
The variables you set with qmake -set are saved in the registry key
HKEY_CURRENT_USER\Software\Trolltech\QMake\<QMAKE_VERSION>.
Because of this you might have a problem when you would like to have different projects using different versions of Qt which happen to have the same version of qmake. In this case the better solution is to use qt.conf file (actually files as you need one file for each Qt installation) (option 3b).
Many of the information above come from the RelocationTricks wiki page authored by Gabe Rudy. Check out his Qt (Qt4) Opensource Windows Installers of Pre-built Binaries with MSVC 2008 project which gives you easy solution of above problems.
This answer is a replacement for steps 3 and 5 of Piotr's (currently top rated) answer above, but you may still need the other steps in his answer, depending what you're trying to achieve.
This is the operation which the official installer uses to fix the hardcoded paths during the installation: qt.520.win32_msvc2012.addons/meta/installscript.qs
This is how the operation is implemented: qtpatchoperation.cpp
This is the list of files that it fixes: files-to-patch-windows-qt5
And this shows how to invoke an installer operation as a standalone command from the commandline: Operations (Qt Installer Framework Manual)
To summarize: after moving your Qt directory to where you want it, download any one of the official Qt installers and run it with the following commandline arguments:
cd <path>
installer.exe --runoperation QtPatch windows <path> qt5
Replace <path> with the full path of your Qt directory after you moved it (the qtbase directory if you are using Qt 5). Omit the final qt5 argument if you are using Qt 4.
This will fix the hardcoded paths in qmake.exe, .prl files, and others. It gives you the exact same behaviour that the official installers have in that respect.
For the initial move, nmake "INSTALL_ROOT=\somewhere" install works for me. So that's steps 1 and 2 of Piotr's answer covered. And I haven't needed steps 4 or 6, FWIW.
I can configure QT 5 on WINDOWS (Visual Studio build) with the prefix option like:
configure -prefix C:\the\path\I\want ...
then call:
nmake
nmake install
and the latter will install Qt in C:\the\path\I\want.
I did it without problems with Qt 5.2.1 and 5.3.x, so far. So, any earlier problems seem to be fixed by now.
It's very odd people claim that there is no "make install" on Windows.
I have used it many times, and I agree that it's not what it is on other platforms, but it serves its purpose.
How I use Qt's make install on Windows (from cmd):
configure
(n/mingw32-)make
(n/mingw32-)make docs
(n/mingw32-)make install
The make install bit copies all necessary headers to be able to delete your source directory. Delete all objects and unecessary stuff:
del /S /Q *.obj lib\*.dll
rmdir /S /Q docs-build qmake tools src
This allows you to remove the source directory. I don't know what impact this has on debugging Qt source code, but it sure reduces the size of a shadow build. I use it to maintain 32 and 64 bit builds with minimal size.
Qt on Windows is not installable with make install, you will notice that Qt installer for Windows just patches dlls & pdbs for the new install location.
What I would suggest is to do a shadow build in the place you would like to install it. You can manually remove *.obj files to save up space.
Qt's own build instructions show how this is done, by search/replace within each Makefile. Assuming the source was extracted to C:\qt-4.8.3 and build was performed within that directory, then do this:
fart -c -i -r Makefile* $(INSTALL_ROOT)\qt-4.8.3 $(INSTALL_ROOT)\my-install-dir
set INSTALL_ROOT=
mingw32-make install
Then create a config file that tells qmake about its new installation path. Create a textfile C:\my-install-dir\bin\qt.conf:
[Paths]
Prefix=C:/my-install-dir
Translations = translations
Then as a final step (as Randy kindly pointed out) you need to patch qmake.exe, which can be done using a simple utility called QtMove. This same tool also automatically updates all the prl files.
Step 1: Move Qt
Cut and Paste
Current directory - C:\tools\Qt
Destination directory -C:\sim\dep\Qt
Step 2: Get Old Qt Directory
Go to C:\sim\dep\Qt\2010.02.1\Qt
Open .qmake.cache
Find variable QT_SOURCE_TREE
Note the value of QT_SOURCE_TREE
Mine was C:\tools\Qt\2010.02.1\Qt
Step 3: Patch Qt
Go to C:\sim\dep\Qt\2010.02.1\bin
The syntax is qpatch.exe list oldDir newDir
qpatch.exe files-to-patch-windows C:\tools\Qt\2010.02.1\Qt C:\sim\dep\Qt\2010.02.1\Qt
Step 4: Set Environment Variables
set QTDIR=C:\sim\dep\Qt\2010.02.1\Qt
set QMAKESPEC=C:\sim\dep\Qt\2010.02.1\Qt\mkspecs\win32-g++
set PATH=%path%;C:\sim\dep\Qt\2010.02.1\Qt\bin
set PATH=%path%;C:\sim\dep\Qt\2010.02.1\bin
You can do all of this with a batch file. This took me a fair while to work out and it has saved me a lot of time since. It's a script to automatically update a Qt installation to new locations. The batch file is available here.
There is a simple utility QtMove (http://www.runfastsoft.com) can do this easily.
Runs the relocated qmake.exe build your .pro file and everything should be linked with new Qt libs.
I am trying to do it, but all I can get is some source code that I don't know how to do deal with I downloaded from http://pkgconfig.freedesktop.org/releases/.
This is a step-by-step procedure to get pkg-config working on Windows, based on my experience, using the info from Oliver Zendel's comment.
I assume here that MinGW was installed to C:\MinGW. There were multiple versions of the packages available, and in each case I just downloaded the latest version.
go to http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/
download the file pkg-config_0.26-1_win32.zip
extract the file bin/pkg-config.exe to C:\MinGW\bin
download the file gettext-runtime_0.18.1.1-2_win32.zip
extract the file bin/intl.dll to C:\MinGW\bin
go to http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.28
download the file glib_2.28.8-1_win32.zip
extract the file bin/libglib-2.0-0.dll to C:\MinGW\bin
Now CMake will be able to use pkg-config if it is configured to use MinGW.
Get the precompiled binaries from http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/
Download pkg-config and its depend libraries :
pkg-config_0.26-1_win32.zip
glib_2.28.8-1_win32.zip
gettext-runtime_0.18.1.1-2_win32.zip
A alternative without glib dependency is pkg-config-lite.
Extract pkg-config.exe from the archive and put it in your path.
Nowdays this package is available using chocolatey, then it could be installed with
choco install pkgconfiglite
I did this by installing Cygwin64 from this link https://www.cygwin.com/
Then - View Full, Search gcc and scroll down to find pkg-config.
Click on icon to select latest version.
This worked for me well.
I would like to extend the answer of #dzintars about the Cygwin version of pkg-config in that focus how should one use it properly with CMake, because I see various comments about CMake in this topic.
I have experienced many troubles with CMake + Cygwin's pkg-config and I want to share my experience how to avoid them.
1. The symlink C:/Cygwin64/bin/pkg-config -> pkgconf.exe does not work in Windows console.
It is not a native Windows .lnk symlink and it won't be callable in Windows console cmd.exe even if you add ".;" to your %PATHEXT% (see https://www.mail-archive.com/cygwin#cygwin.com/msg104088.html).
It won't work from CMake, because CMake calls pkg-config with the method execute_process() (FindPkgConfig.cmake) which opens a new cmd.exe.
Solution: Add -DPKG_CONFIG_EXECUTABLE=C:/Cygwin64/bin/pkgconf.exe to the CMake command line (or set it in CMakeLists.txt).
2. Cygwin's pkg-config recognizes only Cygwin paths in PKG_CONFIG_PATH (no Windows paths).
For example, on my system the .pc files are located in C:\Cygwin64\usr\x86_64-w64-mingw32\sys-root\mingw\lib\pkgconfig. The following three paths are valid, but only path C works in PKG_CONFIG_PATH:
A) c:/Cygwin64/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig -
does not work.
B) /c/cygdrive/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig -
does not work.
C) /usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig - works.
Solution: add .pc files location always as a Cygwin path into PKG_CONFIG_PATH.
3) CMake converts forward slashes to backslashes in PKG_CONFIG_PATH on Cygwin.
It happens due to the bug https://gitlab.kitware.com/cmake/cmake/-/issues/21629. It prevents using the workaround described in [2].
Solution: manually update the function _pkg_set_path_internal() in the file C:/Program Files/CMake/share/cmake-3.x/Modules/FindPkgConfig.cmake. Comment/remove the line:
file(TO_NATIVE_PATH "${_pkgconfig_path}" _pkgconfig_path)
4) CMAKE_PREFIX_PATH, CMAKE_FRAMEWORK_PATH, CMAKE_APPBUNDLE_PATH have no effect on pkg-config in Cygwin.
Reason: the bug https://gitlab.kitware.com/cmake/cmake/-/issues/21775.
Solution: Use only PKG_CONFIG_PATH as an environment variable if you run CMake builds on Cygwin. Forget about CMAKE_PREFIX_PATH, CMAKE_FRAMEWORK_PATH, CMAKE_APPBUNDLE_PATH.
Install mingw64 from https://sourceforge.net/projects/mingw-w64/. Avoid program files/(x86) folder for installation. Ex. c:/mingw-w64
Download pkg-config__win64.zip from here
Extract above zip file and copy paste all the files from pkg-config/bin folder to mingw-w64. In my case its 'C:\mingw-w64\i686-8.1.0-posix-dwarf-rt_v6-rev0\mingw32\bin'
Now set path = C:\mingw-w64\i686-8.1.0-posix-dwarf-rt_v6-rev0\mingw32\bin
taddaaa you are done.
If you find any security issue then follow steps as well
Search for windows defender security center in system
Navigate to apps & browser control> Exploit protection settings> Program setting> Click on '+add program customize'
Select add program by name
Enter program name: pkgconf.exe
OK
Now check all the settings and set it all the settings to off and apply.
Thats DONE!
Another place where you can get more updated binaries can be found at Fedora Build System site. Direct link to mingw-pkg-config package is: http://koji.fedoraproject.org/koji/buildinfo?buildID=354619
for w64-based computers you have to install mingw64. If pkg-config.exe is missing then, you can refer to http://ftp.acc.umu.se/pub/gnome/binaries/win64/dependencies/
Unzip and copy/merge pkg-config.exe into your C:\mingw-w64 installation, eg. into on my pc into C:\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin
In 2022 VS Code works with CMake & pkgconfig out of the box (add pkgconf && vcpkg-pkgconfig-get-modules to your vcpkg.json)
From: https://github.com/JoinMarket-Org/joinmarket/wiki/Installing-JoinMarket-on-Windows
This guide describes how to install JoinMarket and its dependencies (python, libsodium, secp256k1) on Windows.
Some or all of this may or may not work for all versions of Windows. Reports appreciated. It is not claimed to be in any way comprehensive. Verification of downloads are your own responsibility.
Install JoinMarket - go to https://github.com/JoinMarket-Org/joinmarket/releases and download the most recent release. Unzip it into any location you choose.
You will need to install MinGW from here or go to their website. After a few introductory screens, you will be shown a windows with some optional components that you have to choose; this basic setup is sufficient:
From "Basic Setup" in the left menu:
mingw-developer-toolkit
mingw32-base
mingw32-gcc-g++
msys-base
Once you have chosen these, choose "Update" from the main menu first item. These components will be installed into C:\MinGW\bin. Once that is complete, you should have this dll: libgcc_s_dw2-1.dll in that folder C:\MinGW\bin, along with a lot of other files; I'm mentioning this file explicitly, since it's needed specifically for libsecp256k1 to operate in this setup.
Next, you must make sure C:\MinGW\bin is added to your PATH variable. Here's one guide to how to do that; you must append ;C:\MinGW\bin to the end of the path before continuing.
Install Python from https://www.python.org/ftp/python/2.7.11/python-2.7.11.msi. Run the executable. Choose to install the feature Add python.exe to Path (it's the last option in the installer, off by default - switch it on) on local hard drive during installation; Python should then be installed in C:\Python27 (EXTRA NOTE: the most recent 2.7 installation linked here seems to install pip automatically, which is very useful for step 4)
Check that Python runs. Open a new command prompt as administrator by typing cmd.exe into the Start menu and pressing Ctrl+Shift+Enter. Type python and you should see something like:
Python 2.7.11 (default....
....
>>>
Exit the Python console with exit() or by pressing Ctrl+C. Now, make sure your version of pip is up to date: run the command: python -m pip install --upgrade pip.
Go to the directory C:\Python27\Lib\distutils and add a new file, called distutils.cfg. Inside it, put:
[build]
compiler=mingw32
Close and save the file.
Next, you need to install the dll for libnacl. First go to https://download.libsodium.org/libsodium/releases/ and choose the file libsodium-1.0.4-msvc.zip to download. Unzip anywhere, and then copy the file libsodium.dll from the directory \Win32\Release\v120\dynamic (do not use v140), and paste it into root joinmarket directory (the same directory where README.md lives). Then you need to address the Visual C++ 2013 runtime dependency. Do so by going to www.microsoft.com/en-us/download/details.aspx?id=40784 and clicking Download. Choose x86 even on a 64-bit system, and run the executable.
Note that after doing this, you must run pip install -r requirements-windows.txt from the Joinmarket root directory (where the README.md file is) and should not get an error message (this will install/check the python packages libnacl and secp256k1(-transient)).