[vtk-developers] Patches: Large volumes, Image actor extent, Build tweak

[Frank Richter]

Hi,
On 03.06.2011 16:36, Marcus D. Hanwell wrote:
> Did you test the results of applying this patch? 

Yes. (Though only on Linux x86_64...)

> I was working on
> this, and to support the static case requires more logic. On Windows,
> we must prevent the declspec being used for static builds, but on GCC
> 4+ we must use the visibility attribute. Currently vtkWin32Header.h
> (misleading name - relevant for all platforms) only uses the VTK_ABI_*
> macros for shared builds, and so nothing would ever be marked as
> visible with a static build.

Well, hidden VTK symbols, when linked into a shared library, was exactly
what I wanted... so static lib symbols marked as visible was exactly
what I wanted to prevent!

> If you are linking a static library into a shared
> library, on an x86_64 platform at least, you will also need to build
> with -fPIC otherwise it will fail to link.

Yeah. This patch on it's own won't make static VTK in shared libs out of
the box. But, arguably, enabling -fPIC is a different matter.

> It would be great to know what use cases you are thinking of when
> applying this. I haven't had time to revisit this issue recently, but
> there are several conditions we need to account for before something
> like this could be applied.

Basically: the application has several “UI modules”; those are generally
in a shared lib. Also, there is some “core logic” - again, in a shared
lib, because it's used by the GUI application as well as a Python module.

One of those UI modules uses VTK. I wanted to hide the VTK symbols, as
VTK is used in that single module only, due to the supposed performance
benefit of keeping a small set of dynamic symbols, and because I
personally don't like excessive visible modules. I wanted to statically
link VTK so only the actually used subset ends up in the binary and to
avoid the “clutter” of the many shared libs required otherwise.

In short, the scenario is “encapsulation”.

-f.r.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20110606/ee5a23ce/attachment.sig>