Closed K-Wu closed 1 year ago
Thank you! Glad to hear it.
Hm. I think you should be linking any libraries before libc. The linker order is important; this is true for symbol conflicts in general, it's not specific to libfsm. What's your linker command line? Can you try putting -lre before the libc?
Hi there, we bypassed this issue by using dynamic load to select the .so to use. Originally, the problematic linker arguments generated by CMake is as follows. Could you tell if -lre is before libc? Thank you.
Best Regards, Kun
/usr/bin/c++ -fPIC -march=native -Wall -pthread -MMD -ldl -MP -fPIC -mavx -mavx2 -std=c++11 -ftree-vectorize -fopt-info-vec -Bdynamic -flto -shared -o curegex.cpython-36m-x86_64-linux-gnu.so CMakeFiles/curegex.dir/regex.cu.o CMakeFiles/curegex.dir/src/MySimpleNFA.cpp.o CMakeFiles/curegex.dir/src/char_string_int_conversion.cc.o CMakeFiles/curegex.dir/src/launch_re.cpp.o CMakeFiles/curegex.dir/include/src/NFA.cpp.o CMakeFiles/curegex.dir/include/src/NFALoader.cpp.o CMakeFiles/curegex.dir/include/src/graph_helper.cpp.o CMakeFiles/curegex.dir/include/src/node.cpp.o CMakeFiles/curegex.dir/include/src/pugixml.cpp.o CMakeFiles/curegex.dir/include/src/vasim_helper.cpp.o -L/usr/local/cuda-11/lib64 -L/home/kwu/Downloads/ece508project/libfsm/build/lib -L/usr/local/cuda-11/targets/x86_64-linux/lib/stubs -L/usr/local/cuda-11/targets/x86_64-linux/lib -Wl,-rpath,/usr/local/cuda-11/lib64:/home/kwu/Downloads/ece508project/libfsm/build/lib /usr/local/cuda-11/lib64/libcudart_static.a -ldl /usr/lib/x86_64-linux-gnu/librt.so -lre /usr/local/cuda-11/lib64/libcublas.so /usr/local/cuda-11/lib64/libcublasLt.so /usr/local/cuda-11/lib64/libcudart_static.a /usr/local/cuda-11/lib64/libcurand_static.a /usr/local/cuda-11/lib64/libcusolver_static.a /usr/local/cuda-11/lib64/libcusparse_static.a -lfsm -lpthread -ldl /usr/lib/x86_64-linux-gnu/librt.so /usr/local/cuda-11/lib64/libcublas_static.a /usr/local/cuda-11/lib64/libculibos.a -lcudadevrt -lcudart_static -lrt -lpthread -ldl
Reformatting the same thing you said so it's easier to see:
/usr/bin/c++ -fPIC -march=native -Wall -pthread -MMD -ldl -MP -fPIC -mavx -mavx2 -std=c++11 \
-ftree-vectorize -fopt-info-vec -Bdynamic -flto -shared \
-o curegex.cpython-36m-x86_64-linux-gnu.so \
CMakeFiles/curegex.dir/regex.cu.o CMakeFiles/curegex.dir/src/MySimpleNFA.cpp.o \
CMakeFiles/curegex.dir/src/char_string_int_conversion.cc.o \
CMakeFiles/curegex.dir/src/launch_re.cpp.o CMakeFiles/curegex.dir/include/src/NFA.cpp.o \
CMakeFiles/curegex.dir/include/src/NFALoader.cpp.o \
CMakeFiles/curegex.dir/include/src/graph_helper.cpp.o \
CMakeFiles/curegex.dir/include/src/node.cpp.o CMakeFiles/curegex.dir/include/src/pugixml.cpp.o \
CMakeFiles/curegex.dir/include/src/vasim_helper.cpp.o \
-L/usr/local/cuda-11/lib64 -L/home/kwu/Downloads/ece508project/libfsm/build/lib \
-L/usr/local/cuda-11/targets/x86_64-linux/lib/stubs -L/usr/local/cuda-11/targets/x86_64-linux/lib \
-Wl,-rpath,/usr/local/cuda-11/lib64:/home/kwu/Downloads/ece508project/libfsm/build/lib /usr/local/cuda-11/lib64/libcudart_static.a \ -ldl \
/usr/lib/x86_64-linux-gnu/librt.so \
-lre \
/usr/local/cuda-11/lib64/libcublas.so /usr/local/cuda-11/lib64/libcublasLt.so \
/usr/local/cuda-11/lib64/libcudart_static.a /usr/local/cuda-11/lib64/libcurand_static.a \ /usr/local/cuda-11/lib64/libcusolver_static.a /usr/local/cuda-11/lib64/libcusparse_static.a \
-lfsm -lpthread \
-ldl /usr/lib/x86_64-linux-gnu/librt.so \
/usr/local/cuda-11/lib64/libcublas_static.a /usr/local/cuda-11/lib64/libculibos.a \
-lcudadevrt -lcudart_static \
-lrt -lpthread -ldl
I'm not sure. I'd try moving -lre and -lfsm much earlier (right after your .o files). And if that doesn't work, try moving them much later (the last thing on the command line)
I think that makes sense. Since we have solved the issue in another way, we are closing this issue unless we get the same issue in future when we maybe will repopen it.
Hi there,
Thank you for your great repository! It helps our project a lot.
I found that the reg_comp function in libre is the same as that provided by glibc regcomp.c. In our C++ repository, it causes conflict in either the linker or dynamic library loader that causes segmentation fault. We found if we change the name in libre, the issue is solved. It would be great if you agree to change its name a bit.
If you feel good about this change, I can create a pull request reflecting the function name change, though I do want to hear your suggestion on the new function name.
Reference https://codebrowser.dev/glibc/glibc/posix/regcomp.c.html#re_comp https://stackoverflow.com/a/678312 alternatively https://stackoverflow.com/a/678309
Best Regards, Kun