[vtkusers] Building vtk on HP-PARISC HPUX-11.11 64bit fails

[Brad King]

Burkhard Neinhues wrote:
> However, this situation changes for libvtkRenderingPythonTkWidgets.sl. 
> Now, the dependent shared libraries are:
> 
>         shared library list:
>             libvtkRendering.sl
>             libtk8.4.sl
>             libtcl8.4.sl
>             libm.2
>             libvtkGraphics.sl
>             libvtkImaging.sl
>             libvtkIO.sl
>             libvtkFiltering.sl
>             libvtkCommon.sl
>             libvtksys.sl
>             libdl.1
>             libvtkDICOMParser.sl
>             libvtkpng.sl
>             libvtktiff.sl
>             libvtkjpeg.sl
>             libvtkexpat.sl
>             libvtkMPEG2Encode.sl
>             libvtkftgl.sl
>             libfreetype.sl.9
>             libvtkzlib.sl
>             libGL.2
>             libXt.3
>             libSM.2
>             libICE.2
>             libX11.3
>             libXext.3
>             libpthread.1
> 
> If you now pick first linked in shared library, libvtkRendering.sl , the 
> dependent shared libraries are:
> 
>            shared library list:
>             libvtkGraphics.sl
>             libvtkImaging.sl
>             libvtkIO.sl
>             libvtkftgl.sl
>             libfreetype.sl.9
>             libvtkzlib.sl
>             libGL.2
>             libXt.3
>             libSM.2
>             libICE.2
>             libX11.3
>             libXext.3
>             libvtkFiltering.sl
>             libvtkCommon.sl
>             libvtksys.sl
>             libdl.1
>             libm.2
>             libvtkDICOMParser.sl
>             libvtkpng.sl
>             libvtktiff.sl
>             libvtkjpeg.sl
>             libvtkexpat.sl
>             libvtkMPEG2Encode.sl
>             libpthread.1
> 
> The problem is now: When for example libvtkRenderingPythonTkWidgets.sl 
> is created, it'll be linked against libvtkRendering.sl, 
> libvtkGraphics.sl etc.
> which in turn reference other shared libraries already references 
> before. It depends now on the "intelligence" of the linker how these 
> dependencies
> are resolved correctly.
> Add to this that on some platforms the order shared libraries are linked 
> in is also important.
> The Parisc linker can not handle this, when creating one of the widget 
> libraries for python, it'll fail reporting (not verbatim):
> Can not find dependent library  xyz.sl.
> This is not the original problem, when I change the order the shared 
> libraries are linked in, the linker complains about another shared library
> "missing". Of course, the shared libraries are in place, valid and the 
> proper -L option is passed to the linker.
> 
> So my question is: It there a solution possible in theory, is this a 
> CMake problem or can the linking behaviour changed from the VTK build 
> process?
> There's certainly also a problem with the HP linker which contributes to 
> this, as I successfully removed some of the shared libraries
> to make it work on Parisc.

This linking behavior is a CMake feature and cannot be changed from the 
VTK build process.  I would say this is a bug in the Parisc linker. 
Every other linker I've seen can deal with this issue, and here is an 
argument independent of CMake or VTK for why the linker needs to do so.

Consider an example project which may be built either static or shared. 
  All the libraries it needs provide both static and shared versions. 
When linking shared the linker chooses the shared versions and vice 
versa.  Say there are two libraries B and A, and B needs symbols from A 
to function properly.  In order to link statically I must write "-lB 
-lA".  If I switch to a shared build this same link line should continue 
to work even though there is an automatic B->A link behind the scenes.

What is the exact error you get (cut-and-paste please)?

-Brad