problems debugging getopt function with gdb - gdb

I'm building the dnstracer application from source with this script:
#!/bin/bash
#########
# FILES #
#########
PACKAGE_NAME=dnstracer-1.6
PACKAGE_TAR_FILE=${PACKAGE_NAME}.tar.gz
PACKAGE_FTP_SITE=http://ftp.iij.ad.jp/pub/linux/momonga/1/PKGS/SOURCES/
####################################
# REMOVE OLD STUFF JUST TO BE SURE #
####################################
rm -rf build
rm -rf ${PACKAGE_NAME}
rm -rf ${PACKAGE_TAR_FILE}
#####################################
# Get source code for buggy package #
#####################################
wget ${PACKAGE_FTP_SITE}/${PACKAGE_TAR_FILE}
######################
# Unpack it here ... #
######################
tar xf ${PACKAGE_TAR_FILE}
##########################################
# Prepare an out of tree build directory #
##########################################
mkdir build
##############################
# Get inside build directory #
##############################
cd build
#################
# Configure ... #
#################
../${PACKAGE_NAME}/configure
###############
# Make it !!! #
###############
make -j
And I see it ships with its own getopt, which is good for me because I need to debug it:
$ ls -l ./dnstracer-1.6/getopt.*
./dnstracer-1.6/getopt.c
./dnstracer-1.6/getopt.h
However when I try to step inside getopt from gdb, I realize that it probably has some other getopt (maybe without debug symbols?) and it doesn't let me step inside:
$ cd build
$ gdb --args ./dnstracer -v aaaaaa
$ (gdb) break main
$ (gdb) run
$ (gdb) next
$ 1304 while ((ch=getopt(argc,argv,"coq:r:s:t:v"))!=-1) {
$ step
$ 1305 switch (ch) {
How can I configure the build process to use the shipped getopt version rather than some hidden default? Thanks!

And I see it ships with its own getopt, which is good for me because I
need to debug it:
Since you are on Ubuntu this is not the case for you, see in shipped getopt.h:
// Only used in the win32-version of dnstracer.
// Supplied by Mike Black <mblack#csihq.com>
Therefore you are using system getopt which is part of glibc. In order to step into getopt you need glibc debug symbols installed. See https://stackoverflow.com/a/48287761/72178 on how to debug glibc on Ubuntu.

Related

gcov produces different results on Clang and GCC

I'm trying to understand how to properly structure a C++ project by using CMake, googletest, and gcov for test coverage. I would like to build a general CMakeLists.txt that would work for any platform/compiler.
This is my first attempt. However, if I try to build the project and then run lcov (to generate the report), I see that I have different results if I use CLang (right result) or GCC (wrong result).
Note that I'm on MacOs and I installed gcc through brew (brew install gcc).
Moreover I used the following flags in my main CMakeLists.txt:
if(CODE_COVERAGE)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fprofile-arcs -ftest-coverage" )
endif()
Note: If you find something wrong/weird in my CMakeLists.txt files or lcov usage, I'm open to any kind of feedback!
My library
#include "library.h"
#include <iostream>
void foo(){
std::cout << "Foo!" << std::endl;
}
void bar(int n){
if (n > 0){
std::cout << "n is grater than 0!" << std::endl;
}
else if (n < 0){
std::cout << "n is less than 0!" << std::endl;
}
else{
std::cout << "n is exactly 0!" << std::endl;
}
}
void baz(){ // LCOV_EXCL_START
std::cout << "Baz!" << std::endl;
}
// LCOV_EXCL_STOP
My tests
#ifndef GCOV_TUTORIAL_TEST_LIBRARY_H
#define GCOV_TUTORIAL_TEST_LIBRARY_H
#include "../src/library.h"
#include <gtest/gtest.h>
namespace gcov_tutorial::tests {
TEST(TestFooSuite,TestFoo){
foo();
}
TEST(TestBarSuite,TestBarGreaterThanZero){
bar(100);
}
TEST(TestBarSuite,TestBarEqualToZero){
//bar(0);
}
TEST(TestBarSuite,TestBarLessThanZero){
bar(-100);
}
}
#endif //GCOV_TUTORIAL_TEST_LIBRARY_H
CLang Compilation
#!/bin/bash
# Rationale: https://vaneyckt.io/posts/safer_bash_scripts_with_set_euxo_pipefail/
set -euxo pipefail
# BASE_DIR is the project's directory, containing the src/ and tests/ folders.
BASE_DIR=$PWD
COVERAGE_FILE=coverage.info
GCOV_PATH=/usr/bin/gcov
CLANG_PATH=/usr/bin/clang
CLANGPP_PATH=/usr/bin/clang++
rm -rf build
mkdir build && cd build
# Configure
cmake -DCMAKE_C_COMPILER=$CLANG_PATH -DCMAKE_CXX_COMPILER=$CLANGPP_PATH -DCODE_COVERAGE=ON -DCMAKE_BUILD_TYPE=Release ..
# Build (for Make on Unix equivalent to `make -j $(nproc)`)
cmake --build . --config Release
# Clean-up for any previous run.
rm -f $COVERAGE_FILE
lcov --zerocounters --directory .
# Run tests
./tests/RunTests
# Create coverage report by taking into account only the files contained in src/
lcov --capture --directory tests/ -o $COVERAGE_FILE --include "$BASE_DIR/src/*" --gcov-tool $GCOV_PATH
# Create HTML report in the out/ directory
genhtml $COVERAGE_FILE --output-directory out
# Show coverage report to the terminal
lcov --list $COVERAGE_FILE
# Open HTML
open out/index.html
GCC Compilation
#!/bin/bash
# Rationale: https://vaneyckt.io/posts/safer_bash_scripts_with_set_euxo_pipefail/
set -euxo pipefail
# BASE_DIR is the project's directory, containing the src/ and tests/ folders.
BASE_DIR=$PWD
COVERAGE_FILE=coverage.info
GCOV_PATH=/usr/local/bin/gcov-11
GCC_PATH=/usr/local/bin/gcc-11
GPP_PATH=/usr/local/bin/g++-11
rm -rf build
mkdir build && cd build
# Configure
cmake -DCMAKE_C_COMPILER=$GCC_PATH -DCMAKE_CXX_COMPILER=$GPP_PATH -DCODE_COVERAGE=ON -DCMAKE_BUILD_TYPE=Release ..
# Build (for Make on Unix equivalent to `make -j $(nproc)`)
cmake --build . --config Release
# Clean-up for any previous run.
rm -f $COVERAGE_FILE
lcov --zerocounters --directory .
# Run tests
./tests/RunTests
# Create coverage report by taking into account only the files contained in src/
lcov --capture --directory tests/ -o $COVERAGE_FILE --include "$BASE_DIR/src/*" --gcov-tool $GCOV_PATH
# Create HTML report in the out/ directory
genhtml $COVERAGE_FILE --output-directory out
# Show coverage report to the terminal
lcov --list $COVERAGE_FILE
# Open HTML
open out/index.html
You are actually asking two questions, here.
Why do the coverage results differ between these two compilers?
How do I structure a CMake project for code coverage?
Answer 1: Coverage differences
The simple answer here is that you are building in Release mode, rather than RelWithDebInfo mode. GCC does not put as much debugging information in by default as Clang does. On my system, adding -DCMAKE_CXX_FLAGS="-g" to your build-and-run-cov-gcc.sh script yields the same results as Clang, as does building in RelWithDebInfo.
For whatever reason, it appears that Clang tracks more debug information either by default or when coverage is enabled. GCC does not have these same guardrails. The lesson to take away is this: collecting coverage information is a form of debugging; you must use a debugging-aware configuration for your compiler if you want accurate results.
Answer 2: Build system structure
It is generally a terrible idea to set CMAKE_CXX_FLAGS inside your build. That variable is intended to be a hook for your build's users to inject their own flags. As I detail in another answer on this site, the modern approach to storing such settings is in the presets
I would get rid of the if (CODE_COVERAGE) section of your top-level CMakeLists.txt and then create the following CMakePresets.json file:
{
"version": 4,
"cmakeMinimumRequired": {
"major": 3,
"minor": 23,
"patch": 0
},
"configurePresets": [
{
"name": "gcc-coverage",
"displayName": "Code coverage (GCC)",
"description": "Enable code coverage on GCC-compatible compilers",
"binaryDir": "${sourceDir}/build",
"cacheVariables": {
"CMAKE_BUILD_TYPE": "RelWithDebInfo",
"CMAKE_CXX_FLAGS": "-fprofile-arcs -ftest-coverage"
}
}
],
"buildPresets": [
{
"name": "gcc-coverage",
"configurePreset": "gcc-coverage",
"configuration": "RelWithDebInfo"
}
]
}
Then your build script can be simplified considerably.
#!/bin/bash
# Rationale: https://vaneyckt.io/posts/safer_bash_scripts_with_set_euxo_pipefail/
set -euxo pipefail
# Set up defaults for CC, CXX, GCOV_PATH
export CC="${CC:-gcc-11}"
export CXX="${CXX:-g++-11}"
: "${GCOV_PATH:=gcov-11}"
# Record the base directory
BASE_DIR=$PWD
# Clean up old build
rm -rf build
# Configure
cmake --preset gcc-coverage
# Build
cmake --build --preset gcc-coverage
# Enter build directory
cd build
# Clean-up counters for any previous run.
lcov --zerocounters --directory .
# Run tests
./tests/RunTests
# Create coverage report by taking into account only the files contained in src/
lcov --capture --directory tests/ -o coverage.info --include "$BASE_DIR/src/*" --gcov-tool $GCOV_PATH
# Create HTML report in the out/ directory
genhtml coverage.info --output-directory out
# Show coverage report to the terminal
lcov --list coverage.info
# Open HTML
open out/index.html
The key here is the following lines:
# Configure
cmake --preset gcc-coverage
# Build
cmake --build --preset gcc-coverage
This script now lets you vary the compiler and coverage tool via environment variables and the CMakeLists.txt doesn't have to make any assumptions about what compiler is being used.
On my (Linux) system, I can run the following commands successfully:
$ CC=gcc-12 CXX=g++-12 GCOV=gcov-12 ./build-and-run-cov.sh
$ CC=clang-13 CXX=clang++-13 GCOV=$PWD/llvm-cov-13.sh ./build-and-run-cov.sh
Where llvm-cov-13.sh is a wrapper for llvm-cov-13 for compatibility with the --gcov-tool flag. See this answer for more detail.
#!/bin/bash
exec llvm-cov-13 gcov "$#"
As you can see, the results are indistinguishable now that the correct flags are used.

How can I compile Hazelcast C++ Client with the compiler g++-8.2

Is there any solution to make compilation with g++-8.2 for the project using Hazelcast C++ client library ?
If I compile it with g++-8.2, it shows a lot of errors "undefined reference ...".
While using g++-4.9, it works well.
The issue is a bit like the discussion in this google group forum, which indicated the compilation errors are because of the wrong version of a compiler.
However, the compiler g++-4.9 is too old for me to build my big project.
The sample code can be found in the official org website, if someone needs to give it a try.
I finally solved it by upgrading the library from 3.10 to 3.11.
The 3.11 library is built manually using g++-8.2 from Hazelcast source code in Github.
Because there is no make install after building hazelcast-cpp-clienet package, so I use some scripts to arrange header files together in one directory (hazelcast-cpp-client/include) so that a program can easily link the library and headers.
Build script:
#!/bin/bash
# Package Requirements:
# - asio
mkdir hazelcast-cpp-client ; cd hazelcast-cpp-client
# Build
git clone https://github.com/hazelcast/hazelcast-cpp-client.git
mv hazelcast-cpp-client tmp
cd tmp
git checkout v3.11
mkdir release ; cd release
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_BUILD_TYPE=Release ..
make
# Back to 'hazelcast-cpp-client' directory
cd ../..
# Copy .a library out from tmp/
cp tmp/release/*.a .
# Arrange all header files in an one directory
cp -r tmp/hazelcast/include .
cp -r tmp/hazelcast/generated-sources/include/hazelcast/client/protocol ./include/hazelcast/client
rm tmp/external/include/*.md # We don't need readme file
cp -r tmp/external/include/* ./include
# Delete tmp directory
rm -rf tmp
Compilation command is like:
g++ -std=c++11 \
-I/path/to/hazelcast-cpp-client/include \
hz_test.cpp \
/path/to/hazelcast-cpp-client/libHazelcastClient3.11_64.a \
-lpthread
Thanks for reporting this problem. We did not test with the g++-8.2 compiler. I opened an issue to solve the problems: https://github.com/hazelcast/hazelcast-cpp-client/issues/494
Can you tell me also your OS environment? What distribution and version is it?

go unit test runs from %APPDATA%

I am trying to run some of my Go unit tests using "go test" but the test executable is built and run from my machine's %APPDATA%/local/temp directory. My PC has IT enforcement which blocks any unrecognized executable from being run other than from a pre-sanctioned directory (i.e C:/dev/projects"). All my Go source code are in that directory, including my *_test.go files. Is there a way to tell the Go test module to build and run from the current directory?
Yes you can.
Setting temp directory before executing the go test. By default temp directory environment variable gets evaluated in the order of TMP, TEMP, USERPROFILE, Windows directory; refer to msdn doc.
Basically it complies the go test under given temp directory and execute it.
C:\> cd dev\projects\src\mygotest
C:\dev\projects\src\mygotest>echo %CD%
C:\dev\projects\src\mygotest
C:\dev\projects\src\mygotest>set TMP=%CD%
C:\dev\projects\src\mygotest>go test -x
WORK=C:\dev\projects\src\mygotest\go-build306298926
mkdir -p $WORK\mygotest\_test\
mkdir -p $WORK\mygotest\_test\_obj_test\
cd C:\dev\projects\src\mygotest
"C:\\Go\\pkg\\tool\\windows_amd64\\compile.exe" -o "C:\\dev\\projects\\src\\mygotest\\go-build306298926\\mygotest\\_test\\mygotest.a" -trimpath "C:\\dev\\projects\\src\\mygotest\\go-build306298926" -p main -complete -buildid 86cb7a423d355c7468ad98c4f8bffe77b68d2265 -D _/C_/dev/projects/src/mygotest -I "C:\\dev\\projects\\src\\mygotest\\go-build306298926" -pack "C:\\dev\\projects\\src\\mygotest\\sample.go" "C:\\dev\\projects\\src\\mygotest\\sample_test.go"
cd $WORK\mygotest\_test
"C:\\Go\\pkg\\tool\\windows_amd64\\compile.exe" -o "C:\\dev\\projects\\src\\mygotest\\go-build306298926\\mygotest\\_test\\main.a" -trimpath "C:\\dev\\projects\\src\\mygotest\\go-build306298926" -p main -complete -D "" -I "C:\\dev\\projects\\src\\mygotest\\go-build306298926\\mygotest\\_test" -I "C:\\dev\\projects\\src\\mygotest\\go-build306298926" -pack "C:\\dev\\projects\\src\\mygotest\\go-build306298926\\mygotest\\_test\\_testmain.go"
cd .
"C:\\Go\\pkg\\tool\\windows_amd64\\link.exe" -o "C:\\dev\\projects\\src\\mygotest\\go-build306298926\\mygotest\\_test\\mygotest.test.exe" -L "C:\\dev\\projects\\src\\mygotest\\go-build306298926\\mygotest\\_test" -L "C:\\dev\\projects\\src\\mygotest\\go-build306298926" -w -extld=gcc -buildmode=exe "C:\\dev\\projects\\src\\mygotest\\go-build306298926\\mygotest\\_test\\main.a"
$WORK\mygotest\_test\mygotest.test.exe
Hello, playground
PASS
ok mygotest 0.526s
C:\dev\projects\src\mygotest>
Note: TMP set to current terminal session only, it doesn't affect system environment variable.
Important thing to note from above test output is WORK=C:\dev\projects\src\mygotest\go-build306298926.
Happy testing!

.h: No such file or directory YOCTO/Openembedded

I am trying to compile a simple PJSIP program with Yocto/Openembedded. And I have this error : fatal error: pjsua-lib/pjsua.h: No such file or directoryHere is my Makefile:
all: simple_pjsua
simple_pjsua: simple_pjsua.c
$(CC) -o $# $< `pkg-config --cflags --libs libpjproject`
clean:
rm -f simple_pjsua.o simple_pjsua
And here is my simplepjsua_2.6.bb:
DESCRIPTION = "Open source SIP stack and media stack for presence, im/instant \
messaging, and multimedia communication"
SECTION = "libs"
HOMEPAGE = "http://www.pjsip.org/"
# there are various 3rd party sources which may or may not be part of the
# build, there license term vary or are not explicitely specified.
LICENSE = "CLOSED"
PR = "r0"
SRC_URI = "file://simple_pjsua.c \
file://Makefile \
file://README.txt"
S = "${WORKDIR}/"
do_compile() {
cd ${S}
#to prevent libpjproject.PC not found error
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
oe_runmake
}
do_install() {
install -m 0755 -d ${D}${bindir} ${D}${docdir}/simple_pjsua
install -m 0755 ${S}/simple_pjsua ${D}${bindir}
install -m 0755 ${WORKDIR}/README.txt ${D}${docdir}/simple_pjsua
}
I tried adding INC=-I/usr/include/pjsua-lib/ in the Makefile but nothing changed.. And if I want to compile it on my computer with make it's working.
What can I do?
EDIT :
I tried adding export LD_LIBRARY_PATH=/usr/include in do_compile() in the bb file. Same issue
You're linking against host libraries which really isn't the right thing to do unless you're building a native package (which you are not).
You need to make a recipe for pjsip to build and install that, and then this recipe should DEPEND on that.
make sure that /usr/include/pjsua-lib/pjsua.h file exist.
# INC=-I/usr/include/pjsua-lib # not ok
INC=-I/usr/include

How can I set rpath on gcc binaries during bootstrap?

I am trying to build gcc 4.7.2 using a custom prefix $PREFIX
I have built and installed all the prerequisites into my prefix location, and then successfully configured, built and installed gcc.
The problem that I now have is that $PREFIX is not in the library search path, and therefore the shared libraries cannot be found.
$PREFIX/bin $ ./g++ ~/main.cpp
$PREFIX/libexec/gcc/x86_64-suse-linux/4.7.2/cc1plus: \
error while loading shared libraries: \
libcloog-isl.so.1: \
cannot open shared object file: No such file or directory
What works, but isn't ideal
If I export LD_LIBRARY_PATH=$PREFIX/lib then it works, but I'm looking for something which works without having to set environment variables.
If I use patchelf to set the RPATH on all the gcc binaries then it also works; however this involves searching out all elf binaries and iterating over them calling patchelf, I would rather have something more permanent.
What I think would be ideal for my purposes
So I'm hoping there is a way to have -Wl,-rpath,$PREFIX/lib passed to make during the build process.
Since I know the paths won't need to be changed this seems like the most robust solution, and can be also be used for when we build the next gcc version.
Is configuring the build process to hard code the RPATH possible?
What I have tried, but doesn't work
Setting LDFLAGS_FOR_TARGET prior to calling configure:
All of these fail:
export LDFLAGS_FOR_TARGET="-L$PREFIX/lib -R$PREFIX/lib"
export LDFLAGS_FOR_TARGET="-L$PREFIX/lib"
export LDFLAGS_FOR_TARGET="-L$PREFIX/lib -Wl,-rpath,$PREFIX/lib"
Setting LDFLAGS prior to calling configure:
export LDFLAGS="-L$PREFIX/lib -Wl,-rpath,$PREFIX/lib"
In any event I worry that these will override any of the LDFLAGS gcc would have had, so I'm not sure these are a viable option even if they could be made to work?
My configure line
For completeness here is the line I pass to configure:
./configure \
--prefix=$PREFIX \
--build=x86_64-suse-linux \
--with-pkgversion='SIG build 12/10/2012' \
--disable-multilib \
--enable-cloog-backend=isl \
--with-mpc=$PREFIX \
--with-mpfr=$PREFIX \
--with-gmp=$PREFIX \
--with-cloog=$PREFIX \
--with-ppl=$PREFIX \
--with-gxx-include-dir=$PREFIX/include/c++/4.7.2
I've found that copying the source directories for gmp, mpfr, mpc, isl, cloog, etc. into the top level gcc source directory (or using symbolic links with the same name) works everywhere. This is in fact the preferred way.
You need to copy (or link) to those source directory names without the version numbers for this to work.
The compilers do not need LD_LIBRARY_PATH (although running applications built with the compilers will need an LD_LIBRARY_PATH to the $PREFIX/lib64 or something like that - but that's different)
Start in a source directory where you'll keep all your sources.
In this source directory you have your gcc directory either by unpacking a tarball or svn...
I use subversion.
Also in this top level directory you have, say, the following source tarballs:
gmp-5.1.0.tar.bz2
mpfr-3.1.1.tar.bz2
mpc-1.0.1.tar.gz
isl-0.11.1.tar.bz2
cloog-0.18.0.tar.gz
I just download these and update to the latest tarballs periodically.
In script form:
# Either:
svn checkout svn://gcc.gnu.org/svn/gcc/trunk gcc_work
# Or:
bunzip -c gcc-4.8.0.tar.bz2 | tar -xvf -
mv gcc-4.8.0 gcc_work
# Uncompress sources.. (This will produce version numbered directories).
bunzip -c gmp-5.1.0.tar.bz2 | tar -xvf -
bunzip -c mpfr-3.1.1.tar.bz2 | tar -xvf -
gunzip -c mpc-1.0.1.tar.gz | tar -xvf -
bunzip -c isl-0.11.1.tar.bz2 | tar -xvf -
gunzip -c cloog-0.18.0.tar.gz | tar -xvf -
# Link outside source directories into the top level gcc directory.
cd gcc_work
ln -s ../gmp-5.1.0 gmp
ln -s ../mpfr-3.1.1 mpfr
ln -s ../mpc-1.0.1 mpc
ln -s ../isl-0.11.1 isl
ln -s ../cloog-0.18.0 cloog
# Get out of the gcc working directory and create a build directory. I call mine obj_work.
# I configure the gcc binary and other outputs to be bin_work in the top level directory. Your choice. But I have this:
# home/ed/projects
# home/ed/projects/gcc_work
# home/ed/projects/obj_work
# home/ed/projects/bin_work
# home/ed/projects/gmp-5.1.0
# home/ed/projects/mpfr-3.1.1
# home/ed/projects/mpc-1.0.1
# home/ed/projects/isl-0.11.1
# home/ed/projects/cloog-0.18.0
mkdir obj_work
cd obj_work
../gcc_work/configure --prefix=../bin_work <other options>
# Your <other options> shouldn't need to involve anything about gmp, mpfr, mpc, isl, cloog.
# The gcc build system will find the directories you linked,
# then configure and compile the needed libraries with the necessary flags and such.
# Good luck.
I've been using this configure option with gcc-4.8.0, on FreeBSD, after building and installing gmp, isl and cloog:
LD_LIBRARY_PATH=/path/to/isl/lib ./configure (lots of other options) \
--with-stage1-ldflags="-rpath /path/to/isl/lib -rpath /path/to/cloog/lib -rpath /path/to/gmp/lib"
and the resulting gcc binary does not need any LD_LIBRARY_PATH. The LD_LIBRARY_PATH for configure is needed because it compiles a test program to check for the ISL version, which would fail if it didn't find the ISL shared lib.
I tried it on Linux (Ubuntu) where it failed during configuring because the -rpath args were passed to gcc instead of ld. I could fix this by using
--with-stage1-ldflags="-Wl,-rpath,/path/to/isl/lib,-rpath,/path/to/cloog/lib,-rpath,/path/to/gmp/lib"
instead.
Just using configure --with-stage1-ldflags="-Wl,-rpath,/path/to/lib" was not enough for me to build gcc 4.9.2, bootstrap failed in stage 2. What works is to pass he flags directly to make via
make BOOT_LDFLAGS="-Wl,-rpath,/path/to/lib"
I got this from https://gcc.gnu.org/ml/gcc/2008-09/msg00214.html
While it still involves setting environment variables, what I do is that I define LD_RUN_PATH, which sets the rpath. That way the rest of the system can keep using the system provided libraries instead of using the ones that your gcc build generates.
I am going to make a suggestion that I believe solves your problem, although it definitely does not answer your question. Let's see how many downvotes I get.
Writing a generic wrapper script to set LD_LIBRARY_PATH and then to run the executable is easy; see https://stackoverflow.com/a/7101577/768469.
The idea is to pass something like --prefix=$PREFIX/install to configure, building an install tree that looks like this:
$PREFIX/
install/
lib/
libcloogXX.so
libgmpYY.so
...
bin/
gcc
emacs
...
bin/
.wrapper
gcc -> .wrapper
emacs -> .wrapper
.wrapper is a simple shell script:
#!/bin/sh
here="${0%/*}" # or use $(dirname "$0")
base="${0##*/}" # or use $(basename "$0")
libdir="$here"/../install/lib
if [ "$LD_LIBRARY_PATH"x = x ] ; then
LD_LIBRARY_PATH="$libdir"
else
LD_LIBRARY_PATH="$libdir":"$LD_LIBRARY_PATH"
fi
export LD_LIBRARY_PATH
exec "$here"/../install/bin/"$base" "$#"
This will forward all arguments correctly, handle spaces in arguments or directory names, and so forth. For practical purposes, it is indistinguishable from setting the rpath like you want.
Also, you can use this approach not only for gcc, but for your entire my-personal-$PREFIX tree. I do this all the time in environments where I want an up-to-date suite of GNU tools, but I do not have (or want to admit to have) root access.
Try to add your $PREFIX to /etc/ld.so.conf and then run ldconfig:
# echo $PREFIX >> /etc/ld.so.conf
# ldconfig
This will recreate cache that is used by runtime linker and it will pick up your libraries.
WARNING: This operation will cause ALL applications to use your newly compiled libraries in $PREFIX instead of default location