mjhjmtu

For the past half-day or so, I've been having at least the following problems:

1. 
   

   I get errors about missing LD_PRELOAD entries: My LD_PRELOAD contains /lib64/libstdc++.so.6 (not sure if that makes sense), but that file is missing, so whenever I run anything, I get:

   
   
   

   ERROR: ld.so: object '/lib64/libstdc++.so.6' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
   

   
   

so, I looked at LD_PRELOAD, and it turns out to contain /lib64/libstdc++.so.6 - which doesn't exist.

2. 
   

   When trying to build projects with CMake, configuration fails, with errors such as:

   
   
   

   In file included from /usr/include/pthread.h:23:0,
    from /home/eyalroz/src/mine/cuda-api-wrappers/CMakeFiles/CMakeTmp/CheckIncludeFile.c:1:
   /usr/include/sched.h:28:20: fatal error: stddef.h: No such file or directory
   

   
   

but my stdddef.h is safely in /usr/include/linux/stddef.h.

I use GNU/Linux Mint 18.3, and I've not done anything weird with my system lately (well, not that I can remember anyway).

Here's what happened: I was building this program from sources. The genious maintainers decided that:

1. Everybody was running on the exact same machine and OS configuration as them


2. They need to put all of their settings in your $HOME/.bashrc so they can make assumptions in the build scripts.

That got my .bashrc littered with an export CC, export CXX, export C_INCLUDE_PATH, LD_PRELOAD and more stuff. And that messed things up.

Lesson learned: Always check your ~/.profile, ~/.shrc, ~/.bashrc, ~/.bash_profile, ~/.login, ~/.bash_login for weird new entries.

Using LD_PRELOAD as a standard setup is a really bad idea since it may affect the behavior of all software you run.

The intended use of LD_PRELOAD is mainly debugging and as a secondary use case you might replace the default malloc() implementation by another that better fits you usage.

Let me give an example when LD_PRELOAD is used for debugging. Let me assume, you have a program that starts to dump core and you suspect that this might be a result of a NULL pointer dereference. In this case, you may call:

LD_PRELOAD=0@0.so.1 program

and if this no longer dumps core, you verified that there was a NULL pointer dereference.

BTW: if you like predictable builds, your build environments should do this:

# clear environment variables we know to be bad for the build 
unset LD_OPTIONS 
unset LD_AUDIT LD_AUDIT_32 LD_AUDIT_64 
unset LD_BIND_NOW LD_BIND_NOW_32 LD_BIND_NOW_64 
unset LD_BREADTH LD_BREADTH_32 LD_BREADTH_64 
unset LD_CONFIG LD_CONFIG_32 LD_CONFIG_64 
unset LD_DEBUG LD_DEBUG_32 LD_DEBUG_64 
unset LD_DEMANGLE LD_DEMANGLE_32 LD_DEMANGLE_64 
unset LD_FLAGS LD_FLAGS_32 LD_FLAGS_64 
unset LD_LIBRARY_PATH LD_LIBRARY_PATH_32 LD_LIBRARY_PATH_64 
unset LD_LOADFLTR LD_LOADFLTR_32 LD_LOADFLTR_64 
unset LD_NOAUDIT LD_NOAUDIT_32 LD_NOAUDIT_64 
unset LD_NOAUXFLTR LD_NOAUXFLTR_32 LD_NOAUXFLTR_64 
unset LD_NOCONFIG LD_NOCONFIG_32 LD_NOCONFIG_64 
unset LD_NODIRCONFIG LD_NODIRCONFIG_32 LD_NODIRCONFIG_64 
unset LD_NODIRECT LD_NODIRECT_32 LD_NODIRECT_64 
unset LD_NOLAZYLOAD LD_NOLAZYLOAD_32 LD_NOLAZYLOAD_64 
unset LD_NOOBJALTER LD_NOOBJALTER_32 LD_NOOBJALTER_64 
unset LD_NOVERSION LD_NOVERSION_32 LD_NOVERSION_64 
unset LD_ORIGIN LD_ORIGIN_32 LD_ORIGIN_64 
unset LD_PRELOAD LD_PRELOAD_32 LD_PRELOAD_64 
unset LD_PROFILE LD_PROFILE_32 LD_PROFILE_64 

# 
# force locale to C
unset LC_ALL
LC_COLLATE=C; export LC_COLLATE 
LC_CTYPE=C; export LC_CTYPE 
LC_MESSAGES=C; export LC_MESSAGES 
LC_MONETARY=C; export LC_MONETARY 
LC_NUMERIC=C; export LC_NUMERIC 
LC_TIME=C; export LC_TIME 

in a script that controls automated builds or in a makefile in case that you use a make implementation that supports to manage environment variables from within makefiles. Editing the user's environment could be seen as a bad guys act.