It looks like some work has been done to make pthread-win32 work with x64, but there are no build instructions. I have tried simly building with the Visual Studio x64 Cross Tools Command Prompt, but when I try to link to the lib from an x64 application, it can't see any of the function exports. It seems like it is still compiling the lib as x86 or something.
I've even tried adding /MACHINE to the makefile in the appropriate places, but it doesn't help. Has anyone gotten this to work?
You can use the vcpkg here. Which is the Windows package manager for C++.
It supports pthread building and also other open source libraries.
I wanted to use a static pthread library.
When i downloaded the pthread i got the dll(pthread.dll) and import lib(pthread.lib) i.e I can not use only pthread.lib I had to use the pthread.dll file.
So using vcpkg I have built the static lib. Which I can use without any dll dependencies
Using "vcpkg" you can build both Static and Dynamic Libraries
You can use below steps
Below i have added the steps for all DLL (x86|x64) and LIB (x86|x64) cases. You can build it as per your need.
Clone the vcpkg from git directory vcpkg git repo
From the directory where you have cloned vcpkg run below command- Which will install the vcpkg
bootstrap - vcpkg.bat
Check for the library availability by running below commands
vcpkg search pthread
Which will show you below result
mbedtls[pthreads] Multi-threading support
pthread 3.0.0 empty package, linking to other port
pthreads 3.0.0-6 pthreads for windows
As you can see it supports pthread for windows
1 .Building Dynamic Library with import lib (DLL)
Building x86 DLL
vcpkg install pthreads:x86-windows
Which will build the dll and import library in .\vcpkg\installed\x86-windows from
here copy the lib and include and you can use them
Building x64 DLL
vcpkg install pthreads:x64-windows
Which will build the dll and import library in .\vcpkg\installed\x64-windows from
here copy the lib and include folders.
2. Building Static Library (LIB)
Building x86 LIB
vcpkg install pthreads:x86-windows-static
Which will build the dll and import library in .\vcpkg\installed\x86-windows-static
from here copy the lib and include and you can use them
Building x64 LIB
vcpkg install pthreads:x64-windows-static
Which will build the dll and import library in .\vcpkg\installed\x64-windows-static
from here copy the lib and include folders.
NOTE : Try to use with admin privileges
For me, I just use a 64-bit windows compiler (mingw-w64 cross compiler in this particular case) then make (with2.9.1) like:
$ make clean GC-static
Then how I install it for use (some of this may not be needed, of course),
cp libpthreadGC2.a $mingw_w64_x86_64_prefix/lib/libpthread.a
cp pthread.h sched.h semaphore.h $mingw_w64_x86_64_prefix/include
then to use it, you have to define this (example ffmpeg configure line to use it):
--extra-cflags=-DPTW32_STATIC_LIB
Anyhow that's one way.
Another way is to do the same then modify the *.h files and remove all references to dllexport from the headers (or manually define DPTW32_STATIC_LIB in the headers).
ex:
sed 's/ __declspec (dllexport)//g;s/ __declspec (dllimport)//g'
(ref: zeranoe build scripts)
Until it's officially released, it looks like you have to check out the CVS head to get version 2.9 of the library. Version 2.9 has all the x64 patches, but you will still have problems if you try to compile the static library from the command line.
The only workaround I know of is to use the DLLs instead of statically linking the LIB.
Here's how I did it (VS2015). Should work for older Visual Studios too.
1) Download the release .zip from SourceForge
2) Unpack to a clean folder- should see "pthreads.2"
3) Open up your Visual Studio command prompt, navigate to "pthreads.2."
4) Run "nmake", no arguments. It produces a help message listing all the legal commands you can give 'nmake' to build it. For more info, see "pthreads.2\FAQ" file which explains their 3 different flavors of 'cleanup' handling.
I would suggest building "VC" and "VC-debug" (and maybe the static ones of those) only. The 'real' pthreads is a C system library on POSIX platforms like Linux, so only those combos are going to give you the exact same C error behavior on Windows that you'd get on Linux, FreeBSD, etc.
to expand kgriffs answer one has to do two more things to actually build a 64bit DLL and not 32bit DLL.
First download latest pthreads via CVS (as suggested here)
1) use 64bit build tools - achieved by loading correct VC environment settings in command line (more about it here):
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat amd64
(change the 11.0 to whatever version you are using)
2) As it is written in the pthreads Makefile:
TARGET_CPU is an environment variable set by Visual Studio Command Prompt
as provided by the SDK (VS 2010 Express plus SDK 7.1)
PLATFORM is an environment variable that may be set in the VS 2013 Express x64 cross
development environment
which means, that if it was not done by the vcvars (in my case it wasn't) you need to set TARGET_CPU or PLATFORM (just in case I set them both):
set TARGET_CPU=x64
set PLATFORM=x64
3) and now the final step:
nmake clean VC
nmake clean VC-debug
this will make a 64bit DLL files (and proper import library and PDB). I can verify that it works with Visual Studio 2012.
This message might help.
I was successful in replacing "pthread-win32" with "pthreads4w" https://sourceforge.net/projects/pthreads4w/ and compiling in MSVC2019 for x64 target using the console nmake command. Even statically link.
Related
I'm trying to use OpenCV with Dear ImGui in Visual Studio 2022. I'm new to C/C++ libraries and building in general, so I'm unsure if I'm doing anything right. ImGui uses 32-bit architecture and I've used Cmake gui to compile the source code as Win32. I think I have the compiled source code, but it seems to be different than downloading the pre-built libraries. File Explorer Screenshot. I've added the bin to PATH environmental variable, and in Visual Studio tried adding \include to Include Directories, \lib or \lib\Debug to Library Directories, and opencv_world460d.lib to Additional Dependencies. The program still runs, but it doesn't seem to include anything related to OpenCV in the #include files. I found a few .dll files in bin\Debug, but I'm not sure if I should bother with that. I think I could move the source code into the project, but I'm fairly certain that isn't the proper way to do it. Any help would be appreciated.
I needed to run the install target:
You may have built the project, but probably you didn't run the install target. Try running cmake --build <build_dir> --config Release and then cmake --install <build_dir> --config Release, where <build_dir> is a placeholder for the path to the build dir shown in the screenshot. The latter command probably requires admin privileges. Probably best to check the docs of the lib, if there's a step by step instruction for building & installing the whole thing. –
fabian
How can I use libcurl with my project without actually installing it or curl on the system?
I want to make my source-code portable, so that any developer can copy the folder with all sources and other files, run make and compile the program without the need for system level installations.
I am looking for (probably separate) solutions for Linux and for Windows (dll?). If it is possible, provide some standard/official solution and not hack (I'd like to be educated about linking third party libraries)
I've used it on Windows using Visual Studio, all you need to do under Windows:
Download the source
Using CMake generate the project files (when using Visual Studio).
Build the libraries, 3 files will be built: libcurl.lib, libcurl_imp.lib and libcurl.dll
Include curl.h in your project and add the paths to your .lib files
Build your program, put libcurl.dll in the executable folder and it will work.
On Linux it should be a similar process, build the libraries and include them with your source.
You probably want to build a static library out of libcurl and link agains it. Should be pretty straightforward and the process is almost identical on every OS.
I have a c++ codebase that I need to build both windows and unix versions of. It is important that the windows executable work without cygwin or similar installed. Oh, and I'm trying to achieve this from ubuntu.
I've been trying to figure out how to make boost-build take care of it, but have so far come up short.. For simplicity assume this project structure:
root/
|- src/
| |- core/
| | |- number.cpp
| | |- number.hpp
| |- main.cpp
|- jamroot
In an attempt to make boost-build produce windows binaries as a first step, I create a user-config.jam file in my home directory containing the following:
using gcc : 4.4 : i586-mingw32msvc-g++ : <rc>i586-mingw32msvc-windres <archiver>i586-mingw32msvc-ar ;
My jamroot file looks like this:
exe hello :
[ glob-tree *.cpp ]
: : <target-os>windows
;
But when I run bjam I get a unix executable (no extension) but not a windows executable. Renaming the application with a .exe extension and running on windows does not work. I tried various options for bjam, like bjam --toolset=gcc --target-os=windows, bjam --toolset=gcc-mingw --target-os=windows etc. but noting seems to work..
For the record, mingw is properly installed and working.. Calling the compiler manually produces correct output files.
Any ideas?
Also, how do I get bjam to build a version for each toolset listed in my user-config.jam file?
Bonus question:
Eventually, I need to link against one boost library and one custom prebuilt library. How would I go about specifying different libraries for the different target systems?
UPDATE I downloaded the script from http://mingw-cross-env.nongnu.org/ which allowed me to compile a mingw as well as boost libraries in one go, so that problem is taken care of.. I found a way to make bjam call the mingw compiler (I am at a different computer so I cannot provide the solution at this time).. The other questions are still not resolved.
Unfortunately I don't think this can be done (I've failed many times) and I think the reason is because mingw is not suppported for compiling Boost. The only way people seem to have accomplished this is to maintain a separate build environment under win32 using MS Visual Studio.
From your question it's unclear if you're using bjam to build your application, or if you're just trying to build Windows versions of the Boost libraries (.lib or .dll files) to link with your application later. In my attempts I have tried to do this the 'usual' way, in that Windows versions of the Boost libraries are compiled, then the app is compiled separately with mingw32 and linked with Boost.
Unfortunately my stumbling block so far is that I can only get two outcomes - either the build fails when compiling Boost into Win32 dynamic libraries (.dll), or win32 static libraries are successfully built, but then libtool refuses to link them in with the app.
Have a look at the PKGBUILD file that Arch Linux uses to compile mingw32-boost as you might get some hints from how they do it. It seems that bjam threadapi=win32 target-os=windows is enough. Don't forget to set your prefix correctly though, so you don't overwrite your native libraries with win32 versions!
On my ubuntu box, it is as simple as
sudo apt-get install mingw
and then build
export CC=i586-mingw32msvc-gcc
make
Profit!
I have only previously used visual studio for developing c++ but I've just moved to netbeans and am having some issues.
I got mingw installed so that my projects will compile but I dont know how to add external libraries to that. I want to use a static library, not a dll.
The library I specifically am looking at is libpng
I hope this isn't too IDE specific, I'm also looking to know how to prepare the library.
Windows OS.
I figured it out more or less. I used the cmake gui, configured for msys make and mingw g++ and gcc, on the zlib source directory and then ran msys make and make install on the output directory. After that I did the same on libpng, but I had to add some variables to point to the zlib include and library directories within cmake.
Then in netbeans, I right clicked>>properties on my project and added include and lib location for each of the two libraries. I also could have copied the files into my mingw directories.
Now I'm just stuck with this issue.
I tried to write code that was a sample of the Boost test library:
#include <boost/unit_test.hpp>
BOOST_AUTO_TEST_CASE(test)
{
BOOST_CHECK(true);
}
I built the source code, and I got the execution file test.exe. I tried to execute that file, but I got an error message.
The program can't start because boost_unit_test_framework-vc80-mt-1_44.dll is missing from your computer. Try reinstalling the program to fix this problem.
But, I have ready that file on my boost library directory.
What's the problem in this case?
Background:
For my build environment, I use Windows 7 Ultimate x64, and Visual Studio 2005.
So I built boost library by my self, and I got all the libraries for the 64-bit computing system.
Using bjam, and I use the command: bjam --toolset=mvsc-8.0 address-model=64 threading=multi --build-system=complete install on 64-bit command prompt window.
After the build, I set the boost library and header directory in Visual Studio directory path option.
Thank you all!
Make sure that the path to your DLL is included in the "PATH" environment variable. (Or include the DLL in your exe directory if you like). That way the DLL will be found.
You can also choose to use the static versions of the Boost libraries.
Build or download the static libraries and point Visual Studio at those instead. The Boost code will be built into your application (increasing its size some) and you will not need a DLL.
If using CMake to configure your application, you can tell CMake to use the static versions of the Boost libraries using Boost_USE_STATIC_LIBS:
set(Boost_USE_STATIC_LIBS ON)
find_package(Boost ... )
This way, the DLLs will not be required, as the requisite Boost definitions will be built into your application via the static libraries.