当我使用带有共享库的二进制文件执行
显然，这是因为
因此：
LD_PRELOAD和LD_LIBRARY_PATH的区别，来自ld.so man：
LD_PRELOAD是一个环境变量，它指定要在程序启动时预加载的共享库文件。这些库文件将覆盖默认的库文件，从而改变程序的行为。
LD_LIBRARY_PATH也是一个环境变量，它指定要搜索共享库文件的路径。当程序需要链接库文件时，它会在这些路径中查找。
总之，LD_PRELOAD主要用于修改程序的行为，而LD_LIBRARY_PATH则用于指定程序所需的库文件路径。
为什么使用LD_PRELOAD可以正常工作而使用LD_LIBRARY_PATH却无法正常工作？
qemu-aarch64时，会得到以下结果： qemu-aarch64 -L /usr/aarch64-linux-gnu ./test
./test: error while loading shared libraries: testlibrary.so.1: cannot open shared object file: No such file or directory
显然，这是因为
test不知道共享库在哪里。因此：
qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_PRELOAD="/home/test/libraries/testlibrary.so.1 /home/test/libraries/testlibrary2.so.1" ./test
hi!
好的，它能够工作；但是当我使用LD_LIBRARY_PATH时它不能工作：
qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_LIBRARY_PATH="/home/test/libraries ./test
./test: error while loading shared libraries: testlibrary.so.1: cannot open shared object file: No such file or directory
LD_PRELOAD和LD_LIBRARY_PATH的区别，来自ld.so man：
LD_PRELOAD是一个环境变量，它指定要在程序启动时预加载的共享库文件。这些库文件将覆盖默认的库文件，从而改变程序的行为。
LD_LIBRARY_PATH也是一个环境变量，它指定要搜索共享库文件的路径。当程序需要链接库文件时，它会在这些路径中查找。
总之，LD_PRELOAD主要用于修改程序的行为，而LD_LIBRARY_PATH则用于指定程序所需的库文件路径。
LD_PRELOAD:
A list of additional, user-specified, ELF shared objects
to be loaded before all others. This feature can be used
to selectively override functions in other shared objects.
The items of the list can be separated by spaces or
colons, and there is no support for escaping either
separator. The objects are searched for using the rules
given under DESCRIPTION. Objects are searched for and
added to the link map in the left-to-right order specified
in the list.
In secure-execution mode, preload pathnames containing
slashes are ignored. Furthermore, shared objects are
preloaded only from the standard search directories and
only if they have set-user-ID mode bit enabled (which is
not typical).
Within the names specified in the LD_PRELOAD list, the
dynamic linker understands the tokens $ORIGIN, $LIB, and
$PLATFORM (or the versions using curly braces around the
names) as described above in Dynamic string tokens. (See
also the discussion of quoting under the description of
LD_LIBRARY_PATH.)
There are various methods of specifying libraries to be
preloaded, and these are handled in the following order:
(1) The LD_PRELOAD environment variable.
(2) The --preload command-line option when invoking the
dynamic linker directly.
(3) The /etc/ld.so.preload file (described below).
同时，
LD_LIBRARY_PATH:
A list of directories in which to search for ELF libraries
at execution time. The items in the list are separated by
either colons or semicolons, and there is no support for
escaping either separator. A zero-length directory name
indicates the current working directory.
This variable is ignored in secure-execution mode.
Within the pathnames specified in LD_LIBRARY_PATH, the
dynamic linker expands the tokens $ORIGIN, $LIB, and
$PLATFORM (or the versions using curly braces around the
names) as described above in Dynamic string tokens. Thus,
for example, the following would cause a library to be
searched for in either the lib or lib64 subdirectory below
the directory containing the program to be executed:
$ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog
(Note the use of single quotes, which prevent expansion of
$ORIGIN and $LIB as shell variables!)
为什么使用LD_PRELOAD可以正常工作而使用LD_LIBRARY_PATH却无法正常工作？