I'm trying to build a cpp file with opencv functions.
Go 1.3 states that swig building is now bundled in go build tool but I didn't find a way to tell that build tool to add include dirs and libs args with pkg-config.
go test -x cv_test.go
cd /Users/pierre/Projects/go-swig
clang++ -I . -fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common -g -O2 -o $WORK/_/Users/pierre/Projects/go-swig/_obj/binding.cpp.o -c ./binding.cpp
# _/Users/pierre/Projects/go-swig
In file included from ./binding.cpp:1:
./binding.h:5:10: fatal error: 'cv.h' file not found
$WORK/command-line-arguments/_test/tiler.test
FAIL command-line-arguments [build failed]
Has anyone did it successfully ?
As of right now, Go doesn't correctly pass include paths to swig if you use pkg-config, I submitted a patch but it most likely won't be included until 1.4 is out.
So you either build Go with the patch or manually specify the paths with #cgo CXXFLAGS / #cgo LDFLAGS like #JamesHenstridge suggested.
You can tell CGo to use the include and link flags for a particular pkg-config library using the following syntax in one of your Go source files:
// #cgo pkg-config: some-package
import "C"
That is, include it along with any other declarations in the comment block processed by cgo. It is only necessary to include this in one of the .go files in the package. You can also specify additional compile and link flags:
// #cgo CXXFLAGS: -std=c++11
// #cgo LDFLAGS: -L/some/library/dir -lfoo
Full details can be found in the cgo documentation
Related
I am using boost/multiprecision/cpp_int.hpp within class of a cpp file boost.cpp
My main in in practice.cpp
How do i add the Boost into the make file
The current make file looks like this:
practice.exe : practice.o
g++ -Wall -O2 practice.cpp -lws2_32 -o practice.exe
practice.o : practice.cpp
g++ -c -O2 -Wall practice.cpp
clean:
del *.o
del *.exe
So, the general idea is to just system install boost and let the compiler find it in the default include paths.
E.g. on a debian
apt install libboost-all-dev
Should be enough. Boost Multiprecision itself is header-only. So if you only need cpp_int, cpp_dec_float and cpp_bin_float, you're done. You might want GMP/MPFR support, in which case you need to link those libraries with the additional linker flags -lgmp or -lmpfr.
If you need Serialization support, also link -lboost_serialization which would be installed in the default library paths with the system-wide Boost package we installed at the start.
So recently I downloaded the Linux Subsystem on Windows 10, with Ubuntu.
I can compile an SDL2 app to Linux with the g++ command but whenever I try doing it with i686-w64-mingw32-g++ this command, I get an error saying main.cpp:5:9: fatal error: SDL2/SDL.h: No such file or directory.
The command I'm using is i686-w64-mingw32-g++ main.cpp -w -lSDL2 -o main.exe.
https://imgur.com/a/uqcGCoJ
Anyone knows how to fix this? :(
[EDIT]
So now I've tried specifying the directory of the necesary files with this command: g++ main.cpp -I/usr/include/SDL -L/usr/lib/x86_64-linux-gnu -w -Wall -Wextra -std=c++17 -lSDL2 -o main
which worked but when I use it with mingw it doesn't i686-w64-mingw32-g++ main.cpp -I/usr/include/SDL -L/usr/lib/x86_64-linux-gnu -w -Wall -Wextra -std=c++17 -lSDL2 -o main
https://imgur.com/a/sF6CpcP
You need to include the path to SDL's include directory on the command line. However, you need to include the path to the downloaded SDL for mingw32, not /usr/include/SDL2. The difference is the headers in /usr/include/SDL2 are for Linux and libs in /usr/lib are also for Linux, but you need to link to the Windows libraries.
What I usually do is download the development libraries for Mingw32 and put them directly into my project directory. Then all you need to do is add -ISDL2-2.0.8/i686-w64-mingw32/include -LSDL2-2.0.8/i686-w64-mingw32/lib to your command line and it will be able to find the headers and libraries it needs. Finally, make sure you copy SDL2-2.0.8/i686-w64-mingw32/bin/SDL2.dll to your executable directory in the Makefile.
Also, remember to link SDLmain as well. It handles creating a WinMain for you and all that, and then calls your main function.
I'm trying to compile the simavr project from https://github.com/buserror/simavr on Windows 10 using MSYS2 and mingw-w64.
After editing the makefiles to enable the MSYS clauses (Which are commented out by default), and changing the order of 2 include files, I can get the project to compile. I do however encounter an error in the linking step.
The output is
C:/Programs/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lsimavr
Editing the makefile to print the ${LDFLAGS}, yield the following.
-L/lib -L/local/lib -L/c/Users/University/GitHub/simavr/simavr/../simavr/obj-i686-w64-mingw32 -lsimavr -lelf -lws2_32
Looking in the folder "obj-i686-w64-mingw32" mentioned in the build script, the file "libsimavr.a" is present. If I copy the file to the msys lib folder the linking step works fine.
The folder structure of the project is as follows:
simavr root (Where i run the makefile from, located in /c/Users/University/GitHub)
simavr
obj-i686-w64-mingw32
As far as I can tell, LD should be able to link properly without me copying the file manually. What am I missing here?
Edit:
The final command before the linker error.
cc -MMD -Werror -O2 -Wall -g -I/usr/local/include -DNO_COLOR -o obj-i686-w64-mingw32/run_avr.elf obj-i686-w64-mingw32/run_avr.o -L/lib -L/local/lib -L/c/Users/University/GitHub/simavr/simavr/../simavr/obj-i686-w64-mingw32 -lsimavr -lelf -lws2_32
Edit 2:
Cleaning the include paths of MSYS folders:
cc -MMD -Werror -O2 -Wall -g -DNO_COLOR -o obj-i686-w64-mingw32/run_avr.elf obj-i686-w64-mingw32/run_avr.o -L/c/Users/University/GitHub/simavr/simavr/../simavr/obj-i686-w64-mingw32 -lsimavr -lelf -lws2_32
C:/Programs/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lsimavr
Passing CC=gcc to make:
gcc -MMD -Werror -O2 -Wall -g -DNO_COLOR -o obj-i686-w64-mingw32/run_avr.elf obj-i686-w64-mingw32/run_avr.o -L/c/Users/University/GitHub/simavr/simavr/../simavr/obj-i686-w64-mingw32 -lsimavr -lelf -lws2_32
C:/Programs/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lsimavr
Edit 3:
Output of the find command:
$ find /c/Users/University/GitHub/simavr -name 'libsimavr.a'
/c/Users/University/GitHub/simavr/simavr/obj-i686-w64-mingw32/libsimavr.a
Note that previous entries have been made using the git bash prompt, not the one from msys2. However, running the same commands in the msys2 prompt or the mingw prompt from msys2 yields the same results.
Using mingw-w64 toolchain to build project you MUST remove from CFLAGS/CXXFLAGS/CPPFLAGS all paths with /usr, /local, /lib, /include as this paths can contain headers and libs from MSYS2 itself. Second, try pass "CC=gcc" to makefile.
I'm trying to write an autoconf test for a C++ library. I followed http://nerdland.net/2009/07/detecting-c-libraries-with-autotools/ . My check looks like this:
SAVED_LDFLAGS=$LDFLAGS
LDFLAGS="$LDFLAGS -lMyLib"
AC_LINK_IFELSE(
[AC_LANG_PROGRAM([#include <mylibheader.hpp>],
[MyLibNamespace::SomeObject obj()])],
[TEST_LIBS="$TEST_LIBS -lMyLib"] [HAVE_MYLIB=1],
[AC_MSG_ERROR([libMyLib is not installed.])])
LDFLAGS=$SAVED_LDFLAGS
The test fails. If i check config.log the problem seems to be with the generated compilation command given by autoconf for the check:
g++ -o conftest -g -O2 -lMyLib conftest.cpp
As you can see, the -l params aren't at the end, after all inputs and outpus. If i copy&paste the conftest.cpp code from config.log i can make it compile with:
g++ -o conftest -g -O2 conftest.cpp -lMyLib
How can autoconf be wrong? How may i fix this?
The problem is that you're adding -lMyLib to LDFLAGS instead of adding to LIBS. In other words, do this instead:
SAVED_LIBS=$LIBS
LIBS="-lMyLib $LIBS"
AC_LINK_IFELSE(
[AC_LANG_PROGRAM([#include <mylibheader.hpp>],
[MyLibNamespace::SomeObject obj()])],
[TEST_LIBS="$TEST_LIBS -lMyLib"] [HAVE_MYLIB=1],
[AC_MSG_ERROR([libMyLib is not installed.])])
LIBS=$SAVED_LIBS
Edit: link order of libraries is important, so I've updated the LIBS= line to link MyLib before the other libraries, if any, with the assumption that MyLib may depend on other libraries.
I think this is a question about automake.
http://home.gna.org/cal3d/
I'm struggling with the cally demo of Cal3D.
The first problem I ran into was that the Cal3D code base is missing #include <cstring> and #include <memory> in a lot of places.
Doing this every time I got an error in any source file in Cal3d was enough to let me compile it.
The cally demo also needed some #include <cstring>
Now my problem is that HAVE_SDL_H is not defined when tick.cpp is compiled.
The configure and makefile seems to accept that SDL is installed on my system, but the macros in src/tick.cpp doesn't.
I guess there is some kind of bug in the configure.in or something, but I don't seem to find out just what it is.
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -O3 -ffast-math -funroll-all-loops -g -O2 -I/usr/include -I/usr/local/include -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -MT tick.o -MD -MP -MF ".deps/tick.Tpo" -c -o tick.o tick.cpp; \
then mv -f ".deps/tick.Tpo" ".deps/tick.Po"; else rm -f ".deps/tick.Tpo"; exit 1; fi
tick.cpp:144:5: error: #error "no timer implemented for your plateform"
Edit:
I've finally compiled the demo.
When I compiled cal3d I added #include <cstring> to the following files:
src/cal3d/hardwaremodel.cpp
src/cal3d/platform.cpp
src/cal3d/renderer.cpp
src/cal3d/submesh.cpp
src/cal3d_converter.cpp
When I compiled cally I added #include <cstring> to the following files:
src/demo.cpp
src/model.cpp
In model.cpp I changed line 640 from
glBindTexture(GL_TEXTURE_2D, (GLuint)pCalRenderer->getMapUserData(0));
to
glBindTexture(GL_TEXTURE_2D, *(GLuint*)pCalRenderer->getMapUserData(0));
I also did some uglier changes to get src/tick.cpp to compile.
In src/tick.cpp I removed everything that had anything to do with SDL. I also removed a macro if clause checking for __i386__ or __ia64__, so that Tick::getTime() could also be compiled.
I know that this is not a proper fix, so improvements are very much welcome.
64-bit OpenSuSE with a 2.6.27 kernel.
GCC: 4.3.2
GNU Automake: 1.10.1
GNU Autoconf 2.63
64-bit versions of the SDL library is installed with zypper (through the GUI).
Solution
In configure.in change
AC_CHECK_HEADERS([SDL.h])
to
AC_CHECK_HEADERS([SDL/SDL.h])
(then run autoreconf and ./configure)
in tick.cpp change all checks for HAVE_SDL_H to HAVE_SDL_SDL_H
This is all due to a restructuring in the sdl library.
The errors you got with missing #include <cstring> and #include <memory> is mainly du to a cleanup that happened in GNU headers: inclusion of unnecessary headers were removed and consequently programs not including the proper headers for the features they use face compiling errors.
About HAVE_SDL_H, most likely, your Linux distribution is missing packages.
You probably need to install the SDL library. Some Linux distributions like Ubuntu split the packages between the library runtime and the dev files so you need to install both packages
sudo apt-get install libsdl1.2-dev
Regarding:
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -O3 -ffast-math -funroll-all-loops -g -O2 -I/usr/include -I/usr/local/include -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -MT tick.o -MD -MP -MF ".deps/tick.Tpo" -c -o tick.o tick.cpp; \
then mv -f ".deps/tick.Tpo" ".deps/tick.Po"; else rm -f ".deps/tick.Tpo"; exit 1; fi
tick.cpp:144:5: error: #error "no timer implemented for your plateform"
It indeed fails to compile because HAVE_SDL_H is not defined in config.h. When you look at configure.in you see it's using AC_CHECK_HEADERS([SDL.h])
From the autoconf manual:
— Macro: AC_CHECK_HEADERS (header-file..., [action-if-found], [action-if-not-found], [includes])
For each given system header file header-file in the blank-separated argument list that exists, define HAVE_header-file (in all capitals). If action-if-found is given, it is additional shell code to execute when one of the header files is found. You can give it a value of ‘break’ to break out of the loop on the first match. If action-if-not-found is given, it is executed when one of the header files is not found.
So, AC_CHECK_HEADERS([SDL.h]) makes configure search for SDL.h in /usr/include and doesn't find it because its (new?) path is /usr/include/SDL/SDL.h
As a workaround, use CPPFLAGS to add system header search paths when invoking configure:
./configure CPPFLAGS="-I/usr/include/SDL"
Now you may want to fix configure.in
configure.in uses AM_PATH_SDL(1.2.0) which will end up invoking sdl-config --cflags to define SDL_CFLAGS. (the implementation of AM_PATH_SDL typically lies in the /usr/share/aclocal/sdl.m4 file)
# Check for SDL
AM_PATH_SDL(1.2.0)
LDFLAGS="$LDFLAGS $SDL_LIBS"
CXXFLAGS="$CXXFLAGS $SDL_CFLAGS"
AC_CHECK_HEADERS([SDL.h])
AC_LANG_CPLUSPLUS
sdl-config --cflags returns -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT but those -I and -D directives should not end up in CFLAGS anyway but rather in CPPFLAGS (as per the autoconf manual). Hence I would say there is already something wrong "at the SDL level".
Now take a look at the AC_LANG documentation:
‘C’
Do compilation tests using CC and CPP and use extension .c for test programs. Use compilation flags: CPPFLAGS with CPP, and both CPPFLAGS and CFLAGS with CC.
‘C++’
Do compilation tests using CXX and CXXCPP and use extension .C for test programs. Use compilation flags: CPPFLAGS with CXXCPP, and both CPPFLAGS and CXXFLAGS with CXX.
Moving the AC_LANG_CPLUSPLUS up so that it at least above AC_CHECK_HEADERS([SDL.h]) should make it now use g++ and CXXFLAGS when trying to compile SDL.h which should success since SDL_CFLAGS were added to CXXFLAGS. (again, it should really be SDL_CPPFLAGS but you won't change SDL...)