I need help with installing a software.
In general: I try to install PostGIS on a cluster (CentOS) and do not have admin rights. There is a sqlite3 installation (connected to the error), but this seems corrupt. My own one usually works and has (also by install-process) been used previously.
I cannot use yum.
In detail:
For having the MakeFiles build I set flags as I believe to possibly need them:
./configure --prefix="$HOME/.local" CFLAGS="-I$HOME/.local/include" LDFLAGS="-L$HOME/.local/lib" LT_SYS_LIBRARY_PATH="$HOME/.local/lib" LIBS="-L$HOME/.local/lib" SQLITE3_CFLAGS="-I$HOME/.local/include" SQLITE3_LIBS="-L$HOME/.local/lib"
But the following error is thrown when running make:
/usr/bin/sed: can't read /usr/local/lib/libsqlite3.la: No such file or directory
libtool: error: '/usr/local/lib/libsqlite3.la' is not a valid libtool archive
Right after (but I don't see the connection):
libtool: link: ranlib .libs/liblwgeom.a
If I run make again, it jumps that directory. But gets stuck with a similar error (which is not jumped by running make another time):
/bin/sh ../../libtool --mode=link gcc -Wall -Wmissing-prototypes -std=gnu99 -I<exp. $HOME>/.local/include -fno-math-errno -fno-signed-zeros -fPIC -DPIC -I../rt_core -I../../liblwgeom -I<exp. $HOME>/.local/include -I/usr/include/gdal -I<exp. $HOME>/.local/include ../rt_core/librtcore.a raster2pgsql.o -L<exp. $HOME>/.local/lib -static ../../liblwgeom/liblwgeom.la -L/usr/lib64 -lgdal -L<exp. $HOME>/.local/lib -lgeos_c -lc -lm -o raster2pgsql
libtool: error: cannot find the library '/usr/local/lib/libsqlite3.la' or unhandled argument '/usr/local/lib/libsqlite3.la'
I don't get why libtool searches in '/usr/local/lib/'. I didn't find that hardcoded in libtool or the MakeFiles. I'm clueless - and this is above my skill (apperently).
Can you help me?
One of the dependencies (proj) linked in its .la file to the malicious sqlite3 version. Reinstalling this dependency solved the issue.
What would help in similar cases would be to search the 'wrong path' in the dependencies:
find <deps lib dir> -type f -exec grep -l "<wrong path>" {} +
Kudos go to https://stackoverflow.com/a/62500481/14339502 who stated the valuable hint that "it seems like you have some other .la file that references it".
Related
When I search I found 7yr old results talking about a fork of clang instead of clang itself.
Using avr-gcc I can compile and upload my code with
avr-gcc a.cpp -DF_CPU=16000000 -mmcu=atmega2560 -Wall -Werror -Wextra -Os
avr-objcopy -j .text -j .data -O ihex a.out my.hex
sudo avrdude -patmega2560 -cwiring -P/dev/ttyACM0 -b115200 -D -Uflash:w:my.hex:i
I'd like to replace the first step with clang++. The changes I made here
avr-gcc to clang++
Added --target=avr
Added -nostdlib because I'll include it myself
Added -I/usr/avr/include/ because path wasn't implicit
Added -L/usr/avr/lib/avr6 -lc -latmega2560 so it has enough info to build an elf
I found device-specs at /usr/lib/gcc/avr/10.2.0/device-specs/specs-atmega2560 which mentions crtatmega2560.o and -latmega2560 which appears to be located at /usr/avr/lib/avr6/. So I came up with the following and got these errors. How should I be compiling so I can get a hex to upload using avrdude?
$ clang++ a.cpp -DF_CPU=16000000 -mmcu=atmega2560 -Wall -Werror -Wextra -Os --target=avr -I/usr/avr/include/ -nostdlib -L/usr/avr/lib/avr6 -lc -latmega2560
/usr/bin/avr-ld: skipping incompatible /usr/avr/lib/avr6/libc.a when searching for -lc
/usr/bin/avr-ld: cannot find -lc
/usr/bin/avr-ld: skipping incompatible /usr/avr/lib/avr6/libatmega2560.a when searching for -latmega2560
/usr/bin/avr-ld: cannot find -latmega2560
AVR target is experimental in LLVM compiler for which clang is the C and C++ front-end. To enable experimental targets you must compile LLVM from source. This Stack Overflow answer describes how to do it.
Looking at the bug tracker I see there are good reasons why it is experimental.
I am not sure what to answer finally.
Probably it is not the worst idea to compile .o file with clang, and link everything manually just like you wish.
I am not sure, if it is needed to enable any experiment features, due I tried to compile something to AVR, and it works fine with clang-12 when I use llvm repository apt.llvm.org.
still facing some strange compilation error while using MSYS2 mingw64 to compile OpenLDAP
I think it boils down to some win socket thing, currently facing 2 major errors during make depend and make
during make depend
cannot locate nt_err.c in servers/slapd/slapi ==> I resorted to copy nt_err.c from libraries/liblber/nt_err.c
Then came the fatal error while make depend in slapi. Command used by make depend: make -w -I/usr/include -I/usr/include -I/usr/include -I/usr/include depend, it maybe because I have passed -I/usr/include in the main make depend
but still
Entering directory '/home/Jimmy/openldapsrc/openldap-2.4.46/servers/slapd/slapi'
../../../build/mkdep -l -d "." -c "cc" -m "-M" -I../../../include -I.. -I. -I../../../include -I./.. -I. plugin.c slapi_pblock.c slapi_utils.c printmsg.c slapi_ops.c slapi_dn.c slapi_ext.c slapi_overlay.c nt_err.c
In file included from slapi_utils.c:34:0:
../../../include/netdb.h:73:10: fatal error: netinet/in.h: No such file or directory
#include <netinet/in.h>
^~~~~~~~~~~~~~
compilation terminated.
And actually I have seen a lot of similar errors, for example during make it will also give error in slapi like
No such file or directory
#include <sys/socket.h>
^~~~~~~~~~~~~~
compilation terminated.
I have checked with pacman -Fs in.h socket.h the output are as follow
msys/msys2-runtime-devel 2.10.0-2
usr/include/cygwin/in.h
usr/include/netinet/in.h
usr/include/sys/socket.h
and I have msys2-runtime-devel installed. Nonetheless this reminded me that during ./configure output contained
checking sys/socket.h usability... no
checking sys/socket.h presence... no
so Ｉ tried to run gcc -xc -E -v - trying to determine what directory is included, however in MSYS2-MINGW64 it stopped at this
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-7.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 7.3.0 (Rev1, Built by MSYS2 project)
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/cc1.exe -E -quiet -v -iprefix C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/ -D_REENTRANT - -mtune=generic -march=x86-64
the cc1 gave no output, froze MSYS2 and I have to terminate cc1 from task manager.
Then I run directly C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/cc1.exe -E -quiet -v -iprefix C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/ -D_REENTRANT - -mtune=generic -march=x86-64
it returned
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/7.3.0/include"
ignoring nonexistent directory "C:/building/msys64/mingw64/include"
ignoring nonexistent directory "/mingw64/include"
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64- w64-mingw32/7.3.0/include-fixed"
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "C:/building/msys64/mingw64/x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/include
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64- mingw32/7.3.0/../../../../include
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/include-fixed
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/include
End of search list.
Turns out the #include <...> search does not include the /usr/include directory of MSYS2, should have been C:/msys64/mingw64/bin/../../usr/include
I tried putting ENV CFLAGS="-I/usr/include" before ./configure, that caused more errors, many .h not usable but presence. and sys/socket.h is usable and presence.
So turns out -I/usr/include somehow did not pass into the compiler?
My Question is, is this configurable? Or is there something wrong with my setup?
OpenLDAP 2.4.46
MSYS2 20161025
MSYS2 has three different toolchains with different purposes:
The msys-2.0.dll-based toolchain, which creates executables that use the POSIX emulation capabilities provided by msys-2.0.dll. The main compiler is /usr/bin/gcc and it uses headers from /usr/include. This is the toolchain to use if your program was written for a Linux or another POSIX-type operating system and you are finding it difficult to port it to Windows because it uses a lot of features not supported by Microsoft.
MinGW 32-bit toolchain. This compiles native Windows software that can run on 32-bit or 64-bit versions of Windows. The main compiler is /mingw32/bin/gcc. To use this toolchain you must launch MSYS2 with the "MinGW-w64 32-bit Shell" shortcut or launch mingw32.exe. This toolchain is not compatible with the headers in /usr/include, but it can use native Windows headers with interfaces defined by Microsoft, like windows.h.
MinGW 64-bit toolchain. This toolchain is just like the 32-bit toolchain except the executables are 64-bit executables, and thus only work on 64-bit Windows. It has its own shortcut in the start menu, and can also be launched with mingw64.exe.
I don't know anything about OpenLDAP, but if it is requiring a bunch of headers that the MinGW toolchains don't have, you could either try to port it to Windows or switch over to building it with the msys-2.0.dll-based toolchain.
I've built an R package which includes C/C++ code. I am now trying to test this package on win-builder. Unfortunately, the following error is returned in 00install.out:
* installing *source* package 'mypackage' ...
** libs
running 'src/Makefile.win' ...
/usr/bin/make --directory=lib/mylib/
gcc -g -Wall -fPIC -c mycode.c
make[1]: gcc: Command not found
make[1]: *** [mycode.o] Error 127
make: *** [mylib] Error 2
Warning: running command 'make --no-print-directory -f "Makefile.win"' had status 2
ERROR: compilation failed for package 'mypackage'
* removing 'd:/RCompile/CRANguest/R-release/lib/mypackage'
Trying with gcc, gcc.exe, and cc yielded similar results.
Accordingly, I set up a testing environment on a Windows virtual machine according to these instructions. Running R CMD INSTALL . on the code from the command line within this environment resulted in the code compiling and the package installing without issue. (Running R CMD build . also yielded no errors.)
What's up with win-builder, and how can I achieve compilation on it?
Or, more importantly, is being able to build the package on Windows sufficient, regardless of whether it worked on win-builder?
My Makefile.win is as follows:
export CCOMP = gcc
export CPPCOMP = c++
export ADD_CC_FLAGS = -O3
APP_DIR = ./apps/myapp
LIB_DIR = ./lib/mylib
.PHONY: all $(APP_DIR) $(LIB_DIR)
all: $(APP_DIR) $(LIB_DIR)
$(APP_DIR) $(LIB_DIR): mylib
$(MAKE) --directory=$#
$(APP_DIR): $(LIB_DIR) mylib
mylib:
$(MAKE) --directory=lib/mylib
Inserting echo %PATH% into the make file under the mylib target yielded:
Makefile.win:24: *** missing separator. Stop.
You get an obscure error here because you included a file Makefile.win.
But the semantics of make, if such a file is found, it will be used ... which is not what you want here. R builds its own Makefile.win and you are supposed to only supply a snippet to be included -- which must be called Makevars.win.
That is rule number one. Rules number two is to not included all the material you would include in a Makefile -- as you would clobber what R already brings to the table. All this is in Writing R Extensions but could of course be clearer.
My pragmatic suggestion: take a package you know and like which has a working R build in win-builder, and modify it. You can test locally should you have access to an R system with Rtools etc pp.
Edit from OP:
I needed to compile an executable which relied on several libraries. The library codes were in src/libs and the executable's code was in src/apps. I ensured that running make within each subdirectory worked and set src/apps/Makefile to use relative paths to pull in the results of src/libs. The only problem then, was getting the whole chain running. To do so, I created a file src/Makevars.win which had the following structure:
.PHONY: all myprogram sublib1 sublib2
all: sublib1 sublib2 myprogram
myprogram: sublib1 sublib2
#(cd apps/myprogram && $(MAKE) CXX="$(CXX)" CC="$(CC)" CFLAGS="$(CFLAGS) $(CPICFLAGS)" AR="$(AR)" RANLIB="$(RANLIB)")
sublib1:
#(cd lib/sublib1 && $(MAKE) CXX="$(CXX)" CC="$(CC)" CFLAGS="$(CFLAGS) $(CPICFLAGS)" AR="$(AR)" RANLIB="$(RANLIB)")
sublib2:
#(cd lib/sublib2 && $(MAKE) CXX="$(CXX)" CC="$(CC)" CFLAGS="$(CFLAGS) $(CPICFLAGS)" AR="$(AR)" RANLIB="$(RANLIB)")
As I understand it, Makevars.win gets embedded in a dynamically generated Makefile that R produces. So, $(CC) is actually referencing this hidden code.
(There are probably more clever ways to do this.)
I want to install libQGLViewer, which I downloaded from http://www.libqglviewer.com/download.html on Ubuntu 10.04. According to the manual I have to do;
1) cd QGLViewer/
2) qmake
3) make
Compiling the library by typing make almost immediately ends in error however;
`c++ -c -pipe -Wall -W -Os -fPIC -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_TABLET_SUPPORT -I/usr/share/qt3/mkspecs/macx-g++ -I. -I/usr/include/qt3 -I/System/Library/Frameworks/OpenGL.framework/Headers -I/System/Library/Frameworks/AGL.framework/Headers/ -I.moc/ -o .obj/qglviewer.o qglviewer.cpp
In file included from domUtils.h:23,
from qglviewer.cpp:23:
config.h:77:22: error: QGLWidget: No such file or directory
config.h:88:17: error: QList: No such file or directory
config.h:89:19: error: QVector: No such file or directory
In file included from qglviewer.cpp:23:
domUtils.h:25:23: error: QDomElement: No such file or directory
domUtils.h:26:19: error: QString: No such file or directory
domUtils.h:27:23: error: QStringList: No such file or directory
domUtils.h:28:18: error: QColor: No such file or directory
`
this goes on for a while and ends in:
`qglviewer.cpp:841: error: ‘height’ was not declared in this scope
qglviewer.cpp: At global scope:
qglviewer.cpp:864: error: variable or field ‘timerEvent’ declared void
qglviewer.cpp:864: error: ‘QTimerEvent’ was not declared in this scope
qglviewer.cpp:864: error: expected primary-expression before ‘)’ token
make: *** [.obj/qglviewer.o] Error 1
rcar#DUD3642RCAR:~/Downloads/libQGLViewer-2.5.1/QGLViewer$
`
I think this is because it cannot find the QT library. But I have installed QT 5.2 using the latest download from http://qt-project.org/downloads.
Could it be the Makefile just can not locate the library path? And if so I how do I mend this?
Solved it! I missed qtcreator for this; sudo apt-get install qtcreator
I also needed an upgrade to Ubuntu 12.04 because on 10.04 this problem persisted.
I'm trying to use this sqlite extension to calculate stdev in Sqlite dbs, on Linux, I use this command to compile the lib
gcc -fPIC -lm -shared extension-functions.c -o libsqlitefunctions.so
but seems that the .load command is not in the sqlite .help command list, and I got error:
unknown command or invalid arguments: "load". Enter ".help" for help
Same thing happens when I use the command:
sqlite> SELECT load_extension('./libsqlitefunctions.so');
SQL error: no such function: load_extension
I tried to use this instruction to compile sqlite:
0. untar latest sqlite3 source code in a new directory
1. cd to the newly untarred sqlite directory
2. Comment out the line in Makefile.in to enable loadable extensions:
# TCC += -DSQLITE_OMIT_LOAD_EXTENSION=1
3. ./configure LIBS=-ldl && make sqlite3
4. export LD_LIBRARY_PATH="`pwd`:$LD_LIBRARY_PATH"
5. gcc -I`pwd` -shared src/test_loadext.c -o half.so
6. ./sqlite3
But couldn't find the line "TCC += -DSQLITE_OMIT_LOAD_EXTENSION=1" in the newest Sqlite source code.
It looks like configure was updated but not the documentation. Try
./configure --enable-dynamic-extensions
The reference is the configure source code. Digging further, it looks like the dynamic extensions are enabled by default. From README:
The generic installation instructions for autoconf/automake are found
in the INSTALL file.
The following SQLite specific boolean options are supported:
--enable-readline use readline in shell tool [default=yes]
--enable-threadsafe build a thread-safe library [default=yes]
--enable-dynamic-extensions support loadable extensions [default=yes]
So I think load is present. It's the second part of the error invalid arguments that's the problem.
The cause seems to be that you're using Linux instructions. That won't work. Macs don't generally have .so files, which is what your compilation command is generating.
The method of compiling and loading a Mac dynamic library, loadable as an extension, is at this location. The compile command is going to look something like
gcc -bundle -fPIC -I/path-to-sqlite/sqlite3 -o filename.sqlext filename.c
Note the -bundle and -fPIC that are important for dynamic loading, but which you were missing. The resulting filename will be filename.sqlext, so use that in your path.
It may be worth noting that you may get a "missing symbols" error when you load the library - this is due to the fact that the -lm flag needs to be at the end of the compile command thus:
gcc -fPIC -shared extension-functions.c -o libsqlitefunctions.so -lm
Regards Fat jonnie