Undefined symbol when run my CLI modules extensions

Development
1

Operating system: Ubuntu 16
Slicer version: 4.8.1
Expected behavior: cli working
Actual behavior: not working

my cli extension are not working “anymore”. I get these errors:

undefined symbol: _ZN3itk13ProcessObject8SetInputERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPNS_10DataObjectE

I tried install using the zipped file generated by make package. I also tried copy the libs to slicer related folder but I get the same error.

Just checked now, they only work using Slicer-build/Slicer but not the installed binary Slicer. What should I do to make them works in the binary as they used to do.

2

Your build seems to be ABI incompatible with the official Slicer build binaries.

If you are lucky then you may be able to create an ABI-compatible library on a different computer, if you use exactly the same build environment and libraries, but practically you can only ensure compatibility if you build Slicer core and all extensions on the same computer. It can be your computer - for private distributions; or the Slicer build machines - for public distribution.

3

For reference, here is the unmangled name of the missing symbol:

$ echo "_ZN3itk13ProcessObject8SetInputERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPNS_10DataObjectE" | c++filt 
itk::ProcessObject::SetInput(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, itk::DataObject*)
4

Also, as illustrated in commit InsightSoftwareConsortium/ITK@01580b3, the method itk::ProcessObject::SetInput was part of the deprecated API.

Worth noting that while Slicer is built against an ITK having ITKV3_COMPATIBILITY option OFF, the option ITK_LEGACY_REMOVE is still OFF. See here

Anticipating the transition to ITK 5.0, we will look into turning that option ON . This is captured in the following issue: https://issues.slicer.org/view.php?id=4522

5

I don’t understand, what changed? the extension works before, why I have this incompatibility now with the new build that supposed to be the same as the binary 4.8.1? I thought Cmake take care of these things. I also tested with skipping RPATH but I get the same error.

Thank Jean for the info.

I modify SuperBuild/External_ITKv4.cmake to enable make ITKV3_Compatibility. I also enabled the related module in ITKv4-build then rebuilt Slicer. After that, I rebuilt the extension but I got this error

undefined symbol: _ZN6vtksys11SystemTools24GetFilenameLastExtensionERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

I checked it using:
echo “_ZN6vtksys11SystemTools24GetFilenameLastExtensionERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE” | c++filt
vtksys::SystemTools::GetFilenameLastExtension(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)

It looks there are some option I need to change in VTK?

6

You should not have to modify the ITKV3_Compatibility option of Slicer. Instead, it should be possible to update your extension code to note use any legacy code. This is definitively the way forward.

How are you building your Slicer extension ?

Could you confirm you do something like this:

mkdir my-extension-build
cd my-extension-build
cmake -DSlicer_DIR:PATH=/path/to/Slicer-Superbuild/Slicer-build  ../my-extension-src
make

In the my-extension-build/CMakeCache.txt of your extension, what is the value for ITK_DIR ? It should be /path/to/Slicer-Superbuild/ITKv4-build

7

You are right. I will try to update the code and rebuild again. It is just not clear why it works before and not working now.

I build the extension the same way you mentioned. I checked CMakeCashe.txt , ITK_DIR uses my Slicer-build/ITKv4-build

Update:

I package my Slicer build using

Slicer-build/make package

I installed extensions from Slicer but it does not work. Looks like the build is incompatible as @lassoan mentioned. I rebuild again but the problem is still there.

What could possible gone wrong? I am using the source code for the same binary revision 4.8.1 using the same tools versions as mentioned in the instruction web-page e.g. Qt4.8.7.

8

Instead of packaging and installing your extension, I suggest you backtrack and try the following:

  • start Slicer from your build tree
  • go to Edit -> Settings -> Modules, then add the paths to your module
  • restart Slicer

Is the module properly loaded ?

9

There is no problem with the locally built extensions and the locally Slicer. The problem is with the extensions built locally with the binary Slicer downloaded from Slicer website.

Today, I built Slicer in 2 different machines (Ubuntu 16). I got the same error. So probably there is something wrong with the source or there is something installed affect the build.

I will make a clean install of Ubuntu 16 and try again. Is there a away to test the ABI incompatibility without building and testing the extensions?

10

no problem with the locally built extensions and the locally Slicer

Great

summary

problem is with the extensions built locally with the binary Slicer downloaded from Slicer website

Could you indicate which binary you downloaded (version of Slicer)

I built Slicer in 2 different machines (Ubuntu 16). I got the same error. So probably there is something wrong with the source or there is something installed affect the build.

To clarify, you build locally Slicer on two different machine:

  • local machine 1 (Ubuntu 16)
  • local machine 2 (Ubuntu 16)

Then, you locally built your extension on machine 1 and created a package from it (using make package)

Finally, you copied the packaged created on machine 1 onto machine 2.

Installed the extension using the install extension from file

And you see the error at startup on machine 2 ?

questions

It may be useful to try running the application setting the LD_DEBUG env variable. See https://linux.die.net/man/8/ld.so and The LD_DEBUG environment variable | B. Nikolic Software and Computing Blog

Do you have itk locally installed on any of the machine ?

What is the value of LD_LIBRARY_PATH ? Do you have any custom ld.conf settings ? (see file /etc/ld.so.conf or directory /etc/ld.so.conf.d/)

abi checker

Is there a away to test the ABI incompatibility

This project could be useful, but I don’t think it will help yet: Testing/ABI_checker - glibc wiki

moving forward

To help with reproducing build, we are currently transitioning our linux build to use:

This will allow anyone to re-produce the build locally.

1 Like
11

@jcfr many thanks for your concern.

Could you indicate which binary you downloaded (version of Slicer)

The stable version. Slicer 4.8.1 r26813. I thought by building the source of the same revision in release mode, I will get a compatible build.

To clarify …

Everything is as you mentioned expect I am trying to run the locally build extension using the downloaded binary above.

In each machine I did:

  • build Slicer r26813 in release mode.
  • build the extension in release mode using the same build and packaged it.
  • downloaded Slicer 4.8.1 and install the plugin using “install from a file” method.
  • When I run the extension the error “undefined symbol” appeared.

Do you have itk locally installed on any of the machine ?

All the machines has ITK locally build and installed (in addition to the one in Slicer superbuild).

It may be useful to try running the application setting the LD_DEBUG env variable.

Running LD_DEBUG=symbol ~/mySlicerBinaryPath/Slicer – launch ./my_cli some_argument 2> LD_DEBUG_Output.txt produced thousands of lines, large part of the output is missing in the txt file.

What is the value of LD_LIBRARY_PATH ?

$ echo $LD_LIBRARY_PATH
:/usr/local/cuda-9.0/lib64:/usr/local/lib:~/sw/qt5.7.0/5.7/gcc_64/lib

Do you have any custom ld.conf settings ?

I think I don’t have any custom ld.conf setting.

abi checker
moving forward, dockbuild - Compiling environments in Docker images.

This would be very nice to have.

12

Update:

The problem is still there even after clean install of Ubuntu 16. I installed a new Ubuntu 16 in a virtualbox and run this script to build Slicer:

# Preare build tree 
mkdir ~/sw
mkdir ~/sw/Slicer4.8.1-dev
mkdir ~/sw/Slicer4.8.1-dev/build

# Install necessary tools 
sudo apt -y update && sudo apt upgrade  && sudo apt-get install subversion git-core git-svn make gcc g++ libx11-dev libxt-dev libgl1-mesa-dev libglu1-mesa-dev libfontconfig-dev libxrender-dev libncurses5-dev curl libssl-dev  

#install qt4
sudo apt -y install qt4-dev-tools libqt4-dev libqtcore4 libqtgui4 libqtwebkit-dev

# Download and install CMake3.11
wget -N  https://cmake.org/files/v3.11/cmake-3.11.0-rc4.tar.gz  -P ~/sw  && tar -xzvf ~/sw/cmake-3.11.0-rc4.tar.gz  -C ~/sw

cd ~/sw/cmake-3.11.0-rc4
./bootstrap  &&  make &&  sudo make install 

#Download build Slicer
cd ~/sw/
svn co http://svn.slicer.org/Slicer4/branches/Slicer-4-8  ~/sw/Slicer4.8.1-dev/src -r 26813 && 
cd ~/sw/Slicer4.8.1-dev/build
cmake -DCMAKE_BUILD_TYPE=Release  ~/sw/Slicer4.8.1-dev/src && make

I tried in two different Ubuntu 16 machines, their build are compatible with each other but not with the one from Slicer download:

  • Machine 1 has M1Slicer-build (the build folder for Slicer) and M1Slicer-bin (the Slicer binary package generated from the build)
  • Machine 2 has M2Slicer-build and M2Slicer-bin
  • I copied M1Slicer-bin to Machine 2 and copied MSlicer-bin to Machine 1
  • In Machine 1: I can build an extension using M1Slicer-build and install it and run it in the copied M1Slicer-bin
  • Same goes for Machine 2.

Is there something I did wrong? does using cmake 3.11 make difference? or maybe Ubuntu 16 is not compatible with the Slicer Linux binary I downloaded?

13

Update
Tried a Slicer build using qt4t easy. I tested after the build, still not compatible.

If anyone was able to build a compatible Slicer version in Ubuntu 16.04, I would like to know how he did it.

I think the source is not the same. I noticed there is a small change in the “about window” (one has the date in the second line while the other has not). As I have number of ITK extensions don’t work, probably the ITK version or the ITK configuration is different?
SlicerBuildSlicerOfficial

@jcfr @lassoan : could you please comment or suggest?

14

one has the date in the second line while the other has not

This is normal, to build a release that do not include the date, you would have to set the option -DSlicer_RELEASE_TYPE:STRING=Stable. See ReleaseProcess checklist.

But the impact is only cosmetic.

If anyone was able to build a compatible Slicer

You can not build extension using Ubuntu 16.04 and expect them to be compatible with the Slicer 4.8.1 release.

Indeed, the Slicer 4.8.1 release was done using Ubuntu 10.04.

Considering it is not possible to install such an old distribution, there is we now docker images allowing to reproduce builds.

Following this guide will allow you to build your extension and have it working with the Slicer 4.8.1 Linux release.

See Introducing SlicerBuildEnvironment project

15

Now I understand, thanks for the comment.

Why not using the last stable Ubuntu i.e. 16.04 instead of Ubuntu 10.04? with the script above, I was able to build Slicer without any problem in different machines including virtualbox machine. I will try the docker approach as well.

16

To ensure the generated binaries can run a broad set of linux distribution, it is important to use an older distribution requiring an older version of GLIBC and GLIBCXX .

For the upcoming release depending on qt5, we will use centos7

Great. Wait until tomorrow, updated images are being generated and should be available on dockerhub shortly. The current ubuntu1004-gcc4 has gcc version 4.4.3 but Slicer binaries were generated with gcc 4.6. See here

1 Like
17

Updated docker images are now available.

1 Like
18

I just tried it, it was some how complicated because I am trying to get the concept of the docker and there was was some problems regarding permissions and c++ code in my extensions but finally it works now :slight_smile: . Thanks for your effort.

I hope, I am not asking too much :grin: maybe in the future, it is much simpler if you provide an actual build of some popular Linux systems using the recent stable version as everything can be done automatically via scripting. Some download statistics can help in deciding this based on which operating systems the downloaders use.