-1

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.

  1. 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).

  • 1
    Regular usage of Unix does not require LD_PRELOAD, and the now-missing file makes me wonder if it is/was some kind of malware. Not being a malware expert, I'm just leaving this as a comment. – Aaron D. Marasco Jun 6 '18 at 23:20
  • Did you by any chance try to install a different compiler? – Stephen Kitt Jun 7 '18 at 6:32
  • @StephenKitt: Nope. – einpoklum Jun 7 '18 at 8:21
  • I’m voting to close this as unreproducible because it’s caused by a piece of proprietary software which others are unlikely to encounter (hopefully). – Stephen Kitt Jun 7 '18 at 8:56
  • @StephenKitt: It's reproducible by putting junk in your .bashrc, which could happen for all sorts of reasons. – einpoklum Jun 7 '18 at 9:18
1

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.

  • 1
    To make this useful for others, would you mind naming and shaming? I take it this is one of the many mining programs doing the rounds. – Stephen Kitt Jun 7 '18 at 8:35
  • @StephenKitt: It's not a publicly accessible piece of software. – einpoklum Jun 7 '18 at 8:53
-1

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.

  • I don't see why I would force the locale to C. It is what it is. Other than that +1. – einpoklum Jun 7 '18 at 10:41
  • This is what larger project tend to do. If you are sure that you don't need it, be free not to do so. BTW: in the early 1990s, there have been C compilers that did not parse floating point constants correctly in case they have been run in a non-C locale since most locales in the world use a comma as fraction separator. – schily Jun 7 '18 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.