I just installed boost on my mac. (Installed MacPorts, sudo port install boost)
In XCode I added Header Search Path (/opt/local/include) and Library Search Path (/opt/local/lib) and added libraries into Build Phases - Link Binary With Libraries (libboost_filesystem-mt.a, libboost_filesystem-mt.dylib, libboost_system-mt.a, libboost_system-mt.dylib).
Now I trying to build and run this code
#include <iostream>
#include <string>
#include <boost/filesystem.hpp>
int main() {
std::string filename;
std::cin >> filename;
std::cout << boost::filesystem::exists(filename);
return 0;
}
And with any path typed I got Segmentation Fault: 11 when calling exists().
What i did wrong? Is any mistakes when installing boost?
I've run in to similar problems in the past when boost isn't built with the same CXXFLAGS as your program. Here's a pseudo-complete set of bootstrap instructions.
# Configure, build, and install boost
./bootstrap.sh \
--prefix=${PWD}/.local \
--with-libraries=...,filesystem,...
./b2 \
-q \
-d2 \
-j4 \
--debug-configuration \
--disable-filesystem2 \
--layout=tagged \
--build-dir=${PWD}/obj \
cxxflags="-v -std=c++11 -stdlib=libc++" \
linkflags="-stdlib=libc++" \
link=shared \
threading=multi \
install
The important part there is the cxxflags and linkflags. In my experience, it's most often because macports compiles without using -stdlib=libc++ but that's required when using compiling C++11 code using -std=c++11. Common symptoms include random backtraces in gdb that indicate something is a problem with a pointer inside of a particular struct buried deep within a boost library/template.
As you can tell from the above, I build a local copy of boost in to a per-project directory (e.g. ${PWD}/.local) and then link against the local version during development until it's time to package (at which point I statically link or do something else).
# In a GNUmakefile
LOCAL_DIR=${PWD}/.local
INC_DIR=${LOCAL_DIR}/include
LIB_DIR=${LOCAL_DIR}/lib
CPPFLAGS=-I"${INC_DIR}"
CXXFLAGS=-std=c++11 -stdlib=libc++
LDFLAGS=-stdlib=libc++ -L"${LIB_DIR}"
MYPROG_SRCS=myprog.cpp
MYPROG_OBJS=$(MYPROG_SRCS:.cpp=.o)
%.o : %.cpp %.hpp
${CXX} ${CXXFLAGS} ${CPPFLAGS} -c -o $# $<
myprog: ${MYPROG_OBJS}
${CXX} ${LDFLAGS} -o $# $^ ${LIBS}
Bottom line: your CPPFLAGS and LDFLAGS need to match between boost and your program.
I just tried it and it seems to work OK - I built your code as follows:
$ g++ -Wall -lboost_system-mt -lboost_filesystem-mt boost_filesystem.cpp
This is using Xcode 5, and boost 1.51.0 downloaded directly from http://boost.org and installed in /usr/local.
Related
I'm trying to set up an OpenMP project using Clang (3.7.0) on my laptop running Linux Mint.
Now I've read that OpenMP is not supported right away so I followed the tutorial https://clang-omp.github.io/ to integrate OpenMP into Clang.
I've cloned the source code, set the environment variables and set the -fopenmp flag to my project, but I still get the error:
fatal error: 'omp.h' file not found
when building.
My guess is that I have set the environment variables wrong. Is there a way to check if I have put them in the right place? I have just copied them in the .bashrc file.
When I run locate omp.h I get:
/usr/include/re_comp.h
/usr/include/linux/ppp-comp.h
/usr/include/linux/seccomp.h
/usr/include/net/ppp-comp.h
/usr/include/openssl/comp.h
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/omp.h
/usr/lib/perl/5.18.2/CORE/regcomp.h
/usr/src/linux-headers-3.13.0-24/arch/arm/include/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/arch/microblaze/include/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/arch/mips/include/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/arch/powerpc/include/uapi/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/arch/s390/include/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/arch/sh/include/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/arch/sparc/include/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/arch/x86/include/asm/seccomp.h
/usr/src/linux-headers-3.13.0-24/include/linux/ppp-comp.h
/usr/src/linux-headers-3.13.0-24/include/linux/seccomp.h
/usr/src/linux-headers-3.13.0-24/include/net/ipcomp.h
/usr/src/linux-headers-3.13.0-24/include/uapi/linux/ppp-comp.h
/usr/src/linux-headers-3.13.0-24/include/uapi/linux/seccomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/config/seccomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/config/crypto/pcomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/config/inet/ipcomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/config/inet6/ipcomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/config/isdn/ppp/bsdcomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/config/ppp/bsdcomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/config/xfrm/ipcomp.h
/usr/src/linux-headers-3.13.0-24-generic/include/linux/ppp-comp.h
/usr/src/linux-headers-3.13.0-24-generic/include/linux/seccomp.h
Here is my makefile:
# Requires the following project directory structure:
# /bin
# /obj
# /src
# Use 'make remove' to clean up the whole project
# Name of target file
TARGET = main
CXX = clang++
CFLAGS = -std=c++11 \
-Weverything -Wall -Wextra -Wold-style-cast -Wpointer-arith -Wcast-qual \
-Wno-missing-braces -Wempty-body -Wno-error=uninitialized \
-Wno-error=deprecated-declarations -Wno-c++98-compat \
-pedantic-errors -pedantic \
-Os -fopenmp
LINKER = clang++ -o
LFLAGS = -Wall -Weverything -pedantic
SRCDIR = src
OBJDIR = obj
BINDIR = bin
SOURCES := $(wildcard $(SRCDIR)/*.cpp)
INCLUDES := $(wildcard $(SRCDIR)/*.h)
OBJECTS := $(SOURCES:$(SRCDIR)/%.cpp=$(OBJDIR)/%.o)
RM = rm -f
$(BINDIR)/$(TARGET): $(OBJECTS)
#$(LINKER) $# $(LFLAGS) $(OBJECTS)
#echo "Linking complete!"
$(OBJECTS): $(OBJDIR)/%.o : $(SRCDIR)/%.cpp
#$(CXX) $(CFLAGS) -c $< -o $#
#echo "Compiled "$<" successfully!"
.PHONEY: prepare
prepare:
mkdir -p bin
mkdir -p obj
.PHONEY: clean
clean:
#$(RM) $(OBJECTS)
#echo "Cleanup complete!"
#$(RM) tmp_file-*
#echo "Temporary files removed!"
.PHONEY: remove
remove: clean
#$(RM) $(BINDIR)/$(TARGET)
#echo "Executable removed!"
.PHONEY: run
run:
./bin/$(TARGET)
OpenMP is well supported in Clang 3.7, but you might need to enable it see here.
OpenMP 3.1 is fully supported, but disabled by default. To enable it,
please use the -fopenmp=libomp command line option.
Also see Status of supported OpenMP constructs for more precision.
So you don't have to clone the clang-omp project any more.
What build system do you use for your project and what errors do you get when you compile?
If you use Makefile: do not forget to add the -fopenmp flag.
If you use CMake: you should also look for right OpenMP flags with the FindOpenMP module and add them accordingly.
If you still get the include error, then your omp.h header file may not be in the Clang default search path. So you should try to include the one that comes with GCC and add -I/usr/lib/gcc/x86_64-linux-gnu/4.8/include/.
So in your case you should add this line:
CFLAGS = -std=c+11 [etc...]
CFLAGS += -I/usr/lib/gcc/x86_64-linux-gnu/4.8/include/
LINKER = [etc...]
'omp.h' is a C header that comes with the "Mint" libgcc-[version]-dev (RPM-based OSes have this header in a different package, e.g. libgomp-*).
Example libgcc-4.8-dev: /usr/lib/gcc/x86_64-linux-gnu/4.8/include/omp.h
Solution: Install the version for your default GCC: gcc --version
libgcc-dev
In case the context is a build of Clang from source - one solution is to:
Ensure the openmp subproject is built by adding it to LLVM_ENABLE_PROJECTS at CMake invocation
Build that subproject with cmake --build . --target omp
Copy the generated omp.h from build/projects/openmp/runtime/src/omp.h to build/lib/clang/10.0.0/include, which is in the newly-built Clang's default search path.
I previously used the "add GCC's path to omp.h to every build command" approach, but I found this easier.
So I'm on Windows, and I'm wondering how to build a DLL and a Static Library in MingW, and in different architectures like x86 and x64. I'm new to MingW, but not C++. I've been looking around Google a while and haven't found a way to do it yet, the reason being is because most of the tutorials I find are out-of-date.
GNU 'Make' File
Sources = Test.cpp Utilities.cpp
Objects = $(Sources:.cpp=.o)
ProjName = MyProgram
BuildName = $(ProjName).dll
$(ProjName) : $(Objects)
g++ -o $(BuildName) $(Objects)
$(Objects) :
g++ -c -D TEST_DYNAMIC $(Sources)
Clean :
rm $(Objects) $(BuildName)
Addition Information
Mingw Version: 4.8.1-4
Attempts
http://www.mingw.org/wiki/sampledll
-shared is an unrecognized command.
Okay so I figured out why it wasn't working. Those sites are not out-of-date, my MingW was, but my system was using Cygwin, which is what I don't want. So I changed my 'Path' variable to direct it to the correct Mingw.
I'm trying to use the pdfium libraries in linux(debian 64-bit). I managed (finally) to compile the release _x64 version of pdfium and the test programs seem to work. However, I can't seem to to use the libraries in a separate project.
This is my file:
#include <iostream>
#include "fpdfview.h"
#include "fpdftext.h"
#include "fpdfdoc.h"
#include "fpdfedit.h"
main(){
FPDF_InitLibrary();
std::cout << "Hello World!"<<std::endl;
return 0;
}
And this is my Makefile:
CC = g++
CFLAGS = -Wall -g -Wno-unused-variable -Wno-reorder -I/usr/include/pdfium/core/include -I/usr/include/pdfium/fpdfsdk/include -I/usr/include/pdfium/third_party -I/usr/include/pdfium/v8/include
LIBS_pdfium = -static -L/usr/lib/pdfium
LDFLAGS = $(LIBS_pdfium)
Main : Main.o
${CC} ${CFLAGS} Main.o ${LDFLAGS} -o Main
Main.o : Main.cpp
${CC} ${CFLAGS} -c -std=c++11 Main.cpp
clean:
rm *o Main
When I run the makefile the result is:
g++ -Wall -g -Wno-unused-variable -Wno-reorder -I/usr/include/pdfium/core/include -I/usr/include/pdfium/fpdfsdk/include -I/usr/include/pdfium/third_party -I/usr/include/pdfium/v8/include Main.o -static -L/usr/lib/pdfium -o Main
Main.cpp:11: error: undefined reference to 'FPDF_InitLibrary'
collect2: error: ld returned 1 exit status
I've also tried to use the libraries in /home/username/pdfium/out/Release_x64/obj but got the same error
I know that error: undefined reference to FPDF_InitLibrary means that there is a linking error. Therefore I checked the libraries in /home/username/pdfium/out/Release_x64/obj using objdump and one of them contained the InitLibrary symbol. This doesn't seem to make sense...
I don't know if I am referring to the wrong paths in the include or the libraries or if it is something else that is wrong.
I tried to understand the chromiums pdf plugin project makefile since I thought that might help me understand what I am supposed to use but unfortunately it didn't help.
Any ideas for what I am doing wrong?
To compile with PDFium the link line will depend on if you've compiled V8 and/or XFA into your PDFium binary.
With neither of those things enabled you'll need something similar to:
PDF_LIBS="-lpdfium -lfpdfapi -lfxge -lfpdfdoc -lfxcrt -lfx_agg \
-lfxcodec -lfx_lpng -lfx_libopenjpeg -lfx_lcms2 -lfx_freetype -ljpeg \
-lfx_zlib -lfdrm -lpdfwindow -lbigint -lformfiller -ljavascript \
-lfxedit"
PDF_DIR=<path/to/pdfium>
clang -I $PDF_DIR/public -o foo foo.c -L $PDF_DIR/out/Debug -lstdc++ -framework AppKit $PDF_LIBS
public/ is the only directory you should use when working with PDFium for headers. The -framework AppKit is needed on OSX. The PDFium headers are in plain C but you need -lstdc++ as PDFium uses C++ internally and it needs to be able to link in new/delete.
If you're working with V8 you'll need to add in:
-lv8_libbase -lv8_libplatform -lv8_snapshot -licui18n -licuuc -licudata
and if you're using XFA you'll need the V8 includes plus:
-lfpdfxfa -lxfa -lfx_tiff
EDIT
There was recently a pdf_is_complete_lib option added to the PDFium build. Setting that to true in your gn args will create a single libpdfium that can be linked agains. Note, this has only been tested with V8 and XFA disabled.
Args file..
# Build arguments go here.
# See "gn args <out_dir> --list" for available build arguments.
is_debug = false
pdf_is_standalone = true
pdf_use_skia = false
pdf_use_skia_paths = false
pdf_enable_xfa = false
pdf_enable_v8 = false
is_component_build = false
clang_use_chrome_plugins = false
pdf_is_complete_lib = true
use_custom_libcxx = false
Then gn gen your/dir/catalog.
Then ninja -C your/dir/catalog pdfium_all and you take pdfium.a
In Linker
...
g++ -L-I/usr/include/glib-2.0 -o bin/debug/pdfium_test obj/debug/main.o
...
you must have
-pg -s -Wl,--start-group /home/a/repo/pdfium/out/release/obj/libpdfium.a -Wl,--end-group -lpthread -ldl -lpthread
Linking is ok.
I haven't personally built it - because it was too time taking. But I managed to make it work with my golang application using cgo. I used ubuntu 16.04 as my base image in docker. This depends on https://github.com/bblanchon/pdfium-binaries
Following dockerfile downloads the pdfium binary and links to the app you are developing using pkg-config.
FROM ubuntu:16.04
# Specify pdfium version
ARG PdfiumVersion=4026
# Install pkg-config, etc.
RUN apt-get -yqq update && apt-get clean && apt-get install -yqq apt-utils pkg-config tzdata && dpkg-reconfigure -f noninteractive tzdata
# Create .pc file for pkg-config
RUN echo "\n" \
"prefix=/home\n" \
"Name: pdfium\n" \
"Description: pdfium\n" \
"Version: $PdfiumVersion\n" \
"Requires:\n" \
"Libs: -L/home/lib -lpdfium\n" \
"Cflags: -I/home/include\n" > /home/pdfium.pc
# Download and extract pdfium binary
RUN cd /home && wget --quiet https://github.com/bblanchon/pdfium-binaries/releases/download/chromium%2F$PdfiumVersion/pdfium-linux.tgz \
&& tar -xf pdfium-linux.tgz && rm pdfium-linux.tgz
# Setting up paths for pkg-config
ENV LD_LIBRARY_PATH=/home/lib
ENV PKG_CONFIG_PATH=/home/
## COPY YOUR APP TO /app/src/yourApp
# BUILD YOUR APP
WORKDIR /app/src/yourApp
# RUN your app which is linked to pdfium
ENTRYPOINT [“./yourApp"]
I don't know why, but at each new version of CGAL, the procedure to compile completely changes. So, it's not even possible to recompile old piece of code (6 months old) because it doesn't work like that anymore.
I'm frankly very tired of redoing all the makefile of my projects that use CGAL each time. This time, for libcgal8, I don't find any simple substitute. Here's the makefile I was normally using:
ifndef CGAL_MAKEFILE
CGAL_MAKEFILE = /usr/local/cgal/share/cgal/cgal.mk
endif
include $(CGAL_MAKEFILE)
LIBPATH = \
$(CGAL_LIBPATH)
LDFLAGS = \
$(LONG_NAME_PROBLEM_LDFLAGS) \
$(CGAL_LDFLAGS)
COMP=-frounding-math -fopenmp -std=c++0x -l json -L$(LIBPATH) $(LDFLAGS)
EXEC=../crender
all: main.o
g++ -fPIC main.o $(EXEC) $(COMP)
main.o: main.cpp ../common/common.hpp
g++ -c main.cpp $(COMP) -o main.o
So, what do I have to change to make it work again ? If possible, a solution that will survive to the future changes of CGAL.
If it can help, here's the kind of error that I get:
In function CGAL::Gmpq_rep::Gmpq_rep()':
main.cpp:(.text._ZN4CGAL8Gmpq_repC2Ev[_ZN4CGAL8Gmpq_repC5Ev]+0x14): undefined reference to__gmpq_init'
And I get these kind of errors for other functions like "__gmpg_add", "__gmpq_sub" and "__gmpq_mul."
SOLUTION:
You need to add "-lgmp" in the compilation instruction. It's sad that it's not done by default by the makefile provided by CGAL!
(Answered in the comments and in an Edit. See Question with no answers, but issue solved in the comments (or extended in chat) )
The OP wrote:
You need to add "-lgmp" in the compilation instruction. It's sad that it's not done by default by the makefile provided by CGAL!
#sloriot Added:
Since January 2009 (release 3.4), CGAL is using cmake as build system. Since then, all include/link compiler flags are provided through the cmake mechanism (CGALConfig.cmake).
As mentioned above, now CGAL uses cmake as build system. While compiling CGAL example with cmake, I encountered similar problem. Solution is to add and link GMP library. Here is how its done for cmake: Cmake basic library linking problem
This is my makefile for linux and mac os x (no using cmake):
CPP := g++
OPCJE := -W -Wall -pedantic -O0 -Wno-c++11-extensions
BIBLIOTEKI := -lboost_math_c99 -lboost_thread -lm -lCGAL -lmpfr -lgmp
PISZ := echo -e
UNAME_S := $(shell uname -s)
on Mac os X some library are different name (brew install)
ifeq ($(UNAME_S),Darwin)
BIBLIOTEKI = -lboost_math_c99 -lboost_thread-mt -lm -lcgal -lmpfr -lgmp
PISZ = echo
endif
all source
SRC = $(wildcard *.cpp)
OBJ = $(addsuffix .o, $(basename $(SRC)))
BIN_DIR = ./bin
W_ZRODLA = $(wildcard *.cpp)
PROGRAMY = ${W_ZRODLA:%.cpp=$(BIN_DIR)/%}
$(BIN_DIR)/%: %.cpp
#mkdir -p ./bin
$(CPP) $(OPCJE) $< -o $# $(BIBLIOTEKI)
wszystkie: $(PROGRAMY)
#echo
clean:
rm -f ./bin/*
mem: 01
valgrind -v --tool=memcheck --leak-check=full ./01
This is a very basic question, I only post because I've spent already some time into it. This is what I've done so far:
Downloaded and compiled the boost library:
sudo ./bootstrap.sh and sudo ./bjam install
This way it was installed into /usr/local/lib.
In my source code I've added only:
#include <boost/asio.hpp>
using boost::asio::ip::tcp
I compile it with:
g++ -I/usr/lib/jvm/java-6-openjdk/include -L/usr/local/lib -fPIC -lboost_system -shared -o libagent.so agent.cpp
However, ldd -d ./libagent.so gives me:
libboost_system.so.1.46.1 => not found
But there is no error thrown, when using the -lboost_system and ls /usr/local/lib gets me among other things:
libboost_system.so
libboost_system.a
What am I missing?
Did the ./bjam install tool also run the ldconfig(8) tool? ldconfig(8) needs to be run after new libraries are installed to update the caches used by ld.so(8) at program execution time.
You should compile it with:
g++ -I/usr/lib/jvm/java-6-openjdk/include -L/usr/local/lib -Wl,-rpath,/usr/local/lib -fPIC -lboost_system -shared -o libagent.so agent.cpp
This makes it look for the boost library in /usr/local/lib at runtime, the -L option only makes it look in /usr/local/lib at compile time.