I'm compiling some cpp files with:
$ g++ -c --std=c++17 -I/antlr4/runtime/Cpp/runtime/src/ *.cpp
And everything goes fine:
$ ls -l *.cpp *.o
-rw-r--r-- 1 root root 76637 Dec 1 14:33 Java8Lexer.cpp
-rw-r--r-- 1 root root 370768 Dec 1 15:13 Java8Lexer.o
-rw-r--r-- 1 root root 925012 Dec 1 14:33 Java8Parser.cpp
-rw-r--r-- 1 root root 5037896 Dec 1 15:13 Java8Parser.o
-rw-r--r-- 1 root root 113 Dec 1 14:33 Java8ParserBaseListener.cpp
-rw-r--r-- 1 root root 2312 Dec 1 15:13 Java8ParserBaseListener.o
-rw-r--r-- 1 root root 109 Dec 1 14:33 Java8ParserListener.cpp
-rw-r--r-- 1 root root 2304 Dec 1 15:13 Java8ParserListener.o
-rw-r--r-- 1 root root 724 Dec 1 14:36 main.cpp
-rw-r--r-- 1 root root 324360 Dec 1 15:13 main.o
When I try to link with a library, it fails:
$ g++ *.o -l/antlr4/runtime/Cpp/dist/libantlr4-runtime.so.4.9.3
/usr/bin/ld: cannot find -l/antlr4/runtime/Cpp/dist/libantlr4-runtime.so.4.9.3
collect2: error: ld returned 1 exit status
This is weird because the shared library does exist:
$ ls -l /antlr4/runtime/Cpp/dist/libantlr4-runtime.so.4.9.3
-rwxr-xr-x 1 root root 1599624 Dec 1 14:28 /antlr4/runtime/Cpp/dist/libantlr4-runtime.so.4.9.3
You can specify the directory with option -L and the library file with its abbreviated form (no lib prefix, no .so.xxx suffix):
g++ *.o -L /antlr4/runtime/Cpp/dist -lantlr4-runtime
Related
I'm attempting to compile a binary from source, but keep running into an error while doing so.
$ cmake --build ./\[binary_dir\]/
[ 0%] Building C object [binary_dir]/CMakeFiles/ZIPLIB.dir/extlibs/bzip2/bcompress.c.o
cc: error: unrecognized command line option ‘-std=c++20’; did you mean ‘-std=c++2a’?
make[2]: *** [[binary_dir]/CMakeFiles/ZIPLIB.dir/build.make:154: [binary_dir]/CMakeFiles/ZIPLIB.dir/extlibs/bzip2/bcompress.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:307: [binary_dir]/CMakeFiles/ZIPLIB.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
Specifically, "cc: error: unrecognized command line option ‘-std=c++20’; did you mean ‘-std=c++2a’?."
I suspect this has to do with using the incorrect version of gcc; I have multiple version installed but believe I need to be using the latest, or at least 11.1.0. I have these versions installed:
$ ls -l /usr/bin/gcc*
lrwxrwxrwx 1 root root 5 Mar 20 2020 /usr/bin/gcc -> gcc-9
lrwxrwxrwx 1 root root 23 May 29 2021 /usr/bin/gcc-10 -> x86_64-linux-gnu-gcc-10
lrwxrwxrwx 1 root root 23 Apr 28 2021 /usr/bin/gcc-11 -> x86_64-linux-gnu-gcc-11
lrwxrwxrwx 1 root root 22 Mar 9 12:57 /usr/bin/gcc-9 -> x86_64-linux-gnu-gcc-9
lrwxrwxrwx 1 root root 8 Mar 20 2020 /usr/bin/gcc-ar -> gcc-ar-9
lrwxrwxrwx 1 root root 26 May 29 2021 /usr/bin/gcc-ar-10 -> x86_64-linux-gnu-gcc-ar-10
lrwxrwxrwx 1 root root 26 Apr 28 2021 /usr/bin/gcc-ar-11 -> x86_64-linux-gnu-gcc-ar-11
lrwxrwxrwx 1 root root 25 Mar 9 12:57 /usr/bin/gcc-ar-9 -> x86_64-linux-gnu-gcc-ar-9
lrwxrwxrwx 1 root root 8 Mar 20 2020 /usr/bin/gcc-nm -> gcc-nm-9
lrwxrwxrwx 1 root root 26 May 29 2021 /usr/bin/gcc-nm-10 -> x86_64-linux-gnu-gcc-nm-10
lrwxrwxrwx 1 root root 26 Apr 28 2021 /usr/bin/gcc-nm-11 -> x86_64-linux-gnu-gcc-nm-11
lrwxrwxrwx 1 root root 25 Mar 9 12:57 /usr/bin/gcc-nm-9 -> x86_64-linux-gnu-gcc-nm-9
lrwxrwxrwx 1 root root 12 Mar 20 2020 /usr/bin/gcc-ranlib -> gcc-ranlib-9
lrwxrwxrwx 1 root root 30 May 29 2021 /usr/bin/gcc-ranlib-10 -> x86_64-linux-gnu-gcc-ranlib-10
lrwxrwxrwx 1 root root 30 Apr 28 2021 /usr/bin/gcc-ranlib-11 -> x86_64-linux-gnu-gcc-ranlib-11
lrwxrwxrwx 1 root root 29 Mar 9 12:57 /usr/bin/gcc-ranlib-9 -> x86_64-linux-gnu-gcc-ranlib-9
If that's the issue, how can I specify which version of gcc to use? Would that happen in the makefile/cmakelist itself, as a path which I need to specify in my environment, or as a flag applied when calling cmake?
Or does the error suggest another solution?
Presuming you are in a build directory:
You can set CMAKE_C_COMPILER when you run the original call to cmake.
cmake -DCMAKE_C_COMPILER=/usr/bin/gcc-11 ..
cmake --build .
I wanted to move our database from mysql (community version) to mariadb with the further use of php7.1/apache2.4.25... So I have to compile mariadb in our new production environment. I compiled it with these options:
cmake -DCMAKE_CXX_FLAGS:STRING="-std=c++11" -DCONC_WITH_CURL=ON -DCONC_WITH_EXTERNAL_ZLIB=ON -DDISABLE_SHARED=OFF -DCONC_WITH_MYSQLCOMPAT:BOOL=ON -DPLUGIN_CLIENT_ED25519:STRING=DYNAMIC .
make all && make install
The mysql community version has a libmysqlclient.so in /usr/local/mysql/lib located. If I compile it with the options given above I only found these files in /usr/local/mysql/lib (MariaDB 10.2.6):
# ls -l /usr/local/mysql/lib/
total 3572
-rw-r--r-- 1 root root 2305518 Jul 4 08:14 libmariadbclient.a
lrwxrwxrwx 1 root root 15 Jul 4 08:31 libmariadb.so -> libmariadb.so.3
-rwxr-xr-x 1 root root 1297664 Jul 4 08:14 libmariadb.so.3
-rw-r--r-- 1 root root 48406 Jul 4 08:14 libmysqlservices.a
drwxr-xr-x 2 root root 4096 Jul 4 08:31 plugin
How can I get libmysqlclient.so? There isn't also any libmariadbclient.so just libmariadbclient.a ...
Thank you for further hints!
OK, now I found a solution.
I've just did a symbolic link to libmariadb.so and it now looks like the following:
ls -l /usr/local/mysql/lib/
total 3572
-rw-r--r-- 1 root root 2305518 Jul 4 16:21 libmariadbclient.a
lrwxrwxrwx 1 root root 15 Jul 4 16:39 libmariadb.so -> libmariadb.so.3
-rwxr-xr-x 1 root root 1297664 Jul 4 16:21 libmariadb.so.3
lrwxrwxrwx 1 root root 15 Jul 4 16:40 libmysqlclient_r.so -> libmariadb.so.3
lrwxrwxrwx 1 root root 15 Jul 4 16:40 libmysqlclient.so -> libmariadb.so.3
-rw-r--r-- 1 root root 48406 Jul 4 16:21 libmysqlservices.a
drwxr-xr-x 2 root root 4096 Jul 4 16:39 plugin
In this case PHP 7 would finally find the mysql libraries...
I'm trying to run the following:
find /var/log/sa/ -regex ".*/sa[0\-3]\{2\}"
However, this returns no results. I can see in /var/log/sa/ that files exist, both formats of sa## and sar## -- I only want to match the former.
ll /var/log/sa/
total 40992
-rw-r--r-- 1 root root 719892 Dec 1 23:50 sa01
-rw-r--r-- 1 root root 719892 Dec 2 23:50 sa02
-rw-r--r-- 1 root root 719892 Dec 3 23:50 sa03
-rw-r--r-- 1 root root 719892 Dec 4 23:50 sa04
-rw-r--r-- 1 root root 719892 Dec 5 23:50 sa05
-rw-r--r-- 1 root root 719892 Dec 6 23:50 sa06
-rw-r--r-- 1 root root 719892 Dec 7 23:50 sa07
-rw-r--r-- 1 root root 719892 Dec 8 23:50 sa08
-rw-r--r-- 1 root root 719892 Dec 9 23:50 sa09
-rw-r--r-- 1 root root 719892 Dec 10 23:50 sa10
-rw-r--r-- 1 root root 719892 Dec 11 23:50 sa11
-rw-r--r-- 1 root root 719892 Dec 12 23:50 sa12
-rw-r--r-- 1 root root 719892 Dec 13 23:50 sa13
-rw-r--r-- 1 root root 719940 Dec 14 23:50 sa14
-rw-r--r-- 1 root root 719892 Dec 15 23:50 sa15
-rw-r--r-- 1 root root 719892 Dec 16 23:50 sa16
-rw-r--r-- 1 root root 719892 Dec 17 23:50 sa17
-rw-r--r-- 1 root root 719892 Dec 18 23:50 sa18
-rw-r--r-- 1 root root 719892 Dec 19 23:50 sa19
-rw-r--r-- 1 root root 719892 Dec 20 23:50 sa20
-rw-r--r-- 1 root root 719892 Dec 21 23:50 sa21
-rw-r--r-- 1 root root 719892 Dec 22 23:50 sa22
-rw-r--r-- 1 root root 669932 Dec 23 22:10 sa23
-rw-r--r-- 1 root root 719892 Nov 24 23:50 sa24
-rw-r--r-- 1 root root 719892 Nov 25 23:50 sa25
-rw-r--r-- 1 root root 719892 Nov 26 23:50 sa26
-rw-r--r-- 1 root root 719892 Nov 27 23:50 sa27
-rw-r--r-- 1 root root 719892 Nov 28 23:50 sa28
-rw-r--r-- 1 root root 719892 Nov 29 23:50 sa29
-rw-r--r-- 1 root root 719892 Nov 30 23:50 sa30
-rw-r--r-- 1 root root 673355 Dec 1 23:53 sar01
-rw-r--r-- 1 root root 673355 Dec 2 23:53 sar02
-rw-r--r-- 1 root root 673355 Dec 3 23:53 sar03
-rw-r--r-- 1 root root 673355 Dec 4 23:53 sar04
-rw-r--r-- 1 root root 673355 Dec 5 23:53 sar05
-rw-r--r-- 1 root root 673355 Dec 6 23:53 sar06
-rw-r--r-- 1 root root 673355 Dec 7 23:53 sar07
-rw-r--r-- 1 root root 673355 Dec 8 23:53 sar08
-rw-r--r-- 1 root root 673355 Dec 9 23:53 sar09
-rw-r--r-- 1 root root 673355 Dec 10 23:53 sar10
-rw-r--r-- 1 root root 673355 Dec 11 23:53 sar11
-rw-r--r-- 1 root root 673355 Dec 12 23:53 sar12
-rw-r--r-- 1 root root 673355 Dec 13 23:53 sar13
-rw-r--r-- 1 root root 674697 Dec 14 23:53 sar14
-rw-r--r-- 1 root root 673355 Dec 15 23:53 sar15
-rw-r--r-- 1 root root 673355 Dec 16 23:53 sar16
-rw-r--r-- 1 root root 673355 Dec 17 23:53 sar17
-rw-r--r-- 1 root root 673355 Dec 18 23:53 sar18
-rw-r--r-- 1 root root 673355 Dec 19 23:53 sar19
-rw-r--r-- 1 root root 673355 Dec 20 23:53 sar20
-rw-r--r-- 1 root root 673355 Dec 21 23:53 sar21
-rw-r--r-- 1 root root 673355 Dec 22 23:53 sar22
-rw-r--r-- 1 root root 673355 Nov 23 23:53 sar23
-rw-r--r-- 1 root root 673355 Nov 24 23:53 sar24
-rw-r--r-- 1 root root 673355 Nov 25 23:53 sar25
-rw-r--r-- 1 root root 673355 Nov 26 23:53 sar26
-rw-r--r-- 1 root root 673355 Nov 27 23:53 sar27
-rw-r--r-- 1 root root 673355 Nov 28 23:53 sar28
-rw-r--r-- 1 root root 673355 Nov 29 23:53 sar29
-rw-r--r-- 1 root root 673355 Nov 30 23:53 sar30
You should use:
find /var/log/sa/ -regex ".*/sa[0-3][0-9]"
Since the first char after the sa should be 0/1/2/3 and the second char should be any digit.
The reason for the {..} to not work is that GNU's find doesn't support the {from,to} syntax. The default regex in find is emacs, but the version used by GNU don't support the {..} syntax.
find /var/log/sa/ -regextype posix-egrep -regex '.*/sa[0-3]{2}'
You have to use posix-egrep.
I am launching an EC2 instance using Ansible and capturing an AMI image. I have verified that these dependencies get installed correctly on the instance. For example, this is what I get on the EC2 instance just before AMI imaging:
ubuntu#ip-1-2-3-4:/usr/local/bin$ ansible --version
ansible 1.4.4
-rwxr-xr-x 1 root root 5907 Jan 31 22:20 ansible
-rwxr-xr-x 1 root root 9269 Jan 31 22:20 ansible-doc
-rwxr-xr-x 1 root root 29163 Jan 31 22:20 ansible-galaxy
-rwxr-xr-x 1 root root 10419 Jan 31 22:20 ansible-playbook
-rwxr-xr-x 1 root root 6916 Jan 31 22:20 ansible-pull
-rwxr-xr-x 1 root root 714 Jan 31 22:19 aws
-rwxr-xr-x 1 root root 1408 Jan 31 22:19 aws.cmd
-rwxr-xr-x 1 root root 897 Jan 31 22:19 aws_completer
-rwxr-xr-x 1 root root 1860 Jan 31 22:19 aws_zsh_completer.sh
The problem is that once I capture an AMI and launch a new instance, I all files in /usr/local/bin are zero-byte files!
-rwxr-xr-x 1 root root 0 Jan 31 22:20 ansible
-rwxr-xr-x 1 root root 0 Jan 31 22:20 ansible-doc
-rwxr-xr-x 1 root root 0 Jan 31 22:20 ansible-galaxy
-rwxr-xr-x 1 root root 0 Jan 31 22:20 ansible-playbook
-rwxr-xr-x 1 root root 0 Jan 31 22:20 ansible-pull
-rwxr-xr-x 1 root root 0 Jan 31 22:19 aws
-rwxr-xr-x 1 root root 0 Jan 31 22:19 aws.cmd
-rwxr-xr-x 1 root root 0 Jan 31 22:19 aws_completer
-rwxr-xr-x 1 root root 0 Jan 31 22:19 aws_zsh_completer.sh
Why are these files being zero'ed out when I create a new instance from the AMI?
This was a problem with Ansible, not with AWS. Turns out there's a documentation bug in Ansible 1.4.4 where the ec2_ami module does not shut down and reboot the instance by default (the docs claim it does!). This causes all sorts of problems with file system integrity.
The fix is to include no_reboot: no in the Ansible task.
$./configure --prefix ${HOME}/ocsigen OCSIGEN_USER=${USER} OCSIGEN_GROUP=${USER} --with-missing-libs
...
checking for sqlite3_open in -lsqlite3... no
configure: error: SQLite is required. See the --with-sqlite3 configure option.
$uname -r
[FreeBSD[ 9.0-RELEASE-p3
$whereis sqlite3
sqlite3: /usr/local/bin/sqlite3
$ls -l /usr/local/lib/libsqlite*
-rw-r--r-- 1 root wheel 602092 12 3 2011 /usr/local/lib/libsqlite3.a
-rwxr-xr-x 1 root wheel 943 12 3 2011 /usr/local/lib/libsqlite3.la*
lrwx-rw-r--r-- 1 root wheel 602092 12 3 2011 /usr/local/lib/libsqlite3.a
-rwxr-xr-x 1 root wheel 943 12 3 2011 /usr/local/lib/libsqlite3.la*
lrwxr-xr-x 1 root wheel 15 12 3 2011 /usr/local/lib/libsqlite3.so# -> libsqlite3.so.8
-rwxr-xr-x 1 root wheel 617995 12 3 2011 /usr/local/lib/libsqlite3.so.8*
Any suggestion is appreciated!
I think you can use something like
./configure --with-sqlite3=/usr/local/lib
or maybe just /usr/local to tell the ./configure script that sqlite3 is not in the standard directory (/usr/lib).