I tried the instructions of building latest QT5-Alpha(http://qt-project.org/wiki/Qt-5-Alpha
http://qt-project.org/wiki/Building_Qt_5_from_Git)
from GIT,but facing compilation in wayland files
Ubuntu Linux 11.10
__make[4]: Entering directory `/home/xyz/build/newqt5/qt5/qtwayland/src/plugins/platforms/wayland'
g++ -c -pipe -g -fvisibility=hidden -fvisibility-inlines-hidden -D_REENTRANT -Wall -W -fPIC -DQT_NO_LIBUDEV -DQ_PLATFORM_WAYLAND -DQT_NO_WAYLAND_XKB -DQT_WAYLAND_GL_SUPPORT -DQT_WAYLAND_WINDOWMANAGER_SUPPORT -DQ_FONTCONFIGDATABASE -DQT_COMPILES_IN_HARFBUZZ -DQT_PLUGIN -DQT_GUI_LIB -DQT_CORE_LIB -I/home/xyz/build/newqt5/qt5/qtbase/mkspecs/linux-g++ -I. -I/home/xyz/build/newqt5/qt5/qtbase/include/QtCore/5.0.0 -I/home/xyz/build/newqt5/qt5/qtbase/include/QtCore/5.0.0/QtCore -I/home/xyz/build/newqt5/qt5/qtbase/include/QtCore -I/home/xyz/build/newqt5/qt5/qtbase/include/QtGui/5.0.0 -I/home/xyz/build/newqt5/qt5/qtbase/include/QtGui/5.0.0/QtGui -I/home/xyz/build/newqt5/qt5/qtbase/include/QtGui -I/home/xyz/build/newqt5/qt5/qtbase/include/QtPlatformSupport/5.0.0 -I/home/xyz/build/newqt5/qt5/qtbase/include/QtPlatformSupport/5.0.0/QtPlatformSupport -I/home/xyz/build/newqt5/qt5/qtbase/include/QtPlatformSupport -I/home/xyz/build/newqt5/qt5/qtbase/include -I../../../shared -Igl_integration/xcomposite_share -I.moc/debug-shared -o .obj/debug-shared/qwaylandintegration.o qwaylandintegration.cpp
In file included from qwaylandshmwindow.h:45:0,
from qwaylandintegration.cpp:46:
qwaylandwindow.h:112:18: error: ‘wl_callback_listener’ does not name a type
make[4]: *** [.obj/debug-shared/qwaylandintegration.o] Error 1_
Any pointers to overcome this?
Download the alpha source package here: http://releases.qt-project.org/qt5.0/alpha/ and use the steps in README file.
The master in git is NOT what was released as alpha. The build scripts are different. You have to wait for them to add alpha tag to pull it from git. But why not just grab the gz file?
Related
I have tried this on multiple platforms, experiencing the same issue every time.
I successfully build and run my C++ OpenFrameworks application using QtCreator - no problems are encountered.
Then, I successfully use qmake to generate the project file.
Yet when I attempt to make the executable, I receive the following error:
make
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -c -pipe -stdlib=libc++ -O2 -std=gnu++1z -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -mmacosx-version-min=12 -Wall -Wextra -fPIC -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I. -I. -I/opt/homebrew/lib/QtGui.framework/Headers -I/opt/homebrew/lib/QtCore.framework/Headers -I. -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/AGL.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/AGL.framework/Headers -I/opt/homebrew/share/qt/mkspecs/macx-clang -F/opt/homebrew/lib -o main.o src/main.cpp
src/main.cpp:1:10: fatal error: 'ofMain.h' file not found
#include "ofMain.h"
^~~~~~~~~~
1 error generated.
make: *** [main.o] Error 1
I can go into the .pro file and add things to the include path manually, but I don't see why these includes aren't generated automatically?
I think I recognized your problem.
The file name is main.cpp in the src/ folder. Based on its location in the src/ folder, I think your ofMain.h file is also in the src/ folder. Now a question: did you add src/ to your include path? If not with the following line:
INCLUDEPATH += \
src/
It should work now I hope.
Have a nice day!
I often install R packages from source, and need a properly configured ~/.R/Makevars to do this. I want to be able to use OpenMP, so I copied a Makevars I found online. My Makevars ended up being this:
OPT_LOC = $(HOME)/homebrew/opt
LLVM_LOC = $(OPT_LOC)/llvm
CC=$(LLVM_LOC)/bin/clang
CXX=$(LLVM_LOC)/bin/clang++
# CFLAGS and CXXFLAGS *with* -fopenmp
CFLAGS=-fopenmp -g -O3 -Wall -pedantic -std=gnu99 -mtune=native -pipe
CXXFLAGS=-fopenmp -g -O3 -Wall -pedantic -std=c++11 -mtune=native -pipe
# CFLAGS and CXXFLAGS *without* -fopenmp
# (sometimes the package install process fails if -fopenmp is present)
# CFLAGS=-g -O3 -Wall -pedantic -std=gnu99 -mtune=native -pipe
# CXXFLAGS=-g -O3 -Wall -pedantic -std=c++11 -mtune=native -pipe
LDFLAGS=-L$(OPT_LOC)/gettext/lib -L$(LLVM_LOC)/lib -Wl,-rpath,$(LLVM_LOC)/lib
CPPFLAGS=-I$(OPT_LOC)/gettext/include -I$(LLVM_LOC)/include
I can no longer find the original source of my version, but it's similar to this one.
My Makevars works great, except for a few packages, like stringi. These packages complain that "C compiler cannot create executables". I discovered that this error generally goes away if I remove -fopenmp from CFLAGS and CXXFLAGS. As you can see, I've set up Makevars so I can easily switch back and forth between the configuration with -fopenmp and without it.
My workaround works fine, as does the workaround of "delete Makevars entirely" in the Stack Overflow post linked above. But isn't there a better way? It's annoying that I can't expect package installs to succeed because of these dependencies that hate the -fopenmp flag, while removing the flag means I might miss out on OpenMP on some package installs.
If you use GCC instead of Clang you should be able to install stringi with OpenMP enabled. I've tested a number of different solutions and ultimately came up with these steps to successfully install stringi from source with the -fopenmp flag (Intel macOS v11 (Big Sur)):
Reinstall the Xcode command line tools (don't believe Software Update if it says 'up to date' - it lies - brew doctor said my version was actually old)
sudo rm -rf /Library/Developer/CommandLineTools
sudo xcode-select --install
Install GCC and LLVM via Homebrew (instructions for installing Homebrew) or, if you already have GCC/LLVM installed, skip to the next step.
# WARNING: This can take several hours
brew install gcc
brew install llvm
If you already have GCC and LLVM installed via Homebrew:
brew cleanup
brew update
brew upgrade
brew reinstall gcc
brew reinstall llvm
Link some headers into /usr/local/include
sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* /usr/local/include/
# I believe you can safely ignore warnings like this:
#ln: /usr/local/include//tcl.h: File exists
#ln: /usr/local/include//tclDecls.h: File exists
#ln: /usr/local/include//tclPlatDecls.h: File exists
#ln: /usr/local/include//tclTomMath.h: File exists
#ln: /usr/local/include//tclTomMathDecls.h: File exists
#ln: /usr/local/include//tk.h: File exists
#ln: /usr/local/include//tkDecls.h: File exists
#ln: /usr/local/include//tkPlatDecls.h: File exists
Edit your ~/.R/Makevars file (if you don't have a file called Makevars in your ~/.R/ directory, create it) and include only these lines:
LOC = /usr/local/gfortran
CC=$(LOC)/bin/gcc -fopenmp
CXX=$(LOC)/bin/g++ -fopenmp
CXX11 = $(LOC)/bin/g++ -fopenmp
CFLAGS=-g -O3 -Wall -pedantic -std=gnu99 -mtune=native -pipe
CXXFLAGS=-g -O3 -Wall -pedantic -std=c++11 -mtune=native -pipe
LDFLAGS=-L$(LOC)/lib -Wl,-rpath,$(LOC)/lib
CPPFLAGS=-I$(LOC)/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
FLIBS=-L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin19/10.2.0 -L/usr/local/gfortran/lib -lgfortran -lquadmath -lm
CXX1X=/usr/local/gfortran/bin/g++
CXX98=/usr/local/gfortran/bin/g++
CXX11=/usr/local/gfortran/bin/g++
CXX14=/usr/local/gfortran/bin/g++
CXX17=/usr/local/gfortran/bin/g++
Compile a package from source in R/RStudio
# Test if OpenMP is actually enabled
install.packages("data.table", type = "source")
# (loading data.table will tell you if it was successful)
# Compile the stringi package from source
install.packages("stringi", type = "source")
NB: Some users have commented that they had to install a 'fresh' GFortran (e.g., GFortran 10.2 for Big Sur (macOS 11), for Intel processors) to compile packages successfully, and others have commented that they didn't need LLVM, but these steps seem to work in most cases.
Update (2022/04/05)
I recently had an error when updating "RcppAlgos" using this ~/.R/Makevars (couldn't find gmp.h or libgmp). I checked gmp was installed (brew install gmp), then added /usr/local/include to CPPFLAGS and /usr/local/lib to LDFLAGS in the ~/.R/Makevars file to solve the problem, and hopefully prevent similar issues in the future, i.e. edit your Makevars to contain these lines only:
LOC=/usr/local/gfortran
CC=$(LOC)/bin/gcc -fopenmp
CXX=$(LOC)/bin/g++ -fopenmp
CXX11 = $(LOC)/bin/g++ -fopenmp
CFLAGS=-g -O3 -Wall -pedantic -std=gnu99 -mtune=native -pipe
CXXFLAGS=-g -O3 -Wall -pedantic -std=c++11 -mtune=native -pipe
LDFLAGS=-L$(LOC)/lib -Wl,-rpath,$(LOC)/lib,-L/usr/local/lib
CPPFLAGS=-I$(LOC)/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -I/usr/local/include
FLIBS=-L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin19/10.2.0 -L/usr/local/gfortran/lib -lgfortran -lquadmath -lm
CXX1X=/usr/local/gfortran/bin/g++
CXX98=/usr/local/gfortran/bin/g++
CXX11=/usr/local/gfortran/bin/g++
CXX14=/usr/local/gfortran/bin/g++
CXX17=/usr/local/gfortran/bin/g++
I am trying to set up Travis-CI to build this R package. The package builds locally with the following steps that closely mirror the build process on Travis (failed build here):
git clone --depth=50 --branch=master https://github.com/weinstockj/htslibr.git weinstockj/htslibr
cd weinstockj/htslibr/
git submodule update --init --recursive
cd htslibr/
R -e 'install.packages("Rcpp")'
R CMD build .
Travis fails with an error that suggests it cannot find a header file that is in a sub-directory of htslibr/src. Why does R CMD build fail to find the header on Travis (again, no issue locally)?
Travis set up is here , and locally I am also using Ubuntu 16.04.
Here an extract from the failed build log:
mkdir -p /tmp/Rtmpy1bhv4/Rinst23036acf1e4/htslibr/inst/include
cp htslib/htslib/*.h /tmp/Rtmpy1bhv4/Rinst23036acf1e4/htslibr/inst/include
g++ -std=gnu++11 -I"/home/travis/R-bin/lib/R/include" -DNDEBUG -I"/usr/local/lib/R/site-library/Rcpp/include" -I/home/travis/R-bin/include -fpic -g -O2 -c RcppExports.cpp -o RcppExports.o
g++ -std=gnu++11 -I"/home/travis/R-bin/lib/R/include" -DNDEBUG -I"/usr/local/lib/R/site-library/Rcpp/include" -I/home/travis/R-bin/include -fpic -g -O2 -c util.cpp -o util.o
util.cpp:2:24: fatal error: htslib/hts.h: No such file or directory
We see that while the headers are copied to /tmp/Rtmpy1bhv4/Rinst23036acf1e4/htslibr/inst/include, this directory is not on the include path. You can fix this by adding
PKG_CPPFLAGS = -I../inst/include -DSTRICT_R_HEADERS
to Makevars (STRICT_R_HEADERS is not needed but "best practice") and using #include <hts.h> in util.cpp. However, I am not convinced that it is correct to copy the header files to inst/include in the first place. After all, these header files do not represent an API that your packge is providing to other packages. Instead, it is the API of a library that you package uses internally. I would therefore suggest to not copy the header files and use
PKG_CPPFLAGS = -Ihtslib -DSTRICT_R_HEADERS
in Makevars.
BTW, Writing R Extensions advocates a different usage pattern for the targets:
all: $(SHLIB)
$(SHLIB): <any other needed targets>
Though this point is irrelevant if you follow my suggestion to not copy the headers.
I am trying to build a mapnik 2.2.0 RPM file on my RHEL/CENTOS 7 machine.
so I took the RPM SRC file from Fedora 22 which is mapnik-2.2.0-11.fc21.src.rpm ( I have the same result with mapnik-2.2.0-5.fc20.src.rpm )
when I am running the rpmbuild I receive the following error message:
Welcome to Mapnik...
scons: warning: Ignoring missing SConscript 'deps/agg/build.py'
File "/root/rpmbuild/BUILD/mapnik-v2.2.0/SConstruct", line 1799, in <module>
scons: warning: Ignoring missing SConscript 'deps/mapnik/build.py'
File "/root/rpmbuild/BUILD/mapnik-v2.2.0/SConstruct", line 1808, in <module>
scons: done reading SConscript files.
scons: Building targets ...
g++ -o bindings/python/mapnik_building_symbolizer.os -c -ansi -Wall -pthread -ftemplate-depth-300 -O3 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fno-strict-aliasing -finline-functions -Wno-inline -Wno-parentheses -Wno-char-subscripts -fPIC -DHAVE_JPEG -DMAPNIK_USE_PROJ4 -DHAVE_PNG -DHAVE_TIFF -DBIGINT -DBOOST_REGEX_HAS_ICU -DLINUX -DMAPNIK_THREADSAFE -DNDEBUG -DHAVE_CAIRO -DHAVE_PYCAIRO -I. -Iinclude -I/usr/include/polyclipping -I/usr/include/agg2 -I/usr/include -I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/include/gdal -I/usr/include/python2.7 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/libpng15 -I/usr/include/libdrm -I/usr/include/pycairo bindings/python/mapnik_building_symbolizer.cpp
In file included from include/mapnik/symbolizer.hpp:29:0,
from include/mapnik/building_symbolizer.hpp:29,
from bindings/python/mapnik_building_symbolizer.cpp:26:
include/mapnik/image_compositing.hpp:74:19: error: 'comp_op_grain_merge' is not a member of 'agg'
grain_merge = agg::comp_op_grain_merge,
^
include/mapnik/image_compositing.hpp:75:21: error: 'comp_op_grain_extract' is not a member of 'agg'
grain_extract = agg::comp_op_grain_extract,
^
scons: *** [bindings/python/mapnik_building_symbolizer.os] Error 1
scons: building terminated because of errors.
error: Bad exit status from /var/tmp/rpm-tmp.kuI6KW (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.kuI6KW (%build)
Mapnik normally comes with a heavily patched version of the AGG library right there in its source tree. The Fedora build however disables that in favour of having the Mapnik-AGG patches directly in its own AGG package (because they don't like duplicating system libraries elsewhere).
You either need an AGG library for CentOS that is feature-compatible with the patched Fedora version, or you have to modify your Mapnik build to disable the "system_agg" patch (and drop the "rm -rf boost deps" from the spec file).
I built a Qt project in Debug mode with Qt Creator, ran Callgrind to generate profiling data and tried loading it into Cachegrind. I noticed that I only see profiling information for Qt classes, so I figured I must have forgotten to turn on a crucial flag.
Qt Creator's qmake command looks like this:
qmake /path/to/project/MyProject/MyProject.pro -r -spec linux-g++-64 CONFIG+=debug
Sample compile output for one file:
g++ -c -m64 -pipe -g -Wall -W -D_REENTRANT -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -I../Flowchart -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include -I. -I. -I../Flowchart -I. -o main.o ../Flowchart/main.cpp
The -g flag is there, so debug information should be available. I verified this by running gdb on the executable and trying to look at some random source code with l.
The Callgrind command I used was:
valgrind --tool=callgrind ./MyProject
What am I missing here?
You should do:
valgrind --tool=callgrind --trace-children=yes --demangle=yes ./MyProject
Also depending on the distribution of Linux you may have to make sure that you have the Debug information in the QT libraries you are linking against.