onnxruntime: Error when linking libonnxruntime_mlas.a(SconvKernelSse2.S.o) with customized cmake build file

Describe the bug

I built onnxruntime as described by running the build.sh script. When linking against libonnxruntime_mlas.a into my shared lib I get the following error message:

libonnxruntime_mlas.a(SconvKernelSse2.S.o): relocation R_X86_64_PC32 against symbol MlasConvPostProcessFloatSseFilter4Output1' can not be used when making a shared object; recompile with -fPIC

CMake does not look special, here an excerpt:

TARGET_LINK_LIBRARIES(testLib
      -Xlinker --gc-sections
      #-Wl,--start-group
      ${BEGIN_WHOLE_ARCHIVE}
      ${CUDA_LIBS}
      #${PROVIDERS_CUDA}
      ${ORT_LIBS_WHOLE_ARCHIVE}
      ${END_WHOLE_ARCHIVE}
      RDTools
      ${Boost_LIBRARIES}
      ${ORT_LIBS_DIR}/external/protobuf/cmake/libprotobuf.a
      #-Wl,--end-group
      ${ORT_LIBS_NO_WHOLE_ARCHIVE}
      dl
      rt
      pthread
)

System information

  • OS Platform and Distribution:Linux Ubuntu 18.04)
  • ONNX Runtime installed from (source or binary): Source, Branch:master
  • ONNX Runtime version: 0.4.0
  • Python version:
  • Visual Studio version (if applicable):
  • GCC/Compiler version (if compiling from source): 7.4.0
  • CUDA/cuDNN version:
  • GPU model and memory:

To Reproduce Build from source and try to link all onnx libs into a dynamic lib. Currently I cannot provide my complete sources, as it is a commercial project.

Expected behavior Should link without problems, as ibonnxruntime_mlas.a has been compiled with fpic.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 20 (10 by maintainers)

Most upvoted comments

Thanks for the pointer. These new assembly symbols needed to be marked as “.hidden” to avoid exporting the symbols through the Procedure Linkage Table (PLT). I was able to repro your link failure with libonnxruntime.so after removing the version_script that onnxruntime.cmake builds. With the changes, then the error went away.

The changes are currently in tracysh/qgemm which will be submitted to master very soon. I’ll resolve this issue when that is done.

@hariharans29 Are you asking about the shared library? Unfortunately I wasn’t able to compile it with gcc-7.3.

Had same problem, except we needed a dynamic library. For some reason it compiled with gcc-9.1, but I wasn’t able to get it compiled with gcc-7.3.

But as @commanderka, mentioned libonnxruntime.so compiled without problems (well, I had some issues with gcc-7.3, specifically undefined reference to `vtable for std::_Sp_counted_deleter<void*, void (*)(void*), std::allocator<void>, (__gnu_cxx::_Lock_policy)2>', but I didn’t really needed a dynamic version of onnxruntime and it compiled under gcc-8.3). Then I tried to get the same error based on the linker options and removing --version-script did the job.

So basically minimum of what you want to do is to to pass -Wl,--version-script=version_file where version_file has roughly following content:

MYLIB_0.1 {
  global:
    *;
  local:
    MlasConvPostProcess*;
};

What is important here is that MlasConvPostProcess* is in local section which hides all symbols staring with MlasConvPostProcess and they’re no longer part of that shared library interface. For more info take a look at Control over symbol exports in GCC

Note: This fix works only for dynamic library. Also we encountered this error only after upgrade to recently released onnxruntime-0.5.0 and never had any problem with static linking.