An error is reported during program execution, and the error content is as follows
XXXX：symbol lookup error：/home/....../libpdfium.so：undefined symbol：CRYPT_MD5Generate
Error analysis:
This problem indicates that the symbol is not defined, and it is directly located in the third-party dynamic library libpdfium.so linked to the product, so I started from libpdfium.so.
Because of the source code of this third-party library, it is possible to find errors.
Error positioning:
But this symbol undefined error is a headache, because in my original idea, shouldn't the symbol bit definition be reported directly during compilation? So to confirm, I recompile the third-party source code and compile No error was reported, a new so was generated, replaced and re-run, the result is still an undefined package symbol error. Searching on the Internet, I know that when the link is wrong, it will also cause the undefined error of the symbol in the later period (see the end for the reference content). In this block, you can use the ldd -r command to check whether the generated so contains undefined symbols.
Looking at these undefined symbols, there are too many missing, and it shouldn't be. In my case, several static library files will be linked when generating libpdfium.so dynamic library. According to the information found on the Internet, confirm whether the linking static library sequence is correct. Directly search for the error string "CRYPT_MD5Generate" in the third-party source code, and found that there are two cpp files, one is declared and defined, and the other is called.
And in this block, you can see that fpdf_parse_encrypt depends on the fx_crypt file below. Looking at the static library, fpdf_parse_encrypt is compiled into fpdfapi.a, and fx_crypt is compiled into the pdrm.a static library, so fpdfapi.a should depend on pdrm .a static library. Check the link sequence in the Makefile again and find that the sequence is reversed! ! ! The culprit has been found! It is the wrong sequence of links in the Makefile that leads to undefined symbols in the final so!
Here are several useful commands and reference materials that I used in the search process.
After compiling and generating the dynamic link library, when calling:
# lichunhong @ lichunhong-ThinkPad-T470p in ~/Documents/src/effective_robotics_programming_with_ros-master/catkin_ws on git:lichunhong/dev x [18:54:05] C:127
$ rosrun path_plan PathPlanSimulation
/home/lichunhong/Documents/src/effective_robotics_programming_with_ros-master/catkin_ws/devel/lib/path_plan/PathPlanSimulation:
symbol lookup error: /home/lichunhong/Documents/src/effective_robotics_programming_with_ros-master/catkin_ws/src/pathPlan/lib/libpathplan.so:
undefined symbol: _ZN12ninebot_algo10AprAlgoLog9instance_E即 symbol lookup error: libpathplan.so: undefined symbol: _ZN12ninebot_algo10AprAlgoLog9instance_E
When this kind of problem occurs, it is often a problem when linking. The following is a three-step solution
(1) Use the file command to view the architecture of the so library to see if it is consistent with the platform
As you can see, the current so library architecture is x86-64, which can be used under the GNU/Linux platform. Consistent platform and architecture
# lichunhong @ lichunhong-ThinkPad-T470p in ~/Documents/src/motion_planner/bin on git:dev x [18:47:54]
$ file libpathplan.so
libpathplan.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked,
BuildID[sha1]=32ae641e73c547376df20ca94746fbf5507de415, not strippedNext, you need to locate the specific information of undefined symbol
(2) View the link status and error information of the so library through the ldd -r xxx.so command
ldd command, you can check which libraries the corresponding executable file or library file depends on, but the executable file or library file requirements are the same as the compiler type of the operating system, that is, the computer is an X86 GCC compiler, then the ARM cannot be viewed through the ldd command The executable file or library file compiled by the cross compiler.
If you want to view the dependencies of the ARM cross-compiled executable programs and library files on Linux hosts such as Ubuntu, you can use the following command:
readelf -d xxx.so | grep NEEDED
# lichunhong @ lichunhong-ThinkPad-T470p in ~/Documents/src/effective_robotics_programming_with_ros-master/catkin_ws/src/pathPlan/lib on git:lichunhong/dev x [18:57:19]
$ ldd -r libpathplan.so
linux-vdso.so.1 => (0x00007ffec1bd8000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f186cc0a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f186c901000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f186c6eb000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f186c321000)
/lib64/ld-linux-x86-64.so.2 (0x00007f186d27a000)
undefined symbol: pthread_create (./libpathplan.so)
undefined symbol: _ZN12ninebot_algo10AprAlgoLog9instance_E (./libpathplan.so)
undefined symbol: _ZN2cv3maxERKNS_3MatES2_ (./libpathplan.so)
undefined symbol: _ZN12ninebot_algo10AprAlgoLog8WriteLogE10LEVEL_TYPEPKcS3_z (./libpathplan.so)
undefined symbol: _ZN2cv6dilateERKNS_11_InputArrayERKNS_12_OutputArrayES2_NS_6Point_IiEEiiRKNS_7Scalar_IdEE (./libpathplan.so)
undefined symbol: _ZN2cvgtERKNS_3MatEd (./libpathplan.so)
undefined symbol: _ZN2cv8fastFreeEPv (./libpathplan.so)
undefined symbol: _ZN2cv3Mat5setToERKNS_11_InputArrayES3_ (./libpathplan.so)
undefined symbol: _ZN12ninebot_algo10AprAlgoLog9instance_E (./libpathplan.so)You can see that there are many undefined symbols, including the mentioned _ZN12ninebot_algo10AprAlgoLog9instance_E error
(3) Use c++filt symbol to locate the error in that C++ file
From the undefined symbol above, through c++filt <symbol>, you can locate most of the opencv problems
# lichunhong @ lichunhong-ThinkPad-T470p in ~/Documents/src/effective_robotics_programming_with_ros-master/catkin_ws/src/pathPlan/lib on git:lichunhong/dev x [19:04:26] C:1
$ c++filt _ZN2cv7waitKeyEi
cv::waitKey(int)
# lichunhong @ lichunhong-ThinkPad-T470p in ~/Documents/src/effective_robotics_programming_with_ros-master/catkin_ws/src/pathPlan/lib on git:lichunhong/dev x [19:04:31]
$ c++filt _ZN2cv3maxERKNS_3MatES2_
cv::max(cv::Mat const&, cv::Mat const&)