How to build C++ protobuf? - c++

How to build C++ protobuf so that g++ pb.cpp pb.pb.cc $(pkg-config --cflags --libs protobuf) works? (pb.cpp provided below, pb.pb.cc generated from incomplete protobuf build)
I do not want to use apt-get install -y protobuf-compiler libprotobuf-dev because the versions are too old (3.12 in apt, 4.22 in source) so I try and build them myself from source.
CMake
Steps from cmake/README.md.
> cmake -S . -B build -DCMAKE_CXX_STANDARD=14
<truncated, no errors>
> cmake --build build --target install
<truncated, no errors>
Scanning dependencies of target log_internal_check_op
[ 43%] Building CXX object third_party/abseil-cpp/absl/log/CMakeFiles/log_internal_check_op.dir/internal/check_op.cc.o
[ 44%] Linking CXX shared library libabsl_log_internal_check_op.so
[ 44%] Built target log_internal_check_op
<truncated, no errors>
> g++ pb.cpp pb.pb.cc $(pkg-config --cflags --libs protobuf)
/usr/bin/ld: /tmp/cc3B1oMq.o: undefined reference to symbol '_ZN4absl12lts_2023012512log_internal21CheckOpMessageBuilder7ForVar2Ev'
/usr/bin/ld: /usr/local/lib/libabsl_log_internal_check_op.so.2301.0.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
> g++ pb.cpp pb.pb.cc $(pkg-config --cflags --libs protobuf --libs absl_log_internal_check_op)
<truncated, no errors>
Although the last command works fine, the additional pkg-config --cflags --libs absl_log_internal_check_op is not required if I use apt-get install -y protobuf-compiler libprotobuf-dev.
How can I build protobur properly so that g++ pb.cpp pb.pb.cc $(pkg-config --cflags --libs protobuf) without the --libs absl_log_internal_check_op works?
Bazel
I have followed the steps exactly with no warnings at README.md but still cannot use the files.
The errors:
Well-known types (for example, timestamp.proto) missing
In official build (protoc-22.0-linux-x86_64.zip), part of include/
The corresponding *.cc and *.h are present at bazel-bin/src/google/protobuf/wkt/google/protobuf (only *.proto missing)
They are all in the source directory so don't know why they're removed
I don't want to copy from this directory directly because it contains extra files (unittest_*)
*.pc files not included in build (used as pkg-config --cflags --libs protobuf)
Source file
For convenience, here is the Dockerfile:
FROM ubuntu:20.04
ARG INSTALL_LOCATION="./installed"
ENV PATH="$PATH:$INSTALL_LOCATION/bin"
RUN apt-get update
RUN apt-get install -y g++ git
# Bazel install (Protobuf dependency)
# https://bazel.build/install/ubuntu#install-on-ubuntu
RUN apt-get install -y apt-transport-https curl gnupg
RUN curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg
RUN mv bazel-archive-keyring.gpg /usr/share/keyrings
RUN echo "deb [arch=amd64 signed-by=/usr/share/keyrings/bazel-archive-keyring.gpg] https://storage.googleapis.com/bazel-apt stable jdk1.8" | tee /etc/apt/sources.list.d/bazel.list
RUN apt-get update
RUN apt-get install -y bazel
RUN bazel --version
# Protobuf C++ build
# https://github.com/protocolbuffers/protobuf/blob/d41deb9dc6602701b157739a314ad6405f9b89ed/src/README.md#c-protobuf---unix
RUN git clone https://github.com/protocolbuffers/protobuf.git
RUN cd protobuf && git submodule update --init --recursive
RUN cd protobuf && bazel build :protoc :protobuf
RUN cd protobuf && cp bazel-bin/protoc "$INSTALL_LOCATION/bin"
# Only protoc installed
# Missing:
# protobuf.pc: pkg-config --cflags --libs protobuf
# google/protobuf/timestamp.proto: part of protoc-22.0-linux-x86_64.zip which should be included
COPY pb.proto .
# Generates pb.pb.cc and pb.pb.h
RUN protoc --cpp_out=. pb.proto
COPY pb.cpp .
# Error
# RUN g++ pb.cpp pb.pb.cc $(pkg-config --cflags --libs protobuf)
pb.proto
syntax = "proto3";
package pb;
// Well-known type that ships with release distribution
import "google/protobuf/timestamp.proto";
message Test {
google.protobuf.Timestamp time = 1;
}
pb.cpp
#include "pb.pb.h"
int main() {
GOOGLE_PROTOBUF_VERIFY_VERSION;
pb::Test some_var;
/* other code here, but not required for error */
}
ldd
libprotobuf-dev
> ldd /usr/lib/x86_64-linux-gnu/libprotobuf.so
linux-vdso.so.1 (0x00007fff10b24000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2281be8000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2281a06000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2281814000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2281f00000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f22817f9000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f22816aa000)
CMake
> ldd /usr/local/lib/libprotobuf.so
linux-vdso.so.1 (0x00007fff3098d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5952b05000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f5952ae9000)
libabsl_die_if_null.so.2301.0.0 => /usr/local/lib/libabsl_die_if_null.so.2301.0.0 (0x00007f5952ae4000)
libabsl_statusor.so.2301.0.0 => /usr/local/lib/libabsl_statusor.so.2301.0.0 (0x00007f5952ade000)
libabsl_log_internal_check_op.so.2301.0.0 => /usr/local/lib/libabsl_log_internal_check_op.so.2301.0.0 (0x00007f5952ad5000)
libabsl_log_internal_message.so.2301.0.0 => /usr/local/lib/libabsl_log_internal_message.so.2301.0.0 (0x00007f5952ac9000)
libabsl_log_internal_nullguard.so.2301.0.0 => /usr/local/lib/libabsl_log_internal_nullguard.so.2301.0.0 (0x00007f5952ac2000)
libabsl_hash.so.2301.0.0 => /usr/local/lib/libabsl_hash.so.2301.0.0 (0x00007f5952abd000)
libabsl_raw_hash_set.so.2301.0.0 => /usr/local/lib/libabsl_raw_hash_set.so.2301.0.0 (0x00007f5952ab8000)
libabsl_status.so.2301.0.0 => /usr/local/lib/libabsl_status.so.2301.0.0 (0x00007f5952aac000)
libabsl_cord.so.2301.0.0 => /usr/local/lib/libabsl_cord.so.2301.0.0 (0x00007f5952a92000)
libabsl_synchronization.so.2301.0.0 => /usr/local/lib/libabsl_synchronization.so.2301.0.0 (0x00007f5952a82000)
libabsl_time.so.2301.0.0 => /usr/local/lib/libabsl_time.so.2301.0.0 (0x00007f5952a68000)
libabsl_time_zone.so.2301.0.0 => /usr/local/lib/libabsl_time_zone.so.2301.0.0 (0x00007f5952a48000)
libabsl_str_format_internal.so.2301.0.0 => /usr/local/lib/libabsl_str_format_internal.so.2301.0.0 (0x00007f5952a2b000)
libabsl_bad_variant_access.so.2301.0.0 => /usr/local/lib/libabsl_bad_variant_access.so.2301.0.0 (0x00007f5952a26000)
libabsl_strings.so.2301.0.0 => /usr/local/lib/libabsl_strings.so.2301.0.0 (0x00007f5952a05000)
libabsl_throw_delegate.so.2301.0.0 => /usr/local/lib/libabsl_throw_delegate.so.2301.0.0 (0x00007f59529fe000)
libabsl_spinlock_wait.so.2301.0.0 => /usr/local/lib/libabsl_spinlock_wait.so.2301.0.0 (0x00007f59529f7000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5952815000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f59527fa000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5952608000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5952df1000)
libabsl_raw_logging_internal.so.2301.0.0 => /usr/local/lib/libabsl_raw_logging_internal.so.2301.0.0 (0x00007f5952603000)
libabsl_examine_stack.so.2301.0.0 => /usr/local/lib/libabsl_examine_stack.so.2301.0.0 (0x00007f59525fc000)
libabsl_log_internal_format.so.2301.0.0 => /usr/local/lib/libabsl_log_internal_format.so.2301.0.0 (0x00007f59525f7000)
libabsl_log_internal_proto.so.2301.0.0 => /usr/local/lib/libabsl_log_internal_proto.so.2301.0.0 (0x00007f59525f2000)
libabsl_strerror.so.2301.0.0 => /usr/local/lib/libabsl_strerror.so.2301.0.0 (0x00007f59525ed000)
libabsl_log_internal_log_sink_set.so.2301.0.0 => /usr/local/lib/libabsl_log_internal_log_sink_set.so.2301.0.0 (0x00007f59525e6000)
libabsl_log_internal_globals.so.2301.0.0 => /usr/local/lib/libabsl_log_internal_globals.so.2301.0.0 (0x00007f59525e1000)
libabsl_log_globals.so.2301.0.0 => /usr/local/lib/libabsl_log_globals.so.2301.0.0 (0x00007f59525d9000)
libabsl_base.so.2301.0.0 => /usr/local/lib/libabsl_base.so.2301.0.0 (0x00007f59525d3000)
libabsl_city.so.2301.0.0 => /usr/local/lib/libabsl_city.so.2301.0.0 (0x00007f59525ce000)
libabsl_low_level_hash.so.2301.0.0 => /usr/local/lib/libabsl_low_level_hash.so.2301.0.0 (0x00007f59525c9000)
libabsl_cordz_info.so.2301.0.0 => /usr/local/lib/libabsl_cordz_info.so.2301.0.0 (0x00007f59525c2000)
libabsl_cord_internal.so.2301.0.0 => /usr/local/lib/libabsl_cord_internal.so.2301.0.0 (0x00007f59525a7000)
libabsl_crc_cord_state.so.2301.0.0 => /usr/local/lib/libabsl_crc_cord_state.so.2301.0.0 (0x00007f595259f000)
libabsl_cordz_functions.so.2301.0.0 => /usr/local/lib/libabsl_cordz_functions.so.2301.0.0 (0x00007f595259a000)
libabsl_stacktrace.so.2301.0.0 => /usr/local/lib/libabsl_stacktrace.so.2301.0.0 (0x00007f5952595000)
libabsl_symbolize.so.2301.0.0 => /usr/local/lib/libabsl_symbolize.so.2301.0.0 (0x00007f595258b000)
libabsl_malloc_internal.so.2301.0.0 => /usr/local/lib/libabsl_malloc_internal.so.2301.0.0 (0x00007f5952584000)
libabsl_int128.so.2301.0.0 => /usr/local/lib/libabsl_int128.so.2301.0.0 (0x00007f595257a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f595242b000)
libabsl_strings_internal.so.2301.0.0 => /usr/local/lib/libabsl_strings_internal.so.2301.0.0 (0x00007f5952425000)
libabsl_log_sink.so.2301.0.0 => /usr/local/lib/libabsl_log_sink.so.2301.0.0 (0x00007f5952420000)
libabsl_cordz_handle.so.2301.0.0 => /usr/local/lib/libabsl_cordz_handle.so.2301.0.0 (0x00007f5952418000)
libabsl_crc32c.so.2301.0.0 => /usr/local/lib/libabsl_crc32c.so.2301.0.0 (0x00007f5952412000)
libabsl_exponential_biased.so.2301.0.0 => /usr/local/lib/libabsl_exponential_biased.so.2301.0.0 (0x00007f595240d000)
libabsl_debugging_internal.so.2301.0.0 => /usr/local/lib/libabsl_debugging_internal.so.2301.0.0 (0x00007f5952406000)
libabsl_demangle_internal.so.2301.0.0 => /usr/local/lib/libabsl_demangle_internal.so.2301.0.0 (0x00007f59523f9000)
libabsl_crc_internal.so.2301.0.0 => /usr/local/lib/libabsl_crc_internal.so.2301.0.0 (0x00007f59523f0000)
> ldd /usr/local/lib/libabsl_log_internal_check_op.so.2301.0.0
linux-vdso.so.1 (0x00007fff09986000)
libabsl_log_internal_nullguard.so.2301.0.0 => /usr/local/lib/libabsl_log_internal_nullguard.so.2301.0.0 (0x00007fa936193000)
libabsl_strings.so.2301.0.0 => /usr/local/lib/libabsl_strings.so.2301.0.0 (0x00007fa936172000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa935f8c000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa935f71000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa935d7f000)
libabsl_strings_internal.so.2301.0.0 => /usr/local/lib/libabsl_strings_internal.so.2301.0.0 (0x00007fa935d79000)
libabsl_throw_delegate.so.2301.0.0 => /usr/local/lib/libabsl_throw_delegate.so.2301.0.0 (0x00007fa935d70000)
libabsl_raw_logging_internal.so.2301.0.0 => /usr/local/lib/libabsl_raw_logging_internal.so.2301.0.0 (0x00007fa935d6b000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa935c1c000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa9361a3000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa935bf9000)

