How can I integrate SCIP with MinGW and Msys?
Whilst you are waiting for a real answer, I can already guide you to this page from the official site on how to build SCIP (see below). For actual integration there is a pointer in the faq:
How do I construct a problem instance in SCIP?
First you have to create a SCIP object via SCIPcreate(), then you
start to build the problem via SCIPcreateProb(). Then you create
variables via SCIPcreateVar() and add them to the problem via
SCIPaddVar(). The same has to be done for the constraints. For
example, if you want to fill in the rows of a general MIP, you have to
call SCIPcreateConsLinear(), SCIPaddConsLinear() and additionally
SCIPreleaseCons() after finishing. If all variables and constraints
are present, you can initiate the solution process via SCIPsolve().
Make sure to also call SCIPreleaseVar() if you do not need the
variable pointer anymore. For an explanation of creating and releasing
objects, please see the doxygen documentation.
NOTE: See the directories "examples/MIPsolver/" and "examples/Queens/" for simple examples
Remarks on Building/Installing under Windows using MinGW (from http://scip.zib.de/doc/html/INSTALL.php)
To build your own Windows binaries under Windows, we recommend using
the MinGW-Compiler with MSYS from mingw.org
First install MSYS, then MinGW to the mingw folder inside the msys
folder. Now you need to install the following packages to the mingw
folder:
- zlib (or use ZLIB=false ZIMPL=false since zlib is needed for ZIMPL and ZIMPL-support in SCIP)
- pcre (or use ZIMPL=false since pcre is needed for ZIMPL and ZIMPL-support in SCIP)
- gmplib (or use ZIMPL=false since gmplib is needed for ZIMPL and ZIMPL-support in SCIP)
(After calling "make clean" in the ZIMPL folder you will also need
flex and bison to remake ZIMPL. We recommend NOT to use "make clean"
inside the ZIMPL-folder if you do not have these packages installed.)
You can download these additional packages as precompiled binaries for
example from: http://gnuwin32.sourceforge.net/packages.html
(zlib&pcre) http://cs.nyu.edu/exact/core/gmp/ (gmplib) or compile the
source on your own from the project homepages: http://www.zlib.net/
http://www.pcre.org/ http://www.gmplib.org/ (The command "./configure
--prefix=/mingw ; make ; make install" should succeed without problems and installs the packages into the mingw folder.)
Now "make READLINE=false" should be compiling without errors. Please
note that we do NOT support creating the doxygen documentation or
readline-usage under Windows.
Since there are no real symlinks in MSYS, the include and library
files of SoPlex and ZIMPL are actually copied into the
SCIP-lib-folder. When you recompile ZIMPL or SoPlex after compiling
SCIP you have to copy the libraries manually into the SCIP-lib-folder
and recompile SCIP afterwards.
Related
I recently downloaded goattracker2 on Windows 10 and after making some changes to the source code, I need to recompile the program to test it.
I don't have any experience with recompiling.
I had a look at the documentation included in the readme-file:
Recompiling
To recompile for Win32, you need the MinGW development environment,
use the file src/makefile.win as makefile.
To recompile for Linux, use src/makefile.
In both cases you need the SDL development libraries in addition to
the SDL runtime, see http://www.libsdl.org.
Compile first the utilities (datafile & dat2inc) from the src/bme
directory, and place them to your path.
This leaves me with several questions, like
Which programs do I need to download
How do I run or execute the makefile
Where do I need to install the SDL libraries
If anyone has experience with recompiling goattracker, can they provide a step by step tutorial for how to do it?
Get MinGW (I recommend 32bit version) and install.
Download and unpack the SDL Libraries from https://www.libsdl.org/ (depending on your version you might need SDL 1.x)
The SDL Libraries (the *.a files) have to be added in the lib directory of MinGW installation directory (this might be different from the lib dir of MinGW, see this issue)
The header files from SDL (SDL2/ directory MinGW) have to be put where MinGW can find them (this might be different from the include dir of MinGW, see this issue)
Go to the src directory of goattracker and type make -f makefile.win
Disclaimer: Please read question carefully, This question has a twist so read it till end.
So JSON-C is one of the highly popular library to work on JSON using C programming. Basic illustration on current work, whatever code building here is for multi-platform. Currently Linux & Windows are supported platform and I have small issue with Windows related JSON-C part.
I'm using Cygwin for Windows development, and when I compile JSON-C code as per provided instruction on it's GitHub page, using CMAKE it works out quite good and build system is able generate DLLs for Windows. But if you have worked with Cygwin then you must know that whatever is built using Cygwin, will have dependency on it's run-time environment (cygwin1.dll) (Why does GCC-Windows depend on cygwin?) and it won't be an independent DLL that can be moved around to different system with same architecture. So with this dependency on Cygwin if my project is built on Windows platform, I have to carry around either Cygwin Run-Time Env. or I have to make sure Cygwin installed on target system for smooth execution. This sort of dependency I do not wish to have for my project, it can ruin user experience.
So what I want as help here, Is there a way to build JSON-C independent of Cygwin (run-time environment)??
NOTE: I already know that, if using Cygwin one wishes to create such an independent DLL for Windows then that can be done using few parameters to compiler and some additional macros placed in-front of function declaration as described here Creating a DLL in GCC or Cygwin?
But I don't see such support in source code JSON-C for Windows. So I was just wondering if JSON-C Dev team has kept some provision via build-system then I'm keen to know that part.
PS: I have not dipped into JSON-C build system yet due to my other development, so if anyone out there (my beloved community) has anything on this then please share, that would be terrific.
EDIT
Forgot to mention the version I'm using :p
json-c-0.13.1-20180305
I am able to build JSON-C 0.14-20200419 (from https://github.com/json-c/json-c) under MSYS2 with MinGW-w64 - both static and shared - using these instructions (replace /usr/local as needed):
INSTALLPREFIX=/usr/local
mkdir -p build_static build_shared &&
cmake.exe -Wno-dev -GNinja -DCMAKE_INSTALL_PREFIX:PATH=$INSTALLPREFIX -DCMAKE_BUILD_TYPE:STRING=Release -DBUILD_SHARED_LIBS:BOOL=OFF -DBUILD_TESTING:BOOL=OFF -S. -Bbuild_static &&
cmake.exe -Wno-dev -GNinja -DCMAKE_INSTALL_PREFIX:PATH=$INSTALLPREFIX -DCMAKE_BUILD_TYPE:STRING=Release -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_TESTING:BOOL=OFF -S. -Bbuild_shared &&
ninja -Cbuild_static install/strip &&
ninja -Cbuild_shared install/strip &&
echo Success
If you don't have ninja you can probably also use -G"MSYS Makefiles" and use make instead of ninja.
Note that MinGW-w64 is different from Cygwin in that it compiles to native Windows binaries without dependancies on a compatibility layer (like Cygwin's cygwin1.dll). The following screenshots illustrates this:
I've been trying this for over 5 days and I have no idea how to get this to work. I had successfully installed boost once, then I got my computer re-imaged and now it's just not happening. I have Windows 7 Enterprise, and 64-bit operating system.
I downloaded boost from here sourceforge
unzipped it into program files.
I then went to the VS 2013 Native Command prompt. Changed directory to boost tools/build
Ran bootstrap.bat
I then ran ./b2 address-model=64
but it did not give me directories for the compiler and the linker like last time.
I then ran ./b2 --prefix=C:\ProgramFiles\boost_1_58_0
but again nothing happens. I get the following errors:
Warning: No Toolsets were configured.
Warning: Configuring default toolset ""msvc"
Warning: If the default is wrong, your build may not work correctly
warning: Use the "toolset=xxxxx" option to overrride out guess
warning: for more configuration please consult
I have no idea why this worked the first time I had done this and why this isn't working now. Can someone please help me out. I know nothing about Unix but I need to install this so I can use the libraries.
I compile boost with both mingw (64 bit) and msvc 2013 pro. I have never in my life used the vs command prompt to build boost with msvc. Here are my commands to build 64 bit binaries on both toolchains.
First go into the boost folder and just double click bootstrap.bat. This should run and build bjam/b2. Nothing special required and doesn't matter what compiler this gets built with.
Then simply run, in a normal command prompt:
bjam.exe -a -j8 --toolset=msvc --layout=system optimization=speed link=shared threading=multi address-model=64 --stagedir=stage\MSVC-X64 release stage
Where -a forces rebuild all, -j8 means for the build to use 8 cores (adjust this based on your processor capabilities), toolset is obvious, layout means how to structure the naming of the output files, address-model is obvious, stagedir is where to output the built binaries (either relative or absolute path) and release stage is the type of build the system. See more here.
Same thing but using 64 bit mingw.
bjam.exe -j8 --toolset=gcc --layout=system optimization=speed link=shared threading=multi address-model=64 --stagedir=stage\x64 release stage
You can even go on to build additional libraries with a second pass tweaking your arguments. For example, after I've built the core libs with the above command, I run the following command to build in zlib and gzip support.
bjam.exe -a -j8 --toolset=msvc --layout=system optimization=speed link=shared threading=multi address-model=64 --stagedir=stage\MSVC-X64 --with-iostreams -s BZIP2_SOURCE=C:\dev\libraries\cpp\bzip2-1.0.6 -s ZLIB_SOURCE=C:\dev\libraries\cpp\zlib-1.2.8 release stage
Anyway that's just as an example. I linked to the full docs for the build system. Try building using these commands NOT inside a vs command prompt. If you still have problems then please post specific errors.
A note about MSVC
So, msvc compiler + boost supports a type of linking where it will automatically include additional libraries that it knows it needs. I believe boost does this by using the #pragma directive in headers. For example you might use boost::asio configured in such a way that it needs boost::system (for error codes and such). Even if you don't explicitly add boost::system library to the linker options, msvc will "figure out" that it needs this library and automatically try to link against it.
Now an issue arises here because you're using layout=system. The libraries are named simply "boost_" + the lib name, like "boost_system.dll". However, unless you specify a preprocessor define, this auto linking will try and link to a name like "boost_system_msvc_mt_1_58.lib". That's not exact as I can't recall the exact name, but you get the idea. You specifically told boost to name your libraries with the system layout (boost_thread, boost_system) etc instead of the default, which includes the boost version, "MT" if multithreaded, the compiler version, and lots of other stuff in the name. So that's why the auto linking feature goes looking for such a crazy weird name and fails. To fix this, add "BOOST_AUTO_LINK_NOMANGLE" in the Preprocessor section of your C++ settings in visual studio.
More on that here. Note that the answer here gives you a different preprocessor definition to solve this problem. I believe I ended up using BOOST_AUTO_LINK_NOMANGLE instead (which ended up working for me) because the ALL_DYN_LINK macro turned out to be designed as an "internal" define that boost controls and sets itself. Not sure as it's been some time since I had this issue, but the define I provide seems to solve the same root issue anyway.
I am trying to compile "xz-5.2.1" in MinGW/MSYS environment. I see the following errors:
#error UINT32_C is not defined and unsigned int is not 32-bit.
error: #error size_t is not 32-bit or 64-bit
I am not familiar with MinGW, could anyone shed some light on this? It looks like some macro definition are missing. Some header file missing?
ADD 1
The commands I used to compile the xz-5.2.1 are:
./configure
./make
The error screenshot:
Some background, I am following this link to compile the Tesseract-OCR library. And this is just one of the steps.
ADD 2
Based on the error message, I checked the sysdefs.h file. It contains the following content:
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
The above make output contains the -DHAVE_CONFIG_H, so I think the system header file <config.h> should be included.
But strange enough, I searched the C:\MinGW\include, there's no such file. So I GUESS this may have caused the undefined UINT_MAX warning at line 57. And then the UINT32_C is not defined error at line 58.
But I don't know why the system header file config.h is missing and where to get it.
ADD 3
I dig a bit about the GNU autotools. And luckily enough I find that the following commands can carry on my build process: (Though I am still not very sure why it works. All I know is that it may be related to portability.)
autoheader (this generates the config.h.in file)
./Configure (this generates the config.h file from the config.h.in file)
And now, my build process is blocked by another issue as below:
It seems this is a known issue. And another thread has addressed it.
(I will continue update with my progress.)
If you care for an easier way to handle this kind of dependency management or a general update on toolchain functionality, I strongly suggest switching to MSYS2 with MinGW-w64.
Both projects aim (and succeed) in bringing a better version of the original. MSYS2 comes with a large number of 3rd party libraries that you can easily install. MinGW-w64 allows for GCC with full C++11/14/... support and extended Windows API availability, along with some useful extensions and more up to date headers. You'll notice that most problems originating from system headers will have already been solved, either by the MinGW-Packages scripts below, or upstream (of either MinGW-w64 or the projects themselves).
For you specifically, I suggest the following steps:
Install and update MSYS2.
Open an MSYS2 command prompt (or the 32-bit or 64-bit command prompts if you plan on building 32-bit or 64-bit things) from the start menu entries. Install {32-bit,64-bit} MinGW-w64 GCC:
pacman -S mingw-w64-{i686,x86_64}-gcc
Install tesseract-OCR:
pacman -S mingw-w64-{i686,x86_64}-tesseract-ocr
and optionally the data files:
pacman -S mingw-w64-tesseract-ocr-osd mingw-w64-{i686,x86_64}-tesseract-ocr-eng
And you're done. Of course, you can still compile the various dependencies yourself, but why bother? If you really want to, you can start from the build scripts for the packages you can install in MSYS2, which are located here:
https://github.com/Alexpux/MINGW-packages
Just open the PKGBUILD files and you can see the build steps required. Note that all these scripts assume the dependencies have been installed within MSYS2.
Also note that the installed packages and compilers are all independent of MSYS2 as you'd expect: you can use it only as a tool to keep your development tree up to date, and build from any other Windows environment.
I am using msys2 Mingw (gcc 4.8.2 for i686 32-bit) for building Ghostscript 9.10. After running make, gs.exe was created successfully. Followed by that I ran "make so" for creating libgs library. Libgs.so, Libgs.so.9.10 were created which are of the same file size. But I found both of them to be PE executables. After renaming extension to .exe, they produced the same output as done by gs.exe. What I require is libgs.dll, libgs.a to be created, but instead "make so" creates libgs.so which is in fact a PE executable. I also tried using patch found on site:https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-ghostscript/mingw-build.patch, but still the output remains the same. Has anyone been successful in this? Kindly help me.
I presume if you follow the steps taken in the build script connected to the patch you linked, everything will work out fine. I think most of it is just to make it use the "system"'s 3rd party libraries instead of those in the GS source. I'd guess running the configure command would do.
Alternatively, you could just download the MSYS2 base system from here, and do a pacman -Syu mingw-w64-i686-ghostscript. It should download and install the binary package without you having to build it yourself.
If you really want to build it yourself, download the PKGBUILD and patch, and run makepkg from the aforementioned MSYS2 shell and have that build it for you.
Have just completed testing of gs 9.15 built executables using the a patch
MINGW-packages-master.zip from https://github.com/Alexpux/MINGW-packages
Without implementing the zlib patch and PKGBUILD and using a MINGW 4.7.3 32/64
without by ghostscript used libs installed.
They did not work as is while using msys1 pathe'd up ahead of Windoze.
I simply edited the the MINGW Build and 32/64 bit type in makefile in
and set them to =1 there. and as i built without GTK defined in ./configure
SOC_LOADER_PLAIN manually to gs.c
Check the makefile after ./configure ahead of make or make so though , , .
All went well except for the COMPILE_INITS
mkromfs build that failed so I had to set that to =0 and build without that
feature. For me personally preferred as one can patch the gs fonts and libs
much easier.
The builds run as charm with full cpu optimisers implemented
only disabling gcse and guess-branch-probability, easily outperforming
the binaries provided by http://www.ghostscript.com/ by all means.
HPC !