[vtkusers] compilation with -fPIC necessary?

[Sebastiaan]

Hi!

On Fri, 17 Mar 2006, Obada Mahdi wrote:

> Hi Sebastiaan,
>
> I'm a bit confused now concerning where which flag is missing :)
>
> Does compiling shared VTK libraries on the EMT64 really lack a "-fPIC",
> or is it just the "libmpich.a" thing (which obviously was compiled
> without "-fPIC"), or both?
>
This discussion made me a little bit unsure about my previous results, so 
I did an exhaustive test:

mpich & vtk: no
mpich fpic & vtk: yes
mpich & vtk fpic: no
mpich fpic & vtk fpic: yes

So the problem seem to be with mpich.


> On Thu, 16 Mar 2006, Sebastiaan wrote:
>> Recompiling with -fPIC does not work: I get the same error. Recompiling 
>> mpich with -fPIC and then VTK with -fPIC seems to compiles clean (but I do 
>> not know if VTK is build correctly).
>
> Since the linker seems to complain about "libmpich.a" only, it seems
> that "-fPIC" was already present in the first place, and I suppose that
> "libmpich.a" is the only problem.
>
> On Fri, 17 Mar 2006, Sebastiaan wrote:
>> I have also read about -fPIC is almost always needed on 64 bit (don't know 
>> why it is not needed on 32 bit). I also read that -fPIC can break packages. 
>> Since most of VTK compiles clean without -fPIC, it seems overkill to 
>> compile all of VTK with this flag.
>
> VTK itself does not require PIC, building real shared libraries does.
> It is normal to use "-fPIC" when building shared libraries.
>
> Code compiled with "-fPIC" uses a different calling convention, which,
> for example, can break some inline assembly constructs.  Linking a
> PIC-compiled static library to a non-PIC application can also cause
> problems (your PIC-version of "libmpich.a" could break other programs
> that will be linked against it).  However, there is nothing to worry
> about when building shared libraries; after all, they are meant to be
> place-independent (that is what makes them shareable).
>
>> Why isn't this flag automatically added to the compiler for those shared
>> libraries, if it is compiled on a 32 bit system?

(of course I ment 64 bit here)

>
> I was not aware that this is possible, thanks for pointing that out.
> Actually, it should be added.  From what I have just read, it seems that
> Linux's IA32 dynamic linker supports not place-independent.  However,
> even in that case, such libraries can be dynamically loaded, but not be
> shared among different processes.
>
>
> I am very sorry if I am just causing more confusion -- hope you get it
> to work, though.
>
On the contrary, I now understand the need of -fPIC.

>
> Regards
>
> Obada
>
Thanks for the help. It seems that mpich is the problem, so I am going to 
bug them now :p

Sebastiaan

--

English written by Dutch people is easily recognized by the improper use of 'In principle ...'

The software box said 'Requires Windows 95 or better', so I installed Linux.

Als Pacman in de jaren '80 de kinderen zo had beïnvloed zouden nu veel jongeren rondrennen 
in donkere zalen terwijl ze pillen eten en luisteren naar monotone electronische muziek. 
(Kristian Wilson, Nintendo, 1989)