Build fails in VTK : many undefined references

Hello,

Sorry to bother you again. Slicer (128fb86dd18) build fails in VTK on Arch Linux as such :

/usr/bin/ld: CMakeFiles/vtkProbeOpenGLVersion.dir/vtkProbeOpenGLVersion.cxx.o: in function main': vtkProbeOpenGLVersion.cxx:(.text.startup+0x25): undefined reference to vtkRenderer::New()’
/usr/bin/ld: vtkProbeOpenGLVersion.cxx:(.text.startup+0x2d): undefined reference to vtkRenderWindow::New()' /usr/bin/ld: vtkProbeOpenGLVersion.cxx:(.text.startup+0x68): undefined reference to vtkObjectBase::GetClassName() const’
/usr/bin/ld: vtkProbeOpenGLVersion.cxx:(.text.startup+0x172): undefined reference to vtkOutputWindow::GetInstance()' /usr/bin/ld: vtkProbeOpenGLVersion.cxx:(.text.startup+0x183): undefined reference to vtkOutputWindow::GetInstance()’
… many other undefined references

It’s configured as follows :

export LANG=C
export LC_ALL=C
export CFLAGS="-I/usr/include/tirpc"
export CXXFLAGS="-I/usr/include/tirpc"
cmake -DSlicer_VTK_VERSION_MAJOR:INT=8 -DQt5_DIR:PATH=/usr/lib/cmake/Qt5 -DBUILD_TESTING:BOOL=OFF -DCMAKE_BUILD_TYPE:STRING=Release -DADDITIONAL_CXX_FLAGS:STRING=-I/usr/include/tirpc …/Slicer

I suppose libvtkCommon is not found during linking.

Reporting it in hope of a fix.

Regards.

Built with clang 10.0 successfully at 76a41991e.

With commit 128fb86dd, there were linking errors as below :

/usr/bin/ld: …/…/…/bin/libRemoteIO.so: undefined reference to libssh2_init' /usr/bin/ld: ../../../bin/libRemoteIO.so: undefined reference to libssh2_knownhost_free’
/usr/bin/ld: …/…/…/bin/libRemoteIO.so: undefined reference to libssh2_knownhost_get' /usr/bin/ld: ../../../bin/libRemoteIO.so: undefined reference to libssh2_sftp_open_ex’
/usr/bin/ld: …/…/…/bin/libRemoteIO.so: undefined reference to libssh2_channel_wait_eof' /usr/bin/ld: ../../../bin/libRemoteIO.so: undefined reference to libssh2_session_method_pref’
/usr/bin/ld: …/…/…/bin/libRemoteIO.so: undefined reference to libssh2_channel_wait_closed' /usr/bin/ld: ../../../bin/libRemoteIO.so: undefined reference to libssh2_agent_init’
/usr/bin/ld: …/…/…/bin/libRemoteIO.so: undefined reference to libssh2_agent_list_identities' /usr/bin/ld: ../../../bin/libRemoteIO.so: undefined reference to libssh2_agent_connect’
/usr/bin/ld: …/…/…/bin/libRemoteIO.so: undefined reference to libssh2_channel_send_eof' /usr/bin/ld: ../../../bin/libRemoteIO.so: undefined reference to libssh2_userauth_keyboard_interactive_ex’
/usr/bin/ld: …/…/…/bin/libRemoteIO.so: undefined reference to libssh2_agent_disconnect' /usr/bin/ld: ../../../bin/libRemoteIO.so: undefined reference to libssh2_scp_recv2’
/usr/bin/ld: …/…/…/bin/libRemoteIO.so: undefined reference to `libssh2_hostkey_hash’

With gcc 10.1, on top of VTK linking errors, numpy didn’t build, i.e, no *.so file was found.

Will continue with clang then.

1 Like

It turns out that the root cause is with the pull request I submitted recently. The ‘tags’ entry should not have been modified. It is set back to the previous value of ‘vtk-old’ in this corrective pull request.

This allows VTK to compile in a clean build, both with gcc 10.1 and clang 10.0. Moreover, no numpy errors are encountered.

However, this patch was necessary, to allow RemoteIO to link to ssh2.

diff --git a/Libs/RemoteIO/CMakeLists.txt b/Libs/RemoteIO/CMakeLists.txt
index 65bd1b6183..23ca01b092 100644
--- a/Libs/RemoteIO/CMakeLists.txt
+++ b/Libs/RemoteIO/CMakeLists.txt
@@ -95,6 +95,7 @@ add_library(${lib_name} ${srcs})
 set(libs
   ${CURL_LIBRARIES}
   MRMLCore
+  ssh2
   )
 if(Slicer_USE_PYTHONQT_WITH_OPENSSL)
   list(APPEND libs

I hope the corrective request is merged in the Slicer/VTK tree.

Thank you very much for working on this. We can merge the Slicer/VTK pull request if you touch it up a bit based on comments. After that, please submit a pull request to Slicer/Slicer that uses the new Slicer/VTK hash and includes all other proposed changes (RemoteIO and anything else that you find necessary).

I amended the last comment on the fork to be more explicit, and did a forced push. But I am not being able to create a new pull request; no command is available for this, and I am logged in.

My first ever pull request has not been a success, so I’m somehow hesitant now.

No need to create a new pull request, it is enough to change the content of the branch that the pull request was created for.

Maybe you forgot to rebase your branch on the latest version of the target branch.

Update to update.sh associated with commit Slicer/VTK@b4a1815 (added to branch slicer-v8.2.0-2018-10-02-74d9488523) is unlikely to be the source of the problem.

Indeed, we are not running this script while building VTK or Slicer.

I suggest we spend a little bit more time understanding the root cause of the problem. Since we do not call function like libssh2_agent_disconnect in Slicer code, adding a dependency to ssh2 does not seem to be the “right” fix.

Well these are observational findings, perhaps related to Arch’s specifics, being so called ‘bleeding edge’ by nature.

I report these findings in case it’s known to you and a fix can be pointed to, or in case these findings might be useful in the future. I am well aware your build infrastructure is quite different and well described in your factory pages. I am not an IT pro, and won’t ever have such knowledge to venture in advanced tasks like a new pull request.

So in all, I’ll maintain locally a few tweaks that allow me to build Slicer.

As for the ssh2 issue, the new curl pulled in has much to do with ssh2 :

LANG=C LC_ALL=C readelf -hs src/Slicer-SuperBuild/curl-build/lib/libcurl.a |grep ssh 
    30: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND Curl_ssh_init
    35: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND Curl_ssh_cleanup
     9: 0000000000000000    80 OBJECT  LOCAL  DEFAULT    4 ssh_buffer.0
    24: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND Curl_ssh_version
File: src/Slicer-SuperBuild/curl-build/lib/libcurl.a(libssh.c.o)
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS libssh.c
File: src/Slicer-SuperBuild/curl-build/lib/libcurl.a(libssh2.c.o)
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS libssh2.c
     5: 0000000000000000     9 FUNC    LOCAL  DEFAULT    1 my_libssh2_malloc
     6: 0000000000000010     9 FUNC    LOCAL  DEFAULT    1 my_libssh2_realloc
     7: 0000000000000020    17 FUNC    LOCAL  DEFAULT    1 my_libssh2_free

… …

May be I don’t interpret it rightly. I may of course give you more information you may need.

Is there an update on this? I have the same problem building on MacOS 10.15.5 (undefined libssh references).

Does anyone have a workaround to get MacOS builds going? I’ve installed libssh2, but I seem to be unable to tell CMake where to find it. I’ve added the ssh2 library line for RemoteIO (I realize this may be sub-optimal), but make is unable to find libssh2 in /usr/local - I checked link.txt and it does not have -L/usr/local/lib (where libssh2 is located). I’ve tried to add -L/usr/local/lib to what look like CMake LD flag settings, but make still doesn’t look in /usr/local/lib.

How do I add /usr/local/lib to the linker flags for RemoteIO?

Thanks!!

OK, I think I figured this out. ssh2 is required for RemoteIO, but just adding ssh2 to CMakeLists.txt wasn’t sufficient for my setup - it didn’t know where to find libssh2.dylib. To tell it to get ssh2 from /usr/local (version 1.9.0_1 installed via HomeBrew), I had to add a call to find_library() and tell it to look in /usr/local/lib.

diff --git a/Libs/RemoteIO/CMakeLists.txt b/Libs/RemoteIO/CMakeLists.txt
index 65bd1b618..a11163e9c 100644
--- a/Libs/RemoteIO/CMakeLists.txt
+++ b/Libs/RemoteIO/CMakeLists.txt
@@ -92,9 +92,12 @@ set(srcs ${RemoteIO_SRCS})

 add_library(${lib_name} ${srcs})

+find_library(SSH2_LIBRARY NAMES ssh2 PATHS /usr/local/lib)
+
 set(libs
   ${CURL_LIBRARIES}
   MRMLCore
+  ${SSH2_LIBRARY}
   )
 if(Slicer_USE_PYTHONQT_WITH_OPENSSL)
   list(APPEND libs

Now, I have no idea if this is the right solution, as @jcfr mentioned above. But at least it got the build going.

Any comments?

Thanks!

-Hollister