I'm working with Qt 4.8.3 and QtCreator, which I've compiled with msvc2010 as per the instructions here. Now however I need to link to GSL (Gnu Scientific Library), but currently I only know how to build it with g++ which produces linker errors just as described here, undoubtedly for the reason given in the answer by #EvanTeran. However, in my case, building Qt with g++ via cygwin is probably not an option--I've just come off a multi-day nightmare during which I tried to do just this, but could not, as recorded here. Surely there is a way to build gsl with msvc2010, but how? I have VS 2012 Express installed (though I've never used it before) in case there's a solution using it.
EDIT: Looking at CMake, it seems the best I can to is to manually create an entire hierarchy of CMakeLists.txt files for GSL. That's just a little too much so instead I've put a 100pt. bounty on the question mentioned above. Solving my problem the Visual Studio route (here) OR with g++ will get the bounty and the answer to both questions.
Update: The answer below worked great, but not seamlessly, possibly because I actually needed to compile under VS2012. A few tweaks to the code were required, such as explicit casts, which were tolerated under the previous compiler apparently but not mine. Otherwise things proceeded pretty smoothly.
I have implemented CMake build support for GSL here: https://github.com/ampl/gsl
CMake can either generate a Visual Studio solution or NMake makefiles. For example:
> git clone git://github.com/ampl/gsl.git
> cd gsl
> cmake .
-- Building for: Visual Studio 10
-- Check for working C compiler using: Visual Studio 10
-- Check for working C compiler using: Visual Studio 10 -- works
...
This generates the solution (GSL.sln) and project files for Visual Studio 2010.
This CMake build script is now included in the contrib directory of the GSL Git repository git://git.savannah.gnu.org/gsl.git.
As of May 2014, building shared libraries (DLLs) is supported as well with GSL_SHARED option.
You can use CMake and create your own build from this repository for whatever Visual Studio version you are using. Check out the answer by #vitaut for more details.
Related
I decided to give the built-in CMake support in VS2017 a try, and instead of figuring out why our multi-library, multi-executable project has problems with find_package in the hand-crafted CMakeLists.txt files that it has used for years, I decided to try a simple project first, the FooBar example from the CMake wiki: https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
This project creates a shared library foo and an executable bar that links to this library, and is about as simple as they come. I unzipped the project, opened it with File->Open->Folder, the CMake configuration starts and succeeds. Fist thing I notice is that there's no more Build menu, no F7 shortcut to build my project, but instead, I have to select CMake->Build CMakeLists.txt :-( The Debug menu is similarly stunted, and quick debugging is why I use Visual Studio in the first place. This is already looking bad, but it gets worse:
The build fails with this output:
foo.vcxproj -> C:\Users\Enno\AppData\Local\CMakeBuild\639e9ecd-8891-eb38-b26b-ce84aa448eea\build\x86-Debug\foo\Debug\foo.dll
C:\Users\Enno\AppData\Local\CMakeBuild\639e9ecd-8891-eb38-b26b-ce84aa448eea\build\x86-Debug\bar\LINK : fatal error LNK1104: cannot open file '..\foo\Debug\foo.lib'
Thoughts:
The build directory is in %APPDATA%? That's going to be annoying.
There is indeed no .lib file in that location, just the .dll.
At this point I was becoming skeptical that this may not be a problem with VS2017, but maybe with the sample project itself, or with CMake. So I created a solution for VS2015 with cmake.exe -G "Visual Studio 14" ., which I opened in VS2015 and Voila! I got the same error message.
Is there a CMake genius on SO that can tell me what is wrong with this project?
Turns out: The example on the CMake wiki is not portable in the first place, so this has nothing to do with Visual Studio's built-in CMake support. It does not take into account that Windows needs export libraries for DLLs. Adding the correct __declspec(dllexport) incantations to foo.h resolves the error message.
I found all the information that I needed about shared libraries on Windows at this link:
http://gernotklingler.com/blog/creating-using-shared-libraries-different-compilers-different-operating-systems/
I'm using visual studio 2012 and C++ and I'm tying to build a fully static executable of my program. It uses OpenCV 2.4.6 and I wish to be able to run it on a machine without any OpenCV (or even the standard c++ library) installed. I tried to follow every guide on the argument but i couldn't get around it, so here I am.
Thanks for any input!
dont have 2.4.6 but should be exactly the same
build opencv with BUILD_SHARED_LIBS off
set vs2012->project properties->c/c++->code generation->runtime library->multi-threaded(/MT)
set linker input to following
opencv_core245.lib
opencv_contrib245.lib
opencv_features2d245.lib
opencv_objdetect245.lib
opencv_nonfree245.lib
opencv_highgui245.lib
opencv_flann245.lib
opencv_imgproc245.lib
opencv_video245.lib
opencv_legacy245.lib
opencv_gpu245.lib
opencv_ml245.lib
IlmImf.lib
libjasper.lib
libpng.lib
libtiff.lib
libjpeg.lib
zlib.lib
Vfw32.Lib
comctl32.lib
I am open to either a Visual Studio answer or a MinGW answer. I just finished building LLVM 3.2 using CMake and Visual Studio 2010. Everything went smoothly, but I have no llvm-config. Do I need it? Every example I see on the intertubes makes use of that tool. If I don't need it, how do I configure my project to make use of LLVM?
To be clear, I am not trying to use LLVM tools/compilers (like clang and whatnot). I am trying to write C++ code that uses the LLVM libraries to produce LLVM IR and even compile that stuff. I setup my include and lib folders. I ran llvm-config in Linux and saw a long list of macros and libraries.
I have a wonderful folder full of goodies. It just has no llvm-config in there: C:\Program Files (x86)\LLVM\
llvm-config does not exist in windows prebuilt binaries. You need to compile from the source code to get it.
Grab CMAKE > 3.5 , install it and make sure you add it to PATH.
Download Visual Studio 2019
Donwload the source code (9.0.1 is the latest as I'm writing this)
Extract the source code
Cd into the root of the llvm source-code
In cmd, type cmake . this will generate Visual Studio 2019 sln.
open sln file(LLVM.sln), change the build type to Rlease, build the whole project
navigate to your Rlease\bin, and there you have your llvm-config.exe
If you have built the LLVM in debug version all the executables (including llvm-config) have been placed in your build directory (containing Visual Studio project and solution files) in bin/Debug/ subdirectory. In case of release build replace Debug with Release.
If you are interested in using LLVM on Windows more than building it, check out Windows snapshot builds.
tcl8.6.0 doesn't compile in VS11 with the makefile.vc provided by tcl.
I just had to deinstall VS11 and reinstall VC10 (visual studio 2010).
The README file in the "win" folder notes that Visual Studio 6.0 or newer should work,
but it seems the readme file is not up to date.
It seems that MS breaks the needed functionality with every release.
For python the situation seems to be the same:
http://mail.python.org/pipermail/python-dev/2012-July/121122.html
Any solution without the makefile doesn't make sense, as the tcl extensions wouldn't compile.
Can someone confirm that it is impossible to compile tcl8.6 with VS11? (using the provided makefile.vc?)
--
(I would strongly advice against using VC11 at the moment, it's just a huge waste of time.)
not sure what problems you have compiling, as you did not mention it.
But just using:
cd win
nmake -f makefile.vc
just worked for me, in the usual VC 2012 (Express for Desktop) command prompt on Windows 8 Pro.
The tests mostly run, just some link, http and timing relevant tests fail.
I want to build GhostScript 9.04 for Win32 and I have read the documentation to do so which details creating your own makefile project.
I was just curious about the "ghostscript.vcproj" I'm finding in the top level directory. If I convert this to VS2010, I seem to get a good build out of it.
Is there any reason not to use this "ghostscript.vcproj"? The build commandline seems to have some extra stuff in it than what is detailed in the documentation, so I was worried that it might be making some kind of specialized build. See below
nmake -f psi\msvc32.mak SBR=1 DEVSTUDIO= && nmake -f psi\msvc32.mak DEVSTUDIO= bsc
You can use the solutions supplied, they are fine and its what we use. If you would rather use nmake and the makefiles then that's fine too, the solutions simply use the makefiles so its sort of the same, just more convenient in some ways if you are using Visual Studio.
The 'extra stuff' is in there to support the visual studio source browser, basically to improve the experience when using Visual Studio, its not essential.
I'll see about updating the documentation in make.htm.
Sorry to bump a very old topic, but when attempting to compile GhostScript v.9.14.1 with Visual Studio 2015, I get these errors:
Error U1034 syntax error : separator missing lib.mak (line 51)
Error MSB3073 The command "nmake -f psi\msvc32.mak SBR=1 DEVSTUDIO= debug && nmake -f psi\msvc32.mak DEVSTUDIO= debugbsc" exited with code 2. ghostscript C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.MakeFile.Targets
Here's the code at line 51 in lib.mak:
GLLCMS2CC=$(CC_SHARED) $(GCFLAGS) $(I_)$(GLI_) $(II)$(LCMS2SRCDIR)$(D)include$(_I) $(GLF_)
Is there any way to remedy this?
Thank you.
PS: Does this project build the DLL? Could we build the DLL ourselves?