I am using Windows 7 64-bit, and want to compile the non-precompiled libraries (specifically, I need Filesystem) from the command line (I do not use MSVC). I have MinGW, but read on the Boost website that MSYS shell is not supported, so I'm trying to compile the libraries from the Windows command prompt.
First of all, running bootstrap.bat results in the following error:
Building Boost.Jam build engine
'cl' is not recognized as an internal or external command,
operable program or batch file.
Failed to build Boost.Jam build engine.
Please consult bjam.log for furter diagnostics.
You can try to obtain a prebuilt binary from
http://sf.net/project/showfiles.php?group_id=7586&package_id=72941
Also, you can file an issue at http://svn.boost.org
Please attach bjam.log in that case.
Plus, there is not bjam.log file anywhere in the boost_root directory.
Disregarding this error, and trying to run the downloaded bjam.exe file, I get another error:
c:/boost_1_45_0/tools/build/v2/build\configure.jam:145: in builds-raw
*** argument error
* rule UPDATE_NOW ( targets * : log ? : ignore-minus-n ? )
* called with: ( <pbin.v2\libs\regex\build\gcc-mingw-4.5.2\debug\address-model64\architecture-x86>has_icu.exe : : ignore-minus-n : ignore-minus-q )
* extra argument ignore-minus-q
(builtin):see definition of rule 'UPDATE_NOW' being called
c:/boost_1_45_0/tools/build/v2/build\configure.jam:179: in configu
re.builds
c:/boost_1_45_0/tools/build/v2/build\configure.jam:216: in object(
check-target-builds-worker)#409.check
etc. with quite a lot of complaints. Setting the 'architecture' and 'address-model' options doesn't help.
Any suggestions?
#Andre
Following Andre's suggestion, I created minGW-bjam that was running for an hour and a half and built most of the libraries, but not the one I need at this moment: Filesystem.
Trying to compile only Filesystem, specifying version 2 with define="BOOST_FILESYSTEM_VERSION=2" and --disable-filesystem3 does not help. I get the following error:
gcc.compile.c++ bin.v2\libs\filesystem\build\gcc-mingw-4.5.2\debug\v3\src\operations.o
In file included from ./boost/filesystem/v3/operations.hpp:24:0,
from libs\filesystem\v3\src\operations.cpp:48:
./boost/filesystem/v3/config.hpp:16:5: error: #error Compiling Filesystem version 3
file with BOOST_FILESYSTEM_VERSION defined != 3
libs\filesystem\v3\src\operations.cpp:647:26: warning:
'<unnamed>::create_symbolic_link_api' defined but not used
"g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -
DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_FILESYSTEM_VERSION=2 -DBOOST_SYSTEM_DYN_LINK=1 -
I"." -c -o "bin.v2\libs\filesystem\build\gcc-mingw-4.5.2\debug\v3\src\operations.o"
"libs\filesystem\v3\src\operations.cpp"
etc. with a lot of ...failed statements.
Any hints here?
It's easy. Just use "bootstrap.bat gcc" to select GCC
The bootstrap script assumes the msvc compiler is available. But you can build bjam by hand without the bootstrap script:
Step into the tools\build\v2\engine\src directory and call "build.bat mingw". It will create a bjam.exe. You can then put it in your %PATH% or perhaps in the root boost directory...
To be honest, I usually build bjam like this with the msvc compiler and use this "msvc-bjam" to build my mingw boost libraries.
So... the first part of the problem was solved by Andre's suggestion.
The second part was solved by setting the variable BOOST_FILESYSTEM_VERSION to 3 everywhere (the error above complains about incompatibility with what is set in file user.hpp). Although this is not the default option for Boost 1.45 that I'm using, it's the only thing that works (i.e. bjam wants to compile version 3 no matter what). So now I have version 3 of the filesystem library, and version 2 for all others, but that doesn't seem to be an issue for the moment.
I do have a problem with using Boost with OpenCV and Eigen libraries, though... off to the next challenge ;)
Since I can't comment yet, I want to add that I ran
bootstrap mingw
to generate b2 properly and then
b2 --build-dir="c:\boost_release" toolset=gcc --build-type=complete "c:\boost_release\stage"
The includes will be located at your boost root folder (boost_1_58_00/boost) and your binaries at the specified build folder.
Related
How can I link libxml on MinGW when using an omnetpp shell?
I am using omnetpp on a windows 10 machine.
My problem happens when I am trying to install the 3rd party package from here
I think that there is a problem in the Makefile failing to locate the libxml library
Following Rudi's answer (following the question) I changed the Makefile libxml path to I/mingw64/include/libxml2 but I still
get a undefined reference to 'xmlFunctionName' error (for many function names)
I tried to isolate the problem and to compile a sample of code from libxml2
Following the compilation guide: using gcc `xml2-config --cflags --libs` -o tree2 tree2.c
I got a fatal error: 'libxml/parser.h' file not found
When I replaced xml2-config --cflags --libs with -I/mingw64/include/libxml2
I got the same error as before undefined reference to 'xmlFunctionName'
what can I do to resolve that issue?
To this specific problem: libxml2 is actually already present as OMNET 5.x also uses it. All dependencies and tools are available in the tools/win64/mingw64 directory. The problem is that (for unknown reasons) the include file of the include/libxml2/libxml folder. The configure script correctly detects this and makes it available in the Makefile.inc as XML_CFLAGS= = -I/mingw64/include/libxml2
This must be added to the compiler flags for each file where you want to use the XML parser. (the library files are in the /mingw64/lib folder) so those are detected and can be used without additional config.
Generally, third party libraries should be available in the /mingw64/include and /mingw64/lib folders. You can either copy them manually there or try to install it with the mingw package manager (however that will most likely ruin your omnet installation as mingw64 is not particularly consistent and it is a rolling release - i.e. this is highly not recommended).
I'm trying to compile and link to HDF5 with a Fortran program, but I'm getting a run-time error. I've followed closely the procedure described in the answer to this question
Use HDF5 from intel fortran on windows
I've set PATH in the environment variables instead of setting them in visual studio. I moved all of the generated .mod and .lib files to the mod and lib folders in my project folder.
From the command prompt, my compiler config looks like
gfortran --version
GNU Fortran (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.2
gmake --version
GNU Make 3.81
And my makefile looks like
ifdef SystemRoot
PATHSEP2 = \\
else
PATHSEP2 = /
endif
PS = $(strip $(PATHSEP2))
OBJ_DIR = obj
MOD_DIR = mod
LIB_DIR = lib
FC = gfortran
FCFLAGS = -I$(MOD_DIR) -g -Wall
FLFLAGS = -I$(MOD_DIR) -L$(LIB_DIR) -l$(LIB_DIR)hdf5_fortran
SRCS_F = testHDF5.f90
TARGET = testHDF5
all: $(TARGET)
testHDF5: testHDF5.f90
$(FC) -o $# testHDF5.f90 $(FLFLAGS)
$(OBJ_DIR)$(PS)%.o: %.f90
$(FC) $(FCFLAGS) -c -o $# $<
I've changed the hdf5_fortran.lib to libhdf5_fortran.lib because of what I read here
http://www.mingw.org/wiki/specify_the_libraries_for_the_linker_to_use
When I run gmake, I get
gfortran -o testHDF5 testHDF5.f90 -Imod -Llib -llibhdf5_fortran
And when I try to run the executable, a window pops up that says "The application was unable to start correctly (0xc000007b). Click OK to close the application."
This link
http://www.solveinweb.com/solved-the-application-was-unable-to-start-correctly-0xc000007b-click-ok-to-close-the-application/
Suggests that it is due to incompatibility of 32-bit to 64-bit. I'm using a 64-bit machine, and I did download a 32-bit version of CMake, but only because there doesn't seem to be an available version for 64-bit machines. In addition, this link
http://www.cmake.org/pipermail/cmake/2010-September/039375.html
Suggests that it shouldn't matter. So my question is, where did I go wrong? Are there any glaring mistakes with what I've shown so far?
UPDATE:
I found out that the runtime error was due to not specifying a path, in this case HDF5_DIR. In the USING_HDF5_CMAKE document, it says to specify the environment variable
HDF5_DIR=C:/Program Files/HDF_Group/HDF5/1.8.x/cmake/hdf5
Which fixed the problem of the application crashing at the very start. But now, I'm getting the error
HDF5-DIAG: Error detected in HDF5 (1.8.14) thread 0:
#000: C:\Users\Charlie\Downloads\CMake\hdf5-1.8.14\src\H5D.c line 167 in H5Dcr
eate2(): not a datatype ID
major: Invalid arguments to routine
minor: Inappropriate type
HDF5-DIAG: Error detected in HDF5 (1.8.14) thread 0:
#000: C:\Users\Charlie\Downloads\CMake\hdf5-1.8.14\src\H5D.c line 415 in H5Dcl
ose(): not a dataset
major: Invalid arguments to routine
minor: Inappropriate type
I suppose the first error
HDF5-DIAG: Error detected in HDF5 (1.8.14) thread 0:
#000: C:\Users\Charlie\Downloads\CMake\hdf5-1.8.14\src\H5D.c line 167 in H5Dcr
eate2(): not a datatype ID
major: Invalid arguments to routine
minor: Inappropriate type
Is the most important one since that may trigger later ones. According to this thread
http://hdf-forum.184993.n3.nabble.com/HDF5-Fortran-Fail-to-execute-of-a-basic-F90-program-td4026778.html
It is suggested that the same compiler is used to build the library as building the fortran source code (if I'm not mistaken). During the build using CMake, I specified to use MinGW, which I believe is used during both builds, right?
Again, any help on this is greatly appreciated.
I contacted hdf5 support in regards to this problem
Platform/OS:
Windows 7
Product/Version:
HDF5, Latest download
Description:
Hi, I'm having trouble getting HDF5 working on my windows machine with fortran. Below is an outline of what I've done, and after I show the error I get.
1.1) Download and install CMake, Windows (Win 32 Installer) from http://www.cmake.org/download/
1.2) I did not add CMake to the system PATH, because it was too long.
1.3) I manually added "C:/Program Files (x86)/CMake/bin" to the PATH (for user)
in computer->properties->advanced system settings->environment variables 2.1) Download and install HDF5
2.2) I manually added "C:/Program Files/HDF Group/HDF5/1.8.14/cmake/hdf5" to the PATH (for user) in computer->properties->advanced system settings->environment variables
3.1) I created a new, empty, directory (/Project/) and copied HDF5Examples-0.1.1-Source.zip and HDF518 Examples.CMAKE to it. 3.1) Downloaded hdf5-CMakeWindows.zip from http://www.hdfgroup.org/HDF5/release/cmakebuild.html and unzipped
file to find a folder named CMake.
3.2) Opened CMake GUI, set Source Code Dir = CMake/hdf5-1.8.14 folder
3.3) Set Where to build binaries Dir = /Project/ (project folder containing HDF5Examples-0.1.1-Source.zip and HDF518 Examples.CMAKE)
4.1) In the CMake GUI, I pressed Configure, (selected MinGW and default from the 1st and 2nd drop down respectively), Configure. Checked BUILD_SHARED_LIBS and HDF5_BUILD_FORTRAN. Configure, configure, generate.
4.2) I navigated to the bin directory of the CMake folder and copied the library files, .dll files, and .mod files to an empty test folder (/test_HDF5/), where I separated them into lib/mod folders.
4.3) I created a makefile which, if done correctly, linked the .lib files.
4.4) I compiled the files and linked the libraries and there seemed to be no errors, nor warnings. When running the testHDF5.exe I received the following error: The application was unable to start correctly (0xc000007b). Click OK to close the application. I believe this is a configuration issue, and I'm not sure how to resolve it.
I'm very new with linking libraries and I'm just trying to use HDF5 as a data exporting tool with my existing fortran code. Any help is greatly appreciated.
Sincerely, Charlie Kawczynski
And their response was, as of April 14 2015, that MinGW is not supported:
Hi Charlie,
We do not support MinGW at this time. The developer had tried
building with Fortran and was not able to get it to work.
We do have a user forum where you can post questions. However, others
have posted issues about MinGW and Fortran that have not been resolved. :(
For information on the HDF Forum, see:
http://www.hdfgroup.org/services/community_support.html
-Barbara
Hope this helps others.
Android NDK: WARNING:/cygdrive/e/android-sdk-windows/AndroidWorkspace/muPDF/jni/Android.mk:mupdfcore: LOCAL_LDLIBS is always ignored for static libraries [armeabi-v7a] Compile : mupdf <= mupdf.c /bin/sh: /cygdrive/c/Users/MEHDI/Downloads/Compressed/android-ndk-r9d-windows-x86/android-ndk-r9d/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/arm-linux-androideabi-gcc: No such file or directory make: * [/cygdrive/e/android-sdk-windows/AndroidWorkspace/muPDF/obj/local/armeabi-v7a/objs/mupdf/mupdf.o] Error 127
It looks like you're trying to use GCC 4.4.3 which is no longer distributed with the NDK. Did you set NDK_TOOLCHAIN_VERSION in your environment? If so, please undefine it and re-run the command.
Apart from that, the warning is perfectly normal. You should use LOCAL_EXPORT_LDLIBS if you want to export dependent system libraries for your static library. LOCAL_LDLIBS is only used when building a shared library or executable.
ndk-build on Windows does not need cygwin, and some of its components cannot work with cygwin. Run ndk-build.cmd from Windows CMD shell, and avoid hardcoding cygdrive anywhere.
The warning you get is legitimate. You probably have include $(BUILD_STATIC_LIBRARY) in your Android.mk: this module does not use linker, therefore it does not need LOCAL_LDLIBS neither LOCAL_LDFLAGS. I would not worry about this warning, if this is the only problem in your build.
If you need more help with your project, please post the Android.mk file (or fragments of it), and also the Application.mk if you have one.
I want to compile a source code, but there are some compiling errors about __sync_xxx functions (__sync_bool_compare_and_swap etc.)
GCC version on machine is 3.4.3 (it must be gcc 4.1 or over for supporting atomic builtins), so I have downloaded GCC v4.6, copied it to another directory (I didn't remove v3.4.3) then change the $PATH path for GCC but it doesn't work (the same error occurs).
I want to ask that is only changing gcc path with export PATH=... enough for compiling with new GCC?
Use the following configure option when compiling gcc:
--program-prefix=foo --program-suffix=bar
and it will produce bin programs of the form "foo-gcc-bar", so that you may differentiate different builds of gcc.
Replace foo and/or bar with an appropriate "tag" for your build (eg "-4.6" for example).
This way if it doesn't find your toolchain correctly it will fail fast rather than using the 3.4 version.
It also means that different toolchain builds can coexist in the standard installation prefix directories.
We have to use -march=686 switch to get it to work on intel.
Try checking and updating LD_LIBRARY_PATH, to use the lib path for the new gcc installed.
This shoud be a simple problem for users more advanced than I am. :-)
How do I use the boost library with cygwin on windows?
I am programing with g++ using cygwin on a winxp machine.
I need modified Bessel functions of the second order, so I downloaded the latest version of the boost library and installed it in
'c:\cygwin\lib\boost_ 1_ 38_0\' folder.
I am trying to run the "example.cpp" program from the "getting started" section of their website:
http://www.boost.org/doc/libs/1_35_0/more/getting_started/unix-variants.html
I am compiling from the directory where I created the example file using a simple Bash shell command line: 'g++ -Wall example.cpp'
I keep getting the message:
"boost/lambda/lambda.hpp: no such file or directory"
I tried every possible combination of -L, -l, -I options in the command line to include the directory, to no avail. Also tried to add the folder in the PATH line of my windows system.
How do I link to the /boost directory and ALSO to all subdirectories? The header file 'lambda.hpp' is calling other header files in subdirectories.
You're probably not that familiar with C++ yet? It seems you are confusing terms.
C++ programs are built in two steps: compiling and linking. In the first step, each source file (typically called .cpp) is handled individually. Each .cpp file usually uses multiple headers, so the compiler first inserts those - literally. That's why it's called #include.
In the second step, the linker takes all the compiled .cpp files together and builds your final program. Some of those compiled .cpp's might have been bundled together before, in which the bundle is called a library.
Boost is a collection of headers and .cpp files. So, both compiler and linker might need to find the Boost directories. From your error message, it's clear that the compiler step is the problem. The linker does not need headers anymore.
The compiler will see the #include <boost/lambda/lambda.hpp> instuction. That means it needs to know where that first-level boost directory is found. I would guess at this point that the path would be /lib/boost_ 1_ 38_0/include (there's always the find / -name lambda.hpp shotgun appraoch)
If you are not utterly wedded to cygwin, you should take a look at http://nuwen.net/mingw.html which gives you a complete MinGW C++ installation with all the libraries (such as Boost) set up for you.
Edit: I should make it clear you can use this MinGW installation in addition to Cygwin, not as a replacement. Just make sure the MinGW bin directory appears in your PATH before the Cygwin one.
I think you need -I /lib/boost_1_38_0 - although that's a pretty unusual place to put it. You'll have to let us know how you installed it, did you just unzip it in the location you said, or did you run the makefiles? I assume that since you gave a windows path you didn't install it within cygwin - which you probably should do. The instructions in the getting started guide for unix should help - although don't download a prebuilt bjam - it needs to be built with cygwin.
But if you're not very familiar with cygwin (or unix in general) I think you might find it easier to use a native windows tool - as in Neil Butterworth's answer.
Thank you all for the information, it's a nice introduction to the use of libraries with cygwin.
Daniel was right. While any variation gives an error, the following line (using caps i) does the trick:
g++ -Wall -I /cygdrive/c/cygwin/lib/boost_1_38_0/ example.cpp -o example
I will also check MinGW in the next few days.
p.s. I simply downloaded and unzipped boost in that folder, but since I am only using header files I probably won't need to compile with cygwin. [The boost version included with cygwin was 1.33, which does not seem to have Bessel functions.]
This is on win7 cygwin64 g++ 5.4, and boost-1.64.7z on 2017-7. Google doesn't show any useful result for getting started for boost on windows (is boost out of fashion?).
By experimenting, I managed to compile and run a boost graph sample program as follows:
:: g++ 5.4 in c:\cygwin64
:: 7z extract boost download in c:\tools\boost\boost164
> set BOOST_ROOT=c:\tools\boost\boost164
> setx BOOST_ROOT c:\tools\boost\boost164 -m
> cd %BOOST_ROOT%
> bootstrap.sh gcc (the bat files doesn't work)
> b2.exe
...failed updating 58 targets...
...skipped 18 targets...
...updated 1123 targets...
:: Lots of example here (not ranked highly by google)
> mklink /D eg %BOOST_ROOT%/libs/graph/example
:: Compiled and run [maxflow code using boost library][1]
:: http://vision.csd.uwo.ca/code
> unzip ; vi Makefile
CPPFLAGS = -I %BOOST_ROOT%/
LDFLAGS = -L%BOOST_ROOT%/stage/lib
> make
> set PATH=%PATH%;%BOOST_ROOT%/stage/lib
> maxflow.exe
Flow = 6