Gcc/LD compilation link Hidden Rules (fifth bullet): Why is there undified symbol?

Gcc/LD compilation link Hidden Rules (fifth bullet): Why is there undified symbol?

• Nemozhang

04d0ugknyvjtx1snigotteo5tvfxoaybpxck5bmqr94zlcu6xfw

Question 1:
Have you ever encountered: when loading some so files, the prompt undified symbol often causes the loading to fail, but the makefile clearly contains the specified library. How can it still be undified?

Question 2:
Have you ever encountered this problem? You can view so through LDD-R and find that the output contains undified symbol, but it can still be loaded normally.

Solution to problem 1
What we need to solve is how to make so correctly find the symbol.
One of the possible reasons:
Suppose we know that the undified symbol exists in XXX..
Although XXX is added to makefile. A dependency, however, must put XXX. A is placed at the end. because so may be dependent on other. library a also uses XXX. a.
(PS: Why do you need to put it later? refer to other articles in this series)

Real case:
During a compilation of the so file LDD-R in the compilation result, undified symbol was found, but the corresponding open_l5 library was clearly linked. Why does the system still prompt that no symbols are found?
File bin/spp_appwork.so
Bin/spp_appwork.so: Elf 32-bit LSB shared object, Intel 80386, Version 1 (sysv), not stripped

LDD-r bin/spp_appwork.so 2> & 1 | grep-V "tbase \ | Tencent \ | write_log \ | DL"
Linux-gate.so.1 => (0xbfffe000)
Libpthread. so.0 =>/lib/libpthread. so.0 (0xb7e7e000)
Libz. so.1 =>/usr/lib/libz. so.1 (0xb7e6c000)
Libcrypto. so.0.9.8 =>/usr/lib/libcrypto. so.0.9.8 (0xb7d40000)
Libstdc ++. so.6 =>/usr/lib/libstdc ++. so.6 (0xb7c5f000)
Libm. so.6 =>/lib/libm. so.6 (0xb7c3a000)
Libgcc_s.so.1 =>/lib/libgcc_s.so.1 (0xb7c2f000)
Libc. so.6 =>/lib/libc. so.6 (0xb7b0f000)
/Lib/ld-linux.so.2 (0x80000000)
Undefined Symbol: _ zn7copenl54loadeii (bin/spp_appwork.so)
Undefined Symbol: _ zn7copenl56updateei (bin/spp_appwork.so)

Solve the problem by adjusting the location of the open_l5 library.

Possible cause 2:
This symbol should belong to a so dependent on it, but it does not contain the specified symbol because of the low so version of the current environment.

This guess is verified by the following method:

// Follow the normal process to compile ld_so and run properly
Nemo @ vm04_sles10: [ld_so] $ g ++-O ld_so ld_so.cpp-L.-la
Nemo @ vm04_sles10: [ld_so] $./ld_so
Lalala
Call in FUNA ()

// Find another so to replace LIBA. So,
Nemo @ vm04_sles10: [ld_so] $ cp liba. So LIBA. So. BK
Nemo @ vm04_sles10: [ld_so] $ cp d. So LIBA. So

// Undefined symbol will be found at startup
Nemo @ vm04_sles10: [ld_so] $./ld_so
Lalala // <=========== the First Half of the code of the program is executed, and the lalala
./Ld_so: Symbol lookup error:./ld_so: Undefined Symbol: _ z4funav // <=========== an error is returned.

// You can view the undefined symbols through LDD-R.
Nemo @ vm04_sles10: [ld_so] $ LDD-r ld_so
Undefined Symbol: _ z4funav (./ld_so) // <=============== undefined symbol.
Linux-gate.so.1 => (0xbfffe000)
LIBA. So (0xb7f87000)
Libstdc ++. so.6 =>/usr/lib/libstdc ++. so.6 (0xb7e9d000)
Libm. so.6 =>/lib/libm. so.6 (0xb7e78000)
Libgcc_s.so.1 =>/lib/libgcc_s.so.1 (0xb7e6d000)
Libc. so.6 =>/lib/libc. so.6 (0xb7d4c000)
/Lib/ld-linux.so.2 (0xb7f8a000)

Case 2:
I also encountered a similar problem when creating the green lamp. When apache is started, the system prompts that libphp5.so fails to be loaded: Undefined Symbol: xmltextreadersetup
After investigation, we found that there is a libxml2.so in the/usr/local/bin directory of the system, which is inconsistent with the libxml2 version I used when compiling PHP at that time. By modifying LD_LIBRARY_PATH, to give priority to the libxml2 library under my specified directory.

Solution to problem 2
Even with undefined Symbol:, so can be loaded normally if the code is not used during execution?
Yes. However, once used, an error is reported. For example, in the preceding example, lalala is output by executing ld_so, And the undefined Symbol: _ z4funav symbol is not found.

Note:
LD allows undefined symbol when the link is used to generate so, because these real symbols may be solved when so is loaded.
When ld links to generate executable files, 04d0ugknyvjtx1snigotteo5tvfxoaybpxck5bmqr94zlcu6xfw of undefined symbol is not allowed.

Question 1:
Have you ever encountered: when loading some so files, the prompt undified symbol often causes the loading to fail, but the makefile clearly contains the specified library. How can it still be undified?

Question 2:
Have you ever encountered this problem? You can view so through LDD-R and find that the output contains undified symbol, but it can still be loaded normally.

Solution to problem 1
What we need to solve is how to make so correctly find the symbol.
One of the possible reasons:
Suppose we know that the undified symbol exists in XXX..
Although XXX is added to makefile. A dependency, however, must put XXX. A is placed at the end. because so may be dependent on other. library a also uses XXX. a.
(PS: Why do you need to put it later? refer to other articles in this series)

Real case:
During a compilation of the so file LDD-R in the compilation result, undified symbol was found, but the corresponding open_l5 library was clearly linked. Why does the system still prompt that no symbols are found?
File bin/spp_appwork.so
Bin/spp_appwork.so: Elf 32-bit LSB shared object, Intel 80386, Version 1 (sysv), not stripped

LDD-r bin/spp_appwork.so 2> & 1 | grep-V "tbase \ | Tencent \ | write_log \ | DL"
Linux-gate.so.1 => (0xbfffe000)
Libpthread. so.0 =>/lib/libpthread. so.0 (0xb7e7e000)
Libz. so.1 =>/usr/lib/libz. so.1 (0xb7e6c000)
Libcrypto. so.0.9.8 =>/usr/lib/libcrypto. so.0.9.8 (0xb7d40000)
Libstdc ++. so.6 =>/usr/lib/libstdc ++. so.6 (0xb7c5f000)
Libm. so.6 =>/lib/libm. so.6 (0xb7c3a000)
Libgcc_s.so.1 =>/lib/libgcc_s.so.1 (0xb7c2f000)
Libc. so.6 =>/lib/libc. so.6 (0xb7b0f000)
/Lib/ld-linux.so.2 (0x80000000)
Undefined Symbol: _ zn7copenl54loadeii (bin/spp_appwork.so)
Undefined Symbol: _ zn7copenl56updateei (bin/spp_appwork.so)

Solve the problem by adjusting the location of the open_l5 library.

Possible cause 2:
This symbol should belong to a so dependent on it, but it does not contain the specified symbol because of the low so version of the current environment.

This guess is verified by the following method:

// Follow the normal process to compile ld_so and run properly
Nemo @ vm04_sles10: [ld_so] $ g ++-O ld_so ld_so.cpp-L.-la
Nemo @ vm04_sles10: [ld_so] $./ld_so
Lalala
Call in FUNA ()

// Find another so to replace LIBA. So,
Nemo @ vm04_sles10: [ld_so] $ cp liba. So LIBA. So. BK
Nemo @ vm04_sles10: [ld_so] $ cp d. So LIBA. So

// Undefined symbol will be found at startup
Nemo @ vm04_sles10: [ld_so] $./ld_so
Lalala // <=========== the First Half of the code of the program is executed, and the lalala
./Ld_so: Symbol lookup error:./ld_so: Undefined Symbol: _ z4funav // <=========== an error is returned.

// You can view the undefined symbols through LDD-R.
Nemo @ vm04_sles10: [ld_so] $ LDD-r ld_so
Undefined Symbol: _ z4funav (./ld_so) // <=============== undefined symbol.
Linux-gate.so.1 => (0xbfffe000)
LIBA. So (0xb7f87000)
Libstdc ++. so.6 =>/usr/lib/libstdc ++. so.6 (0xb7e9d000)
Libm. so.6 =>/lib/libm. so.6 (0xb7e78000)
Libgcc_s.so.1 =>/lib/libgcc_s.so.1 (0xb7e6d000)
Libc. so.6 =>/lib/libc. so.6 (0xb7d4c000)
/Lib/ld-linux.so.2 (0xb7f8a000)

Case 2:
I also encountered a similar problem when creating the green lamp. When apache is started, the system prompts that libphp5.so fails to be loaded: Undefined Symbol: xmltextreadersetup
After investigation, we found that there is a libxml2.so in the/usr/local/bin directory of the system, which is inconsistent with the libxml2 version I used when compiling PHP at that time. By modifying LD_LIBRARY_PATH, to give priority to the libxml2 library under my specified directory.

Solution to problem 2
Even with undefined Symbol:, so can be loaded normally if the code is not used during execution?
Yes. However, once used, an error is reported. For example, in the preceding example, lalala is output by executing ld_so, And the undefined Symbol: _ z4funav symbol is not found.

Note:
LD allows undefined symbol when the link is used to generate so, because these real symbols may be solved when so is loaded.
When ld links to generate executable files, it does not allow undefined symbol.