I have an existing Qt5.3.2 installation from tar.gz source files.
When attempting to compile VTK, which has optional Qt{4,5} interface, I was informed I don't have QtWebKitWidgets by ccmake.
I don't particularly want to reinstall Qt5 on top of the existing installation, for fear of breaking other things built against it.
Can I add to my current Qt5?
Would variants on
/path/to/configure -release -prefix $existingPrefix
make -module-qtwebkit
make install
or
/path/to/configure -release -prefix $newPrefix
make -module-qtwebkit
make install
cp -rf $newPrefix/CMake/QtWebKit (or similar path) $existingPrefix/CMake/
or as above, but with symlink, work?
Qt5.3 no longer includes QtWebKit, which should now be built separately.
The WebKit package can be downloaded from the Qt Downloads website, via the separate packages repository: link for 5.3.2
This can then be installed by appropriately setting environment variables such that the relevant (Qt5.3.2) qmake is first in the path, then from the expanded source directory, typing:
qmake
make -jN (with N make jobs)
(sudo, if appropriate) make install
The download is approximately 50MB.
Edit: It's also worth noting that if your Bison version is 3.x, then you might not be able to build the snapshot for QtWebKit. Instead download from the development repositories, to avoid an error looking something like: link to bug report
g++ -c [...] -o .obj/release-shared/generated/glslang_tab.o generated/glslang_tab.cpp
generated/glslang_tab.cpp: In function 'int yyparse(TParseContext*)':
generated/glslang_tab.cpp:1785:30: error: too few arguments to function 'int yylex(YYSTYPE*, void*)'
yychar = yylex (&yylval);
^
generated/glslang_tab.cpp:279:12: note: declared here
extern int yylex(YYSTYPE* yylval_param, void* yyscanner);
Related
I have a c++ program, which contains two classes. one of them is using libssh and some of its functions and another one is for calculating cpu usage. there is a link of how I a built and added libssh:libssh's functions couldn't be found on qt my program works fine. now I want to build a .so library out of it to use in other programs. first I made two .o file like this:
gcc -c -fPIC info.cpp -o info.o
gcc -c -fPIC cpuusage.cpp -o cpuusage.o
and I made a .so from them:
gcc -shared -o libsmc.so info.o cpuusage.o
whenever I want to use libsmc.so, I include info.h, but the problem is that libssh functions cannot be found. I think I have to add libssh statically to my project. but I don't know how to!
Ps:I read this explanation :Using a shared library in another shared library , but this is for linking shared libraries that have been used in a program via command line, I don't wanna compile program with command line and want to link libraries constantly.
To build a C/C++ software using external libraries, I would really recommend to use a build system instead of typing commands manually.
The most used build system for C++ is CMake (https://cmake.org/), which is well supported by Qt, but there are many other build systems existing. Another is QMake, which is Qt's build system.
If you are using an IDE, like QtCreator or Microsoft Visual Studio, CMake is integrated as well. There are plenty of tutorials and example to use CMake for a project (e.g. https://mirkokiefer.com/cmake-by-example-f95eb47d45b1), even though the learning curve is not as steep as I would want.
But if you still want to use command line (or to debug the command line generated by CMake): When linking against a library, you need to:
Give the include path to the compiler, i.e. the path where the .h of the external library can be found. With gcc, this is done with -I, e.g. "-I/usr/lib/mylib/include".
Give the library folder and name to the linker, i.e. the path where to find the compiled library, as well as its name. With gcc, this is done with -L for the path and -l for the name. Check the gcc manual for more details about these commands.
And if you want to use CMake, then you can use the functions:
target_include_directories(..)
and
target_link_libraries(..)
Background: I compile bitcoind on one system but run it on another. When I compiled bitcoind 0.19.1 some time back using the following method, I was able to run bitcoind and bitcoin-cli on the target system without issue. I think.
./autogen.sh
./configure --disable-wallet --disable-tests --disable-bench --disable-gui --enable-util-tx=no --prefix=$HOME/bitcoind/x64 --exec-prefix=$HOME/bitcoind/x64
make && make install
Today I compiled v0.20.0 using the same method. If I run ./bitcoind -version on the system I compiled the binary it runs fine, but if I take the binary to my target system I get the following error:
./bitcoind: error while loading shared libraries: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
The binary seemed to be portable last time, and the pre-compiled binary I download from the Bitcoin Core team runs fine.
Note that on the target system libboost-filesystem-dev and libboost-filesystem1.67-dev are not installed, this is likely the source of my error. That said, running the pre-compiled binary from the Core team runs, so why doesn't mine?
Can someone help me understand if I did something wrong or if I need to add ./configure flags to make the binary more portable? Specifically what I likely did differently than the core developers that made my binary fail where theirs worked?
EDIT 1: Running ./configure --enable-static or ./configure LDFLAGS=-static does not result in a portable binary either.
Also note that installing libboost-filesystem library with apt does fix the error.
Thanks to Andrew Chow for his helpful answer to this on the bitcoind StackExchange. I needed to build the depends as per the depends documentation. Since I'm building for the same platform I'll be running on, I can run make in the depends directory with no arguments except -j2 which uses two cores. Change the number to however many cores you want to commit to the compile.
cd depends
make -j2
cd ..
./autogen.sh
./configure --prefix=$PWD/depends/x86_64-pc-linux-gnu
make -j2 && make install
My environment is below.
・Operating System and version:windows 10 64bit
・Compiler:C:\msys64\mingw64\bin\g++.exe
・PCL Version:1.9.1
pcl_config.h not found as below error occurred when compiled under above env..
Certainly this header file is not included.
Let me know how to solve it.
PS C:\pcl\pcl\examples\common> g++ -o minmax -I ../../io/include -I ../../common/include .\example_get_max_min_coordinates.cpp
In file included from ../../common/include/pcl/PCLHeader.h:10,
from ../../common/include/pcl/point_cloud.h:47,
from ../../io/include/pcl/io/pcd_io.h:42,
from .\example_get_max_min_coordinates.cpp:2:
../../common/include/pcl/pcl_macros.h:64:10: fatal error: pcl/pcl_config.h: No such file or directory
#include
^~~~~~~~~~~~~~~~~~
compilation terminated.
Short answer
pcl_config.h is generated via pcl_config.h.in by the cmake tool. So it seems that compilation did not finish correctly.
Longer answer
Please make sure you have compiled the relevant modules of PCL (at least pcl-core) before proceeding
You might prefer a pre-built installation from releases or distributed by a package/source manager of your choice
PCL makes heavy use of other libraries and it is best to supply the dependencies (as mentioned below) via CMake or manually via the -I and -l options. If you provide the location of pcl_config.h, the compiler will complain about Eigen next.
The build instructions are available here. TL;DR: After satisfying the dependencies (cmake, c++ compiler, boost, eigen, flann, vtk and other depending on use-case), run the following commands
cd $PCL_SOURCE_DIR
mkdir -p build; cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make -j8
Feel free to use any build generator (like Ninja) or change build type to Debug or RelWithDebInfo as per your needs.
I am a little bit confused on how to efficiently prepare the R package, so that it will be compatible across all needed system platforms. This is needed so that the new version of package will be accepted by CRAN. The main difficulty comes from compiling external C++ shared library, and optionally CUDA version if the compiler is available. To support this flow I've created specific Makefile, unfortunately using GNU-extensions. It works fine on Linux, OSX and when executed manually via gmake on Solaris. Relevant part is here:
# Checking whether nvcc compiler is available
NVCC_TEST = $(shell basename $(shell which nvcc 2> /dev/null)"")
ifeq ($(NVCC_TEST),nvcc)
ALL_LIBS += libcucubes_gpu.so
ALL_OBJS += $(GPU_OBJS)
ALL_FLAGS += $(GPU_FLAGS)
else
ALL_OBJS += gpu_fallback.o
endif
Turns out that, when running R CMD INSTALL (...) on Solaris, the installation fails on something like this:
make: Fatal error in reader: Makefile, line 39: Unexpected end of line seen
ERROR: compilation failed for package 'libcucubes'
As it turns out, it is caused by the fact that Solaris' version of make is executed instead of GNU-compatible gmake (I've tested it works fine), even though it is available. My question is whether there is any simple way to force usage of gmake here, for the R package build. In general I know I could use autotools to solve compatibility issues during installation, but it seems to bring too much complexity for that simple case. Any advices will be really appreciated, thanks!
If you can't get your build process to use gmake instead of Solaris's pure POSIX make, you can use this hack:
Make a dedicated directory for this hack: mkdir $HOME/make_hack
Softlink gmake asmakein that directory: ln -s /path/to/gmake $HOME/make_hack/make
Set your PATH: PATH=$HOME/make_hack:$PATH
Now, run your build process using that PATH, and it should use gmake. Hopefully it just uses make from its PATH envval and not some hardcoded full path.
Yeah, it's a hack. But it's probably a lot easier than modifying the build process to use gmake instead of make.
From Writing R Extensions:
If you really must require GNU make, declare it in the DESCRIPTION
file by
SystemRequirements: GNU make
and ensure that you use the value of environment variable MAKE (and
not just make) in your scripts.
configure scripts are the preferred solution though. BTW, in general a Makevars file is also preferred over a full Makefile.
The readline library allows the CLI for sqlite to accept arrow keys to recall previously typed commands. I can build without this and sqlite works, it's just a hassle not having this nice capability. I've installed readline-devel from yum and /usr/lib64/libreadline.so.5 is present as well as it's header files. When I run ./configure to build sqlite, I see these lines:
checking for library containing readline... no
checking for readline... no
The library path is set to the correct path:
LD_LIBRARY_PATH="/usr/lib64:/usr/local/lib:/lib:/usr/lib"
By default, ./configure does try to include readline support so there are no special "--with-XXXX" options needed.
Anyone every seen this problem? I need to use this newer version to get latest foreign key support. It's hassle running on CentOS as is bundles pretty old versions of apps but we don't have a choice right now and I cannot find an updated RPM with newer version of sqlite.
=== UPDATE ===
Ok, I found a solution but I don't completely like it...
First, I tried with this option:
./configure CPPFLAGS="-I/usr/include/ -DHAVE_READLINE"
That causes the readline functionality to get compiled into shell.c which is what is needed for starters. But, the linking fails because it cannot find libreadline. The only 'kludgy' way I could figure out to get it to link was to manually edit the Makefile after running the above ./configure command. I changed this line:
LIBS = -ldl -lpthread
to this:
LIBS = -ldl -lpthread -lreadline -ltermcap
Then I ran "make clean all" and "make install" and the readline functionality works in the CLI.
I tried every way I could think of to pass in the extra libraries including exporting using LIBS, exporting using READLINE_LIBS, exporting using LDFLAGS, nothing would work. If you set LIBS to anything, like "export LIBS="-lreadline", it causes configure to fail. The --help on configure about using LIBS seems to contradict what happens when you actually set it to any value.
Anyway, this works so I can live with it - but I don't particularly like it! :(
==== THE RIGHT SOLUTION ====
Well, wouldn't you know it. Spend hours trying to figure it out, then stumble onto the right tip on Google. Just needed to install ncurses-devel first. So, to summarize all that is needed to built it 'unkludgily':
yum install ncurses ncurses-devel
yum install readline readline-devel
yum install libtermcap libtermcap-devel
./configure
make
make install
No special command line options or exports or Makefile edits needed! Readline support is automatically built in by default now.