Why the library is not getting used
The dynamic linker will ignore LD_LIBRARY_PATH if the program to be loaded has setuid or setgid bit set, for security. Otherwise, there would be the old trick of using LD_LIBRARY_PATH or LD_PRELOAD to override an innocuous system/library call to do something else instead or in addition to what it's supposed to do.
If done to a setuid root program that's not protected against this trick, you would be able to control what the program does while having root privileges... and at that point, there would be no limits at all to what you could do.
You'll find a description of this security mechanism in the ld.so(8) man page:
Secure-execution mode
For security reasons, the effects of some environment variables are voided or modified if the dynamic linker determines that the binary should be run in secure-execution mode. (For details, see the discussion of individual environment variables below.) A binary is executed in secure-execution mode if the AT_SECURE entry in the auxiliary vector (see getauxval(3)) has a nonzero value. This entry may have a nonzero value for various reasons, including:
- The process's real and effective user IDs differ, or the real and effective group IDs differ. This typically occurs as a result of executing a set-user-ID or set-group-ID program.
- A process with a non-root user ID executed a binary that conferred capabilities to the process.
- A nonzero value may have been set by a Linux Security Module.
... followed by long-form descriptions of the LD_* environment variables and how each of them are affected by the secure-execution mode.
How to fix your problem
You could add /usr/local/lib to /etc/ld.so.conf or make your own /etc/ld.so.conf.d/*.conf file for it, then run ldconfig as root to make sure the new library path gets picked up... if you still have a working way to become root that's independent from sudo, that is!
Otherwise, you might need to boot into single-user/recovery mode, and gain access to the system just like if you had lost the root password. But instead of resetting the root password, you'd make the /etc/ld.so.conf[.d] modification as above.
Why the -E option of sudo won't help here
The sudoers(5) man page says:
Note that the dynamic linker on most operating systems will remove variables that can control dynamic linking from the environment of setuid executables, including sudo. Depending on the operating system this may include _RLD*, DYLD_*, LD_*, LDR_*, LIBPATH, SHLIB_PATH, and others. These type of variables are removed from the environment before sudo even begins execution and, as such, it is not possible for sudo to preserve them.
You said sudo - root gives you su: Authentication failure. The command and the error message don't quite match up. Did you actually run su - root instead? Then you might be running Ubuntu or some other Linux distribution that comes with the root account's password locked by default; those distributions typically rely heavily on sudo for admin access. If that is the case with your distribution, you are now discovering why deleting a standard system library located in /lib64 was not a great idea.
