I am using cygwin to run SCIP under Windows. However, when I use make to run the installation, cygwin reports
"fmemopen" was not declared in this scope
tmpStream = fmemopen(tmpString, 63, "w");
I think the problem arised when I tried to install packages for ZLIB within the cygwin package manager, but I am not sure how I can handle with that error?
Apparently, for some reason the flags _WIN32 or _WIN64 is not set when using cygwin. You can do that manually be adjusting the corresponding sub-makefiles make.cygwin.x86.gnu or make.cygwin.x86_64.gnu in soplex-2.2.1/make/:
Simply add -D_WIN32 or -D_WIN64, respectively, in the first line, extending the CPPFLAGS parameter.
You might also try compiling without the rational solving capabilities of SoPlex by running make LEGACY=true.
Related
I tried cabal install GLUT which gave the following:
Setup: Missing dependency on a foreign library:
* Missing C library: glut32
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
So I thought, ok, lets get the sources and point cabal to the directories. I first tried freeglut and then the following
cabal install GLUT --extra-include-dirs="<path to freeglut>\include"
--extra-lib-dirs="<path to freeglut>\src"
Same thing, so I thought maybe it doesn't work with freeglut, and got glut:
cabal install GLUT --extra-include-dirs="<path to glut>\include"
--extra-lib-dirs="<path to glut>\lib"
When this doesn't work, I try to download the source and cabal install inside the directory, then runghc Setup configure. Then thinking that there is some parse error of the paths, I try every possible way of writing a file path known to man; quotes, no quotes, backslashes, double backslashes, forward slashes, and every combination of the above. I even placed all the files on my PATH in hopes it would find them. All other options exhausted, I proceeded to sacrifice a goat to satan, but still no dice.
The question is, what do I have to do to convince ghc to find this library? (this is windows 7)
You need to make the libglut32.a import library accessible to the compiler (see this answer for information about what import libraries are). Just copy it under $GHCDIR/mingw/lib. Alternatively, try the Haskell Platform installer, which ships with a pre-compiled version of the GLUT bindings.
I am trying to cabal install a component of wxHaskell (Haskell platform 2013.2 against wxWidgets 3.0).
I was able to compile the git version with 32 bit mingw from mingw.org. But in the end, the installed wx cannot function correct, and running a minimal example gives runtime exceptions in wxc.dll. So I try to compile the same thing under TDM-GCC 4.8.1 64bit, since the wxWidgets people provide their binary in the form of TDM-GCC compiled binaries.
But I immediately run into compilation errors with TDM-GCC, telling me
error: 'strnlen' was not declared in this scope
What surprises me is that even though both mingw32 and TDM-gcc uses the same external gcc from Haskell Platform c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe, one would give an error while the other compiles fine.
The first file causing problem is src\cpp\eljaccelerator.cpp. It compiles OK under mingw32:
...
c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe -Wl,--hash-size=31 -Wl,--reduce-
memory-overheads -Isrc/include -IC:/MinGW/msys/1.0/local/include/wx-3.0 -IC:/Min
GW/msys/1.0/local/lib/wx/include/msw-unicode-3.0 -D__WXMSW__ -DWXUSINGDLL -D_LAR
GEFILE_SOURCE=unknown -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\eljaccelerato
r.cpp -o dist\build\src/cpp/eljaccelerator.o
but gives an error under TDM-gcc:
Building wxc
c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe -Wl,--hash-size=31 -Wl,--reduce-
memory-overheads -Isrc/include -IC:/mingw/msys/1.0/local/include/wx-3.0 -IC:/min
gw/msys/1.0/local/lib/wx/include/msw-unicode-3.0 -D__WXMSW__ -DWXUSINGDLL -D_FIL
E_OFFSET_BITS=64 -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\eljaccelerator.cpp
-o dist\build\src/cpp/eljaccelerator.o
In file included from C:/mingw/msys/1.0/local/include/wx-3.0/wx/crt.h:19:0,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/string.h:4305,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/memory.h:15,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/object.h:19,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/wx.h:15,
from src/include/wrapper.h:20,
from src\cpp\eljaccelerator.cpp:1:
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const char*, size_t)':
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:173:92: error: 'strnlen' was n
ot declared in this scope
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const wchar_t*, size_t)':
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:187:95: error: 'wcsnlen' was n
ot declared in this scope
Failed to install wxc-0.90.1.1
I was wondering if anyone has any similar experience. Any idea what went wrong and how to fix compilation for TDM-GCC? I tried adding #include <cstring> to wxcrt.h but it doesn't change anything.
FYI, I have compiled wxWidgets 3.0.0 from source in mingw and tdm-gcc versions respectively, using
./configure --enable-stl && make && make install
I can provide more details if needed.
First of all, wxWidgets certainly does work with MinGW, the fact that only TDM binaries are provided simply means that someone volunteered to provide the latter but not the former. But all three popular versions of MinGW (the two already mentioned and MinGW-w64) do work, so there must be something wrong with the build...
However while they all work, they are certainly different compilers, so what do you mean that they both use the same gcc binary? It must be either a MinGW one or a TDM one, but it can't be both at once.
It's also very suspicious that the configure detects different flags to use for the large file support. Look at config.log, something must have gone wrong and there must be some errors in the initial stage in it.
I'm attempting to compile a relatively simple Fortran executable so that it can be passed around to other Windows users that don't have Cygwin (or something of the sort) installed, however, I'm unable to get the executable to operate as a standalone. I've tried gfortran -static file.f and gfortran -static-libgfortran file.f, however other users always encounter this error:
The program can’t start because cygwin1.dll is missing from your computer. Try reinstalling the program to fix this problem.
From what I've read online (e.g. here), the -static option should be sufficient. I have verified that running the executable from my machine (DOS prompt) does work.
I have gcc (gfortran) version 4.7.3. I should also point out this is my first attempt at compiling portable Fortran.
Update
After realizing that this isn't a gfortran-specific issue (thanks to replies here), searches led me to related posts here and here
This is partially explained in the Cygwin FAQ. The solution is to install the mingw64-i686-gcc-fortran package with its dependencies, and cross-compile your code with i686-w64-mingw32-gfortran -static.
Just package the cygwin1.dll along with your binary file (both in the same folder) then it will run just fine.
I tried to compile vim 64-bit on windows. But I don't know how to use MinGW-64. There's a mingw-32-make in the 32-bit version, which I could use to build. But I didn't find any 'make' program in the 64-bit MinGW. Could you please tell me how to use mingw-64, or any tutorial I could follow?
Thank you.
It does not matter from which source make program comes, it only just must be able to execute the Makefile. To compile vim with MinGW with specific compiler and Make_ming.mak makefile I used to use the following:
Export environment variable CC set to the appropriate compiler (in my case it was 32-bit named i686-pc-mingw32-gcc).
Export environment variable LD set to the appropriate linker (in my case it was similar, but with -ld suffix in place of -gcc). Be sure they are found on $PATH: I am not sure what kind of escaping you should do to make makefile work so just avoid the necessity for escaping.
Export environment variable prefix pointing to the directory where mingw resides (in my case it was /usr/i686-mingw32: I am cross-compiling).
Export environment variable vim_cv_toupper_broken set to yes. I am not sure why I did this.
Finally run make:
cd {path/to/vim/repository}/src
make -f Make_ming.mak FEATURES=HUGE CROSS_COMPILE=i686-pc-mingw32- OPTIMIZE=SPEED VIMRUNTIMEDIR="C:\\vim73\\runtime" CROSS=yes ARCH=i686
. You definitely do not need CROSS_COMPILE and CROSS options and ARCH should be probably omitted (or equal to x86_64). VIMRUNTIMEDIR should point to the place where you plan to install vim. Not sure about escaping though.
Exporting environment variables should be probably done with
set var=value
, e.g.
set CC=x86_64-w64-mingw32-gcc
(use actual name of the executable). If this does not work try moving them to the make command line:
make -f Make_ming.mak CC=x86_64-w64-mingw32-gcc LD=… …
.
And variables for python (should also be present on the command-line):
PYTHON="P:\\ath\\to\\directory\\with\\python" PYTHONINC="P:\\ath\\to\\directory\\with\\python\\header\\files" PYTHON_VER=27 PYTHON_VER_LONG=2.7.5
. (If using python msi installer PYTHONINC is %PYTHON%\\include. It is 90% some directory whose trailing path component is include. Should contain at least Python.h file.)
I just compiled VIM on MinGW and made a gist about it. I tried x86-64 (search for it), too, and with /etc/fstab changed to 64 it basically worked, just that my interpreters all were 32 and so it stopped there.
Try to set
ARCH=x86-64 in vim74/src/Make_ming.mak
and add option CC=x86_64-w64-mingw32-gcc, maybe it will be useful.
We have a problem building out C++ software on Ubuntu Linux with qmake.
Problem is: we use some library, for example OpenCV, that can have different versions in one system.
qmake automatically add -L/usr/lib or -L/usr/lib/x86_64-linux-gnu to g++ arguments, and contents of LIBS variables after it.
So there conflicts with different versions of OpenCV, the system version is used, but we need custom one, located at our build tree.
Are there any methods to change libs order in -L or something else to solve this problem?
There are two components to doing this:
First, you need to make sure to include them in your .pro file correctly. Do this with something like (this is from my current project):
LIBS += L${OPENCV_HOME}/lib \
-lopencv_core \
-lopencv_highgui \
You can replace the environment variable with whatever your path is. I've found it convenient to use environment variables like this because you also need header includes:
INCLUDEPATH += $$(OPENCV_HOME)/include/opencv2 \
$$(OPENCV_HOME)/include/opencv \
$$(OPENCV_HOME)/include
This allows you to create projects and build them correctly.
When you attempt to run them, however, you will likely run into all sorts of issues due to your app finding the wrong libraries (from system libraries like you say) - you need to set your LD_LIBRARY_PATH variable correctly. In this case I have a launch script (you can do this in your user profile or elsewhere) which contains:
export LD_LIBRARY_PATH=${OPENCV_HOME}/lib
Which then looks to that (as well as other) locations on the LD_LIBRARY_PATH first, before system libraries.
Another hack is to exploit the LIBS = $(SUBLIBS) ... part of the Makefile qmake writes.
Namely, invoke the generated Makefile with
make SUBLIBS=-L/path/to/your/opencv
I had the same issue which I fixed by setting QMAKE_LIBDIR to the lib directory of the build tree. QMake automatically added the system library path after this value, thus allowing to correctly detect the desired libraries:
QMAKE_LIBDIR = /path/to/desired/opencvlib
I have two OpenCV versions on my PC, one installed by default in /usr and another installed by compiling the sources in a custom dir (not /usr).
The first worked just fine with Qt, the other didn't. I struggled a lot trying to make the Qt Creator work with my OpenCV compiled sources. So I added -L/opencv_lib_path but it always said 'undefined reference' for some OpenCV API I was using. It simply doesn't want to look there for the libs, it will look in LD_LIBRARY_PATH instead. I tried adding my opencv_lib_path to the LD_LIBRARY_PATH, no joy either.
The only thing that worked was Frodon's solution, just add this in your Qt .pro file and it will work.
QMAKE_LIBDIR = /path_to_installed_opencv/lib