[vtkusers] Building vtk on HP-PARISC HPUX-11.11 64bit fails
Burkhard Neinhues
Burkhard.Neinhues at airbus.com
Fri Mar 10 04:15:56 EST 2006
Hi Mathieu,
>> vtkRendering_LIB_DEPENDS:STATIC=.....-lGL;-lXt;-lSM;-lICE;-lSM;-lICE;-lSM;-lICE;-lX11;-lXext;-lX11;-lXext;-lX11;-lXext;
>>
>>
>> This doesn't look nice and despite the STATIC token, the link is
>> actually performed using shared libraries of course!
>
>
> STATIC is simply a keyword recognized by CMake (the cache manager) and
> has nothing to do with shared or static linking.
>
Ok! Then the question remains why X11 get's multiply linked in ?
>
> They are not 'automagically' created. vtkCommon does not link to any
> other VTK library. vtkIO only link to the proper libs, and so and so
> forth. Could you be more specific in sending the exact linker error,
> on let say the linking of vtkCommon ?
>
vtkCommon is not causing the problems. It is one of the first libraries
created during the build, hence there's not that much that is required
to be linked in.
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.
>> Is there no way for less automised builds using standard tools ?
>> libtool/automake/autoconf ?
>
Ok, I admit that this is probably the wrong place to launch a discussion
about autoconf/CMake.
> CMake has proved to work on many *NIX platform. This is the first time
> I am seeing such problems.
> Again with the exact error we should be able to help you, as we
> currently have nightly testing of CMake and VTK on HPUX systems.
Is this a 64 bit build? The HP linker behaves differently for 32/64 bit
links. I used aCC +DD64 -AA -mt to build it, compiler versions 3.55 and 3.60
produce the same problem, HPUX Parisc version is 11.11, linker version
is 11.18. Itanium builds are fine though.
Greetings,
Burkhard
This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message.
More information about the vtkusers
mailing list