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.
Related
I'm trying to compile glibc (CORRECTION: 2.34, not 2.3.4) on a RedHat system. I get this error while trying to run configure:
*** These critical programs are missing or too old: make compiler
*** Check the INSTALL file for required versions.
I installed the latest version of 'make':
> make --version
GNU Make 4.3
However, even with the latest version of 'make', I still get the same error. What is causing the problem?
glibc's configure prefers gnumake and gmake over make if they are available on the PATH command search path. Chances is that you have gmake binary that is version 3.81.
I think you should make with gcc version 6.5.0,
ct-ng may help you to build glibc. ct-ng http://crosstool-ng.github.io/docs/
1. ct-ng menuconfig
2. ct-ng build
You can choose gcc version at step 1.
As an reminder, glibc-2.34 remove some libs and no longer create like *-2.33.so under dir sysroot/lib/ . link:https://lwn.net/Articles/864920/
I ran into this issue as well and noticed that the config.txt was looking for gmake and found it in /usr/bin/gmake which was strange.
Listing shows that there is a symlink to make.
ls -l /usr/bin/gmake
lrwxrwxrwx. 1 root root 4 Jun 11 18:18 /usr/bin/gmake -> make
I installed make 4.3 in a custom path AND ensured that it was on $PATH but I was still getting the same error. Making a symlink to my custom installed version of make resolved the problem.
ln -s <custom path>/bin/make <custom path>/bin/gmake
Solved this by setting the MAKE variable. When looking in the configure script, it checks against "if test -n "$MAKE"; then", i.e.
MAKE=//make
export MAKE
I am running Arch Linux and trying to build a project in Qt however, Qt spits the following error:
/opt/cuda/include/crt/host_config.h:129: error: #error -- unsupported GNU version! gcc versions later than 7 are not supported!
I have already tried a suggestion from a previous Stack Overflow post found here:
CUDA incompatible with my gcc version
I did not use the exact command as my cuda is located in /opt/cuda/bin/gcc. I did the same command for g++. However, the terminal outputs that these files are already linked. I did confirm this by going to the actual file and looking at it's properties.
Can someone please suggest a solution to my issue?
I managed to do so usung this two lines, this will update the symbolic links of cuda to gcc7
ln -s /usr/bin/gcc-7 /usr/local/cuda/bin/gcc
ln -s /usr/bin/g++-7 /usr/local/cuda/bin/g++
The issue comes from cuda-10.0/targets/x86_64-linux/include/crt/host_config.h in the main CUDA-10 directory tree. The target for your architecture was placed in /opt.
Some posts recommend faking the inequality
if __GNUC__ > 7
to say
if __GNUC__ > 8
but that is a bad idea. Using
make 'NVCCFLAGS=-m64 -D__GNUC__=7' -k
is permissible in some trivial cases, but still fundamentally the same bad hack.
You probably have alternates on your system which has constructed symbolic links pointing to the version 8 gnu tool chain files. That's why you get an indication version 7 is already installed.
You can learn how to modify your alternates for just your developer users BUT NOT for root or any system admin accounts. You may want to remember how to switch back and forth between 7 and 8 so you only use 7 when actually needed, since many other things may be tested only with 8.
If that doesn't work for you, you can build gcc-7 from source. The preparatory system admin work includes a dnf install, a build from source, an install of 7.4 gnu compiler, and a set up of paths for CUDA development only. If you have gnu gcc and g++ version 8 installed with the appropriate standard libraries and it works, the version 7 compiler can be installed with relative ease.
Browse and find the nearest mirror listed on https://gcc.gnu.org/mirrors.html and then copy the link location for gcc-7.4.0.tar.xz and place it in the shell variable u like this example.
u="http://mirrors.concertpass.com/gcc/releases/gcc-7.4.0/gcc-7.4.0.tar.xz"
Then you can do the rest as commands.
sudo dnf install libmpc-devel
cd
mkdir -p scratch
cd scratch
wget -O - "$u" |tar Jxf -
cd gcc-7.4.0
mkdir build
cd build
../configure --prefix=/usr/local/gcc-7
make
sudo bash -c "cd \"`pwd`\"; make install"
Then you execute this in the shells and tools you develop with. Do NOT put this in the system login apparatus or in .bashrc or .bash_profile, for the same reason as above. Other things may be tested with version 8 only. Instead place them in your development environment where they belong.
LD_LIBRARY_PATH=/usr/local/gcc-7/lib64:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/gcc-7/lib:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/cuda-10.0/NsightCompute-1.0/host/linux-desktop-glibc_2_11_3-glx-x64/Plugins:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/cuda-10.0/NsightCompute-1.0/target/linux-desktop-glibc_2_11_3-glx-x64:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/cuda-10.0/targets/x86_64-linux/lib/stubs:$LD_LIBRARY_PATH
PATH=/usr/local/gcc-7/bin:$PATH
PATH=/usr/local/cuda-10.0/bin:$PATH
PATH=$HOME/big/cuda.samples/NVIDIA_CUDA-10.0_Samples/bin/x86_64/linux/release:$PATH
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.
I want to use sqlite with the json extension so I've installed it with homebrew. When I run which sqlite though, the one that is being used is the anaconda install. If I try and use pythons sqlite library I have the same issue. It's linked to the Anaconda version and the JSON functions aren't available. How do I replace this with the brew version? Brew provided some values when I installed sqlite but I don't know if I need them or how they are used.
LDFLAGS: -L/usr/local/opt/sqlite/lib
CPPFLAGS: -I/usr/local/opt/sqlite/include
PKG_CONFIG_PATH: /usr/local/opt/sqlite/lib/pkgconfig
Sqlite installed by Homebrew is keg-only, which is not linked to /usr/local/... .
This is because system already have older version of sqlite3.
If you really want to invoke Homebrew's sqlite binary, specify full path as below.
$ /usr/local/opt/sqlite/bin/sqlite3
(All Homebrew package is symlinked under /usr/local/opt)
I'm not so familiar with python, but AFAIK sqlite is statically linked to python executable.
In other words, maybe you have to build python from source to use with Homebrew's sqlite.
The answer by equal-l2 is correct. Also, the comment under it by Keith John Hutchison.
But, since they are from quite a few years ago and there is not an officially accepted answer still, here you go as this still catches you off-guard in 2022.
To fix, add this to your ~/.zshrc file and you should be good:
export PATH=/usr/local/opt/sqlite/bin:$PATH
Remember to have $PATH at the end like the above and not at the beginning like so:
export PATH=$PATH:/usr/local/opt/sqlite/bin
as the shell traverses your $PATH for command completion left to right and stops at the first instance found and obviously you want your desired path to be considered first.
Also, you might need to run source ~/.zshrc and rehash if you want it to just start working in the same terminal session.
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);