[vtk-developers] Changes to vtkPlane broke build

[Marcus D. Hanwell]

On Friday 08 January 2010 08:14:24 Moreland, Kenneth wrote:
> Not being as grumpy as John this morning, I can see how such a mistake
>  could easily be made.  I am more confused as to why it did not give errors
>  in MSVC.  I thought that  when a library or dll was created that the
>  linker required that all symbols were accounted for (unlike Unix-type
>  linkers).  At least that was how it worked in MSVC 6 and I think .net when
>  I was still using it.  Maybe that changed.

I have been looking at adding some extra compiler and linker warnings to GCC 
that may help in similar situations. I have not had time to fully test the 
changes but one affects the linker,

set(CMAKE_SHARED_LINKER_FLAGS
      "-Wl,--fatal-warnings -Wl,--no-undefined -lc 
${CMAKE_SHARED_LINKER_FLAGS}")

This makes the linker error out when it cannot resolve all symbols at link 
time, the problem is that, on Linux at least, we do not seem to be linking to 
everything explicitly. I think Python was the one that made vtkCommon explode, 
and I haven't had time to look into this further since.
> 
> At any rate, what surprises me a little is that the Filtering directory is
>  apparently listed in the include directories when compiling the Common
>  library.  Why is that?  If that directory was not listed in the includes
>  list, then the compiler would have complained immediately when vtkPlane
>  included vtkDataSet.h, and the error could have been caught immediately.

It does seem like this would be a good cross platform way in which to enforce 
these relationships. Adding further checks/strictness into linkers where it is 
supported could also help to improve overall quality.

Marcus
> 
> -Ken
> 
> 
> On 1/8/10 12:48 AM, "Biddiscombe, John A." <biddisco at cscs.ch> wrote:
> 
> The linker will not cause errors when one DLL references another when
>  symbols are missing. It only flags errors when code that requires the
>  symbols pulls in the dlls and fails to find the desired symbols.
> 
> There are few libs/executables which use common on it's own, as soon as the
>  linker pulls in filtering too, the error is masked - because the linker
>  finds the symbol it wants (in the other DLL).
> 
> All my local builds are broken, and yes there are fails on the dashboards
>  too. I see 6 machines submitting build fails yesterday
>  http://www.cdash.org/CDash/index.php?project=ParaView3&date=2010-01-07
> 
> Could those responsible please be a bit more careful - this is a commit
>  which should never have taken place - everybody knows that common can't
>  use filtering.
> 
> Grumpy
> 
> JB
> 
> > -----Original Message-----
> > From: vtk-developers-bounces at vtk.org
> > [mailto:vtk-developers-bounces at vtk.org] On Behalf Of David Gobbi
> > Sent: 07 January 2010 21:38
> > To: Berk Geveci
> > Cc: VTK Developers
> > Subject: Re: [vtk-developers] Changes to vtkPlane broke build
> >
> > The fact that the VTK dashboard builds don't show errors for this is
> > just too weird.  Shouldn't generating the VTK wrappers flush this out
> > in the same way that the ParaView build does?  Shouldn't even making
> > the instantiators be enough?
> >
> >    David
> >
> >
> > On Thu, Jan 7, 2010 at 12:43 PM, Berk Geveci <berk.geveci at kitware.com>
> >
> > wrote:
> > > I never understood linkers well so I can't explain why the dashboard
> > > didn't fail. You'd think that the Windows dll wouldn't link because it
> > > doesn't have access to vtkDataSet symbols. The ParaView dashboard
> > > demonstrates the problem nicely:
> > >
> > > http://www.cdash.org/CDash/viewBuildError.php?buildid=509383
> > >
> > > That's how I found out.
> > >
> > > -berk
> > >
> > > On Thu, Jan 7, 2010 at 12:33 PM, Bill Lorensen
> > > <bill.lorensen at gmail.com>
> >
> > wrote:
> > >> I don't see and broken builds on the VTK dashboard (Nightly Expected).
> > >> Shouldn't the nightlies (or better yet a continuous) VTK build detect
> > >> this sort of defect.
> > >>
> > >> Bill
> > >>
> > >> On Thu, Jan 7, 2010 at 10:53 AM, Berk Geveci <berk.geveci at kitware.com>
> >
> > wrote:
> > >>> I took at the code and the functionality is very cool. It just needs
> > >>> to find another home :-) Maybe a new utility class in Filtering or
> > >>> even a filter. (Thinking about it, maybe implicit functions should
> > >>> subclass from vtkDataObject?)
> > >>>
> > >>> Another comment, I noticed the CenterOfMass and create_matrix are
> > >>> polluting the global namespace. You should put them in an anonymous
> > >>> namespace instead. Also, create_matrix does not follow VTK's naming
> > >>> conventions, please fix that.
> > >>>
> > >>> I am going the revert this commit for now. Let me or Karthik know
> > >>> when you have a fix.
> > >>>
> > >>> Best,
> > >>> -berk
> > >>>
> > >>> On Thu, Jan 7, 2010 at 10:14 AM, David Doria
> > >>> <daviddoria+vtk at gmail.com>
> >
> > wrote:
> > >>>> On Thu, Jan 7, 2010 at 10:04 AM, Berk Geveci
> > >>>> <berk.geveci at kitware.com>
> >
> > wrote:
> > >>>>> Hi Karthik and David,
> > >>>>>
> > >>>>> Karthik's commit to vtkPlane broke some builds. I noticed that
> > >>>>> vtkPlane is now referring to vtkDataSet. It can't do that since
> > >>>>> vtkPlane is in Common and vtkDataSet is in Filtering. Please fix
> > >>>>> this somehow (without moving vtkPlane to Filtering).
> > >>>>>
> > >>>>> -berk
> > >>>>
> > >>>> Guys,
> > >>>>
> > >>>> I am travelling today. I can look at it first thing tomorrow if
> > >>>> Karthik doesn't get to it first. I wasn't aware that it is illegal
> > >>>> to use things from different libraries? Why is this the case?
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> David