编译出错 [ 17%] Built target crypto as: symbol lookup error: as: undefined symbol: deflate
Opened this issue · 2 comments
What are the problems?(screenshots or detailed error messages)
What are the types of GPU/CPU you are using?
What's the operating system ppl.llm.serving runs on?
What's the compiler and its version?
Which version(commit id or tag) of ppl.llm.serving is used?
What are the commands used to build ppl.llm.serving?
What are the execution commands?
minimal code snippets for reproducing these problems(if necessary)
models and inputs for reproducing these problems (send them to openppl.ai@hotmail.com if necessary)
sudo apt-get install zlib1g-dev
Another work-around. I also encountered this issue on Ubuntu 20.04.3 LTS (Focal Fossa) with gcc version 9.4.0.
The compilation actually breaks due to as
run failure, NOT a typical undefined symbol
issue which usually occurred during linking. When I check the dynamic dependence of executable as
, I found that:
user@hostname:~/ppl.llm.serving/ppl-build (master)$ ldd `which as`
linux-vdso.so.1 (0x00007ffd705c6000)
libopcodes-2.34-system.so => /lib/x86_64-linux-gnu/libopcodes-2.34-system.so (0x00007f066b2ad000)
libbfd-2.34-system.so => /lib/x86_64-linux-gnu/libbfd-2.34-system.so (0x00007f066b166000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f066b14a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f066af22000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f066af1d000)
It turns out that as
depends on zlib
as well.
Then, if we check the build command in grpc-build/third_party/zlib/CMakeFiles/zlibstatic.dir/build.make
(at line 188 in my case), we'll find that:
cd /data/workspace/ppl.llm.serving/ppl-build/grpc-build/third_party/zlib && /usr/bin/cc $(C_DEFINES) $(C_INCLUDES) $(C_FLAGS) -MD -MT grpc-build/third_party/zlib/CMakeFiles/zlibstatic.dir/inflate.o -MF CMakeFiles/zlibstatic.dir/inflate.o.d -o CMakeFiles/zlibstatic.dir/inflate.o -c /data/workspace/ppl.llm.serving/deps/grpc/third_party/zlib/inflate.c
The cmake-generated command first change directory to .../zlib
, and then run the compiler. However, this is where the compilation breaks, since .../zlib
has another libz.so
which is newly built and maybe INCONSISTENT. This can be checked by ls
, and running ldd
in .../zlib
directory:
user@hostname:~/ppl.llm.serving/ppl-build/grpc-build/third_party/zlib $ ldd `which as`
linux-vdso.so.1 (0x00007ffd60389000)
libopcodes-2.34-system.so => /lib/x86_64-linux-gnu/libopcodes-2.34-system.so (0x00007ff51c340000)
libbfd-2.34-system.so => /lib/x86_64-linux-gnu/libbfd-2.34-system.so (0x00007ff51c1f9000)
libz.so.1 (0x00007ff51c1f4000) <=== here is the difference!!!!!!!!!
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff51bfcc000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff51bfc7000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff51c55d000)
Therefore, because as
is launched in .../zlib
directory on which another (maybe inconsistent) libz
library resides, the correct system libz
is not loaded.
The work-around is straightforward, just not run as
in .../zlib
directory (in my case I change it to upper directory).
Modify Ln188 of grpc-build/third_party/zlib/CMakeFiles/zlibstatic.dir/build.make
.
#cd /data/workspace/ppl.llm.serving/ppl-build/grpc-build/third_party/zlib && /usr/bin/cc $(C_DEFINES) $(C_INCLUDES) $(C_FLAGS) -MD -MT grpc-build/third_party/zlib/CMakeFiles/zlibstatic.dir/inflate.o -MF CMakeFiles/zlibstatic.dir/inflate.o.d -o CMakeFiles/zlibstatic.dir/inflate.o -c /data/workspace/ppl.llm.serving/deps/grpc/third_party/zlib/inflate.c
cd /data/workspace/ppl.llm.serving/ppl-build/grpc-build/third_party && /usr/bin/cc $(C_DEFINES) $(C_INCLUDES) $(C_FLAGS) -MD -MT zlib/grpc-build/third_party/zlib/CMakeFiles/zlibstatic.dir/inflate.o -MF zlib/CMakeFiles/zlibstatic.dir/inflate.o.d -o zlib/CMakeFiles/zlibstatic.dir/inflate.o -c /data/workspace/ppl.llm.serving/deps/grpc/third_party/zlib/inflate.c