Related

Why can't this executable find this shared library? [duplicate]

I build an R package which uses Rcpp and links to a third-party shared object (libbarraopt.so) (which also links to other shared objects such as liboptsrvr.so in its own directory). To ensure that it is able to find those shared objects it links against, I put the following variables in ~/.Renviron:
BARRA_OPS_HOME=${HOME}/bin/BarraOptimizer8.5
In the package, I create the following src/Makevars:
BARRA_LIB=$(BARRA_OPS_HOME)/lib/intel64
BARRA_INCLUDE=$(BARRA_OPS_HOME)/include
PKG_CXXFLAGS=-I$(BARRA_INCLUDE)
PKG_CFLAGS=-I$(BARRA_INCLUDE)
PKG_LIBS=-L$(BARRA_LIB) -Wl,-R,$(BARRA_LIB) -lbarraopt
Under Ubuntu 16.04, I can build, load, and use the package successfully without any problem. However, when I test exactly the same package when OS is upgraded to 17.10, the package can be built but it cannot be loaded, saying:
g++ -std=gnu++11 -I/usr/share/R/include -DNDEBUG -I"/home/renkun/R/x86_64-pc-linux-gnu-library/3.4/Rcpp/include" -I/home/renkun/bin/BarraOptimizer8.5/include -fpic -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c RcppExports.cpp -o RcppExports.o
** libs
g++ -std=gnu++11 -I/usr/share/R/include -DNDEBUG -I"/home/renkun/R/x86_64-pc-linux-gnu-library/3.4/Rcpp/include" -I/home/renkun/bin/BarraOptimizer8.5/include -fpic -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c barraopt.cpp -o barraopt.o
g++ -std=gnu++11 -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -Wl,-z,relro -o barraopt.so RcppExports.o barraopt.o -L/home/renkun/bin/BarraOptimizer8.5/lib/intel64 -Wl,-R,/home/renkun/bin/BarraOptimizer8.5/lib/intel64 -lbarraopt -L/usr/lib/R/lib -lR
installing to /tmp/Rtmpvbb6Io/devtools_install_42a342a07f84/barraopt/libs
* DONE (barraopt)
Error in dyn.load(dllfile) :
unable to load shared object '/home/renkun/Workspaces/barraopt/src/barraopt.so':
liboptsrvr.so: cannot open shared object file: No such file or directory
Calls: suppressPackageStartupMessages ... <Anonymous> -> load_all -> load_dll -> library.dynam2 -> dyn.load
Execution halted
Exited with status 1.
It seems that -Wl,-rpath is not effective here.
Under a machine with Ubuntu 16.04, ldd src/barraopt.so shows that all dynamic linking is corrected resolved. (BARRA_OPS_HOME = /home/ken/bin/BarraOptimizer8.5)
linux-vdso.so.1 => (0x00007ffc89a16000)
libbarraopt.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libbarraopt.so (0x00007f85dae49000)
libimf.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libimf.so (0x00007f85da97f000)
libR.so => /usr/lib/libR.so (0x00007f85da346000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f85d9fc4000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f85d9dae000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f85d99e3000)
liboptsrvr.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/liboptsrvr.so (0x00007f85d7b10000)
libopsproto.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libopsproto.so (0x00007f85d77a1000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f85d7497000)
libintlc.so.5 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libintlc.so.5 (0x00007f85d7249000)
libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f85d6fe8000)
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007f85d6da1000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f85d6b31000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f85d690f000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f85d66fe000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f85d64e4000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f85d62dc000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f85d60d7000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f85d5eb5000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f85d5c98000)
/lib64/ld-linux-x86-64.so.2 (0x000055fb75088000)
libifcore.so.5 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libifcore.so.5 (0x00007f85d5961000)
libifport.so.5 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libifport.so.5 (0x00007f85d5732000)
libsvml.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libsvml.so (0x00007f85d4e6d000)
libmosek64.so.7.0 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libmosek64.so.7.0 (0x00007f85d3c63000)
libiomp5.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libiomp5.so (0x00007f85d396b000)
libprotobuf.so.6 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libprotobuf.so.6 (0x00007f85d3668000)
libbridge_common.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libbridge_common.so (0x00007f85d3417000)
libsharc_xmlxproto.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libsharc_xmlxproto.so (0x00007f85d31a4000)
libboost_thread.so.1.49.0 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libboost_thread.so.1.49.0 (0x00007f85d2f8a000)
libopenblas.so.0 => /usr/lib/libopenblas.so.0 (0x00007f85d0ef5000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f85d0ccc000)
libxerces-c-3.1.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libxerces-c-3.1.so (0x00007f85d07c4000)
libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f85d0499000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f85d027f000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f85d0040000)
However, with the same source, under Ubuntu 17.10, ldd shows that the shared objects libbarraopt.so links against are not resolved even though -Wl,-rpath is secified: (BARRA_OPS_HOME = /home/renkun/bin/BarraOptimizer8.5)
linux-vdso.so.1 => (0x00007ffe067f5000)
libbarraopt.so => /home/renkun/bin/BarraOptimizer8.5/lib/intel64/libbarraopt.so (0x00007f3dc5f0c000)
libR.so => /usr/lib/libR.so (0x00007f3dc58e4000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3dc555e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3dc5208000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3dc4ff1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3dc4c11000)
liboptsrvr.so => not found
libopsproto.so => not found
libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x00007f3dc49b6000)
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007f3dc4770000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f3dc44fe000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f3dc42d8000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f3dc40c8000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3dc3eab000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3dc3ca3000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3dc3a9f000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f3dc3870000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3dc3651000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3dc6526000)
libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 (0x00007f3dc13ab000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f3dc1182000)
libgfortran.so.4 => /usr/lib/x86_64-linux-gnu/libgfortran.so.4 (0x00007f3dc0da3000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f3dc0b63000)
It looks like only libbarraopt.so is linked with the correct path but shared objects it links against are missing.
I'm wondering what might be wrong with my build configurations that breaks under the toolchain shipped by 17.10. Although using global config such as ldconfig would solve such problem, I prefer not because some .so it relies have conflict with the version the OS ships. I'd rather use a locally configured version without affecting the global config.
It seems that -Wl,-rpath is not effective here.
What likely happened is that your updated linker emits DT_RUNPATH dynamic tag, where the old linker emitted DT_RPATH. (It's also possible that your old linker was GNU-ld, and the new one is Gold.)
The DT_RUNPATH is preferred as more correct, and affects search path of the binary itself, but not of any of the dependent libraries.
The DT_RPATH has global effect, similar to adding the directory to LD_LIBRARY_PATH environment variable.
You can verify this with: readelf -d a.out | grep 'R.*PATH'.
If you do see the RPATH vs. RUNPATH difference, and in fact are using Gold, you can force the "old" behavior with -Wl,--disable-new-dtags (GNU ld also had --disable-new-dtags added to it recently, so it should work for either linker).

Is there a way to statically link the glib2 library?

Since the production device does not have a glib2 runtime environment, I need to statically link to glib2. I tried to compile and link in the following ways, but it still links libglib-2.0.so.0. I am sure that libglib-2.0.a exists on my device.
#include <glib.h>
int main(void)
{
char *test;
test = g_new0(char,1);
g_free(test);
return 0;
}
i tried build it by
gcc `pkg-config --static --libs --cflags glib-2.0` main.c -o test
ldd test
linux-vdso.so.1 (0x00007ffe9dbc8000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f2ee333f000)
libm.so.6 => /lib64/libm.so.6 (0x00007f2ee31fb000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f2ee3183000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2ee3162000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2ee2f93000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2ee3492000)
The flags that pkg-config --static gives you are library flags suited for a program that will ultimately be statically linked. Now, it's not pkg-config's job to configure your build, just to give you the flags your libraries need.
So, you need to add -s to your gcc command yourself.

Compiling OpenGL Program (Linux) - Cannot find -lGL

I am attempting to compile a test opengl program on ubuntu. I have installed bumblebee, the nvidia 304 driver and libgl1-mesa-dev, using apt-get.
I can see the file /usr/lib/libGL.so.1 - and yet compiling with g++ and the flag -lGL returns the error: error: cannot find -lGL.
Any ideas on what I can do to fix this?
Output of dpkg -L libgl1-mesa-dev
/.
/usr
/usr/share
/usr/share/bug
/usr/share/bug/libgl1-mesa-dev
/usr/share/bug/libgl1-mesa-dev/script
/usr/share/bug/libgl1-mesa-dev/control
/usr/share/doc
/usr/share/doc/libgl1-mesa-dev
/usr/share/doc/libgl1-mesa-dev/copyright
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/mesa
/usr/lib/x86_64-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig/gl.pc
/usr/share/doc/libgl1-mesa-dev/changelog.Debian.gz
/usr/lib/x86_64-linux-gnu/mesa/libGL.so
/usr/lib/x86_64-linux-gnu/libGL.so
/usr/lib/x86_64-linux-gnu/libglapi.so
Update
The command ldconfig -p | grep libGL.so gives the output:
libGL.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGL.so.1
libGL.so.1 (libc6,x86-64) => /usr/lib/libGL.so.1
libGL.so.1 (libc6) => /usr/lib/i386-linux-gnu/libGL.so.1
libGL.so (libc6) => /usr/lib/i386-linux-gnu/libGL.so
I don't know if that's useful or correct?

How to configure shared library search path after building GCC on my own?

I just built GCC 5.1 on Ubuntu 14.04, which has gcc 4.8 as default. When I try to build things with it, I find that ld will use the default libstdc++ instead of the newly build one.
Here is the output:
drizzlex#dx ~/test
$ g++ hello.cpp
drizzlex#dx ~/test
$ ldd a.out
linux-vdso.so.1 => (0x00007ffde0d25000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa181ad2000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa1817cc000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa1815b5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa1811f0000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa181dfd000)
And if I use $ export LD_LIBRARY_PATH=/usr/local/lib64/, it will find the right one.
drizzlex#dx ~/test
$ ldd a.out
linux-vdso.so.1 => (0x00007fffeeaf5000)
libstdc++.so.6 => /usr/local/lib64/libstdc++.so.6 (0x00007f4583d92000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4583a67000)
libgcc_s.so.1 => /usr/local/lib64/libgcc_s.so.1 (0x00007f4583850000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f458348b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f458410e000)
I would like to know what should I do to make it correct? Since I know set LD_LIBRARY_PATH is not the best choice.
For building with g++ 5.1 use this:
$ g++5.1 hello.cpp -Wl,-rpath,/usr/local/lib64
And you will not need set LD_LIBRARY_PATH.
This is from https://en.wikipedia.org/wiki/Rpath
rpath is a term in programming which refers to a run-time search path
hard-coded in an executable file or library, used during dynamic
linking to find the libraries the executable or library requires.

Shared library, makefile. Library path

Im trying to link my program to the shared library. Im using a makefile to compile. It looks like this: `
make: sms_out.cpp SMSDispatch.cpp SMSDispatch.h
g++ -c -fPIC SMSDispatch.cpp -o SMSDispatch.o
g++ -shared SMSDispatch.o -o libSMSDispatch.so
` g++ sms_out.cpp -L. -lSMSDispatch -o sms_out
It works fine if I run the program in the command window with:
LD_LIBRARY_PATH="." ./sms_out
But I want to run it with just ./sms_out, can someone help me?
Tried to add export LD_LIBRARY_PATH=. to the makefile, but that didnt work, just got the error " error while loading shared libraries: libSMSDispatch.so: cannot open shared object file: No such file or directory" when I try to run the program.
Another option - provide -rpath options to linker to inform your binary where else search for dynamic objects.
g++ -Wl,-rpath=<path to .so> -o <your binary here> <cpp file name>.cpp
Add the directory where the .so file exists to LD_LIBRARY_PATH:
$ export LD_LIBRARY_PATH=/dir/containing/sharedobject
A utility you may find useful is ldd, which prints the shared library dependencies. For example:
$ ldd /bin/ls
linux-vdso.so.1 => (0x00007fff819ff000)
librt.so.1 => /lib64/librt.so.1 (0x00007fc0d3f67000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fc0d3d4a000)
libacl.so.1 => /lib64/libacl.so.1 (0x00007fc0d3b42000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc0d37e9000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc0d35cd000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc0d4170000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc0d33c9000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007fc0d31c4000)
If shared objects are not locatable a string not found, or similar, is displayed instead of the path to the shared object being used.