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

[Mathieu Malaterre]

>> We are talking static libs here right ?
>> Instead of manually modifying Makefile, could you instead modify the 
>> file:
> 
> 
> 
> Just for clarification: No, we're talking about shared libraries! Static 
> libraries in conjunction with threads don't work on HPs.
> With your hint I can alter the order -lXext -lX11
> are linked in, but it'll not fix the issue of multiple -lX11 statements 
> during linking (see CMakeCache.txt):
> 
> 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.


> The problem is far more general: Each time a shared library is created 
> in vtk it is usually linked to many other (vtk) shared libraries.
> In vtk, the vtk shared libraries are often linked against *all*  other 
> shared libraries created before during the build.
> However, since these "other" shared libraries were created the same way, 
> there'll finally be a lot of multiply referenced
> shared libraries. The dependent libraries (on Linux use ldd to see them, 
> on HP it's chatr) cause the problems with the HP linker:
> There're simply to many nested dependencies created this way.
> There's no easy way to patch this behaviour, since these dependencies 
> seem to be automagically created in CMakeCache.txt

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 ?

> Is there no way for less automised builds using standard tools ? 
> libtool/automake/autoconf ?

"standard" and "autoconf" in the same sentence... how often did you used 
those "standard" tools ;-P

> See explanations above. If this is really a CMake problem, I'll probably 
> search for own alternatives since I don't believe in an
> easy fix then.

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.

>>> Cmake is also difficult to compile on HPs (missing symbols for 
>>> curses) and must be manually tuned to allow
>>> 64 bit builds on HPs.
>>
>>
>>
>> Could you send more details (exact output) to the CMake ML ?
> 
> 
> Ok!

Great

Thanks
Mathieu