[vtk-developers] Site v20n17.pbm.ihost.com needs attention

David Gobbi david.gobbi at gmail.com
Thu Jan 14 13:29:35 EST 2010 

I see your point, that makes sense.  For a moment there the discussion
made alarm bells go off in my head.

  David


On Thu, Jan 14, 2010 at 11:23 AM, Dave Partyka <dave.partyka at kitware.com> wrote:
> I would agree 99% of the time but if it is indeed the case that nothing can
> be done about it in the near future or without considerable effort/funding
> then it's as Bill says, more of a distraction.
>
> On Thu, Jan 14, 2010 at 1:10 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> If the errors are indeed genuine (even if they are brought about by
>> peculiarities in the system architecture), then they should stay on
>> the dashboard, shouldn't they?
>>
>> Just my 2 cents, though I'm not sure if I've understood the issue
>> completely.
>>
>>  - David
>>
>>
>> On Thu, Jan 14, 2010 at 10:57 AM, Dave Partyka <dave.partyka at kitware.com>
>> wrote:
>> > I am actually more inclined to just disable metaIO on that machine as it
>> > doesn't appear to have issues anywhere else. If no one objects I will
>> > set
>> > VTK_USE_METAIO off as it defaults to ON for that machine.
>> >
>> > On Thu, Jan 14, 2010 at 12:54 PM, Bill Lorensen
>> > <bill.lorensen at gmail.com>
>> > wrote:
>> >>
>> >> Not specualting, just doing the best I can with my limited knowledge.
>> >>
>> >> On Thu, Jan 14, 2010 at 12:42 PM, Francois Bertel
>> >> <francois.bertel at kitware.com> wrote:
>> >> > Stop speculating, the issue is in metaio. Here is the reason of the
>> >> > failure and there is unfortunately no trivial solution right now
>> >> > (even
>> >> > for Brad King!):
>> >> >
>> >> > From an private thread of discussion involving me, Luis, Julien
>> >> > Jomier
>> >> > and Brad King, Dec 4 2009:
>> >> >
>> >> > Brad King said:
>> >> >
>> >> > "
>> >> > $ nm libvtkmetaio.so | grep ElementByteOrderFix
>> >> > .vtkmetaio::MetaArray::ElementByteOrderFix() T   271508768
>> >> > 172
>> >> > .vtkmetaio::MetaImage::ElementByteOrderFix(long) T   269262912
>> >> > 180
>> >> > ...
>> >> >
>> >> > $ nm libvtkIO.so| grep ElementByteOrderFix
>> >> > ...
>> >> > vtkmetaio::MetaImage::ElementByteOrderFix(long long) U           -
>> >> >
>> >> > Something is causing streamoff to be a different size in one of
>> >> > vtkIO's
>> >> > translation units than in metaio's translation units.  It's probably
>> >> > the
>> >> > KWSys Configure.h that defines _LARGEFILE_SOURCE and related macros
>> >> > (this
>> >> > was something Andy Cedilnik added at some point to "guarantee" LFS
>> >> > support
>> >> > in all Kitware projects)."
>> >> >
>> >> > Brad King said:
>> >> >
>> >> > "
>> >> > [I recommends to] teach MetaIO about large file support.
>> >> >
>> >> > Doing it right is a bit tricky.  This is one of those cases that
>> >> > requires
>> >> > users of a library to define macros before including its headers.  We
>> >> > have
>> >> > generally avoided this requirement by configuring feature settings
>> >> > into
>> >> > header files such as vtkConfigure.h.  However, the problem here is
>> >> > that
>> >> > enabling large file support means defining a macro like
>> >> > _LARGEFILE_SOURCE
>> >> > in *every* translation unit before any *system* header is included.
>> >> >  This
>> >> > cannot be done reliably in a place like vtkConfigure.h because users
>> >> > could
>> >> > write this:
>> >> >
>> >> > #include <stdio.h>
>> >> > #include <vtkObject.h> /* Uh oh, _LARGEFILE_SOURCE is defined too
>> >> > late!
>> >> > */
>> >> >
>> >> > By the time our configured header gets included, the system API has
>> >> > already
>> >> > been loaded without large file support!  If instead we require users
>> >> > to
>> >> > add -D_LARGEFILE_SOURCE on the command line then it will apply to the
>> >> > system API no matter when it is included.
>> >> >
>> >> > A better approach is this:
>> >> >
>> >> >  # CMakeLists.txt
>> >> >  # ... try compiles to detect proper LFS_MACRO ...
>> >> >  add_definitions(-D${LFS_MACRO})
>> >> >
>> >> >  /* myconfig.h.in */
>> >> >  #ifndef @LFS_MACRO@
>> >> >  # error "This source requires -D at LFS_MACRO@"
>> >> >  #endif
>> >> >
>> >> > The LFS_MACRO value can be put in the FooConfig.cmake file for use by
>> >> > outside projects.
>> >> >
>> >> > Unfortunately we did not understand this problem back when the macros
>> >> > were
>> >> > put in KWSys, and changing it there now is very hard for
>> >> > compatibility
>> >> > :(
>> >> > "
>> >> >
>> >> >
>> >> > On Thu, Jan 14, 2010 at 12:30 PM, Dave Partyka
>> >> > <dave.partyka at kitware.com> wrote:
>> >> >> Humm I didn't noticed that it was using nightly CMake. I
>> >> >> most certainly will
>> >> >> give it a shot. Thanks for pointing that out!
>> >> >>
>> >> >> On Thu, Jan 14, 2010 at 12:27 PM, Bill Lorensen
>> >> >> <bill.lorensen at gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> Dave,
>> >> >>>
>> >> >>> I noticed that this build is using cmake2.9. Have you tried it with
>> >> >>> cmake2.8?
>> >> >>>
>> >> >>> Bill
>> >> >>>
>> >> >>> On Thu, Jan 14, 2010 at 11:54 AM, Dave Partyka
>> >> >>> <dave.partyka at kitware.com>
>> >> >>> wrote:
>> >> >>> > I just fixed all the compile errors late last week and now it
>> >> >>> > just
>> >> >>> > has
>> >> >>> > test
>> >> >>> > failures. I'll keep prodding at it.
>> >> >>> >
>> >> >>> > On Thu, Jan 14, 2010 at 11:52 AM, Bill Lorensen
>> >> >>> > <bill.lorensen at gmail.com>
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Folks,
>> >> >>> >>
>> >> >>> >> Late October was the last time the site v20n17.pbm.ihost.com had
>> >> >>> >> a
>> >> >>> >> green dashboard.
>> >> >>> >>
>> >> >>> >> Could the owner of this build please take a look and see if the
>> >> >>> >> problems can be resolved? Currently it is reporting 610 failing
>> >> >>> >> tests:
>> >> >>> >>
>> >> >>> >> http://www.cdash.org/CDash/viewTest.php?onlyfailed&buildid=514704
>> >> >>> >>
>> >> >>> >> Or, perhaps we no longer support this compiler: AIX00C518-xlC ?
>> >> >>> >>
>> >> >>> >> Bill
>> >> >>> >> _______________________________________________
>> >> >>> >> Powered by www.kitware.com
>> >> >>> >>
>> >> >>> >> Visit other Kitware open-source projects at
>> >> >>> >> http://www.kitware.com/opensource/opensource.html
>> >> >>> >>
>> >> >>> >> Follow this link to subscribe/unsubscribe:
>> >> >>> >> http://www.vtk.org/mailman/listinfo/vtk-developers
>> >> >>> >>
>> >> >>> >
>> >> >>> >
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> Powered by www.kitware.com
>> >> >>
>> >> >> Visit other Kitware open-source projects at
>> >> >> http://www.kitware.com/opensource/opensource.html
>> >> >>
>> >> >> Follow this link to subscribe/unsubscribe:
>> >> >> http://www.vtk.org/mailman/listinfo/vtk-developers
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > François Bertel, PhD  | Kitware Inc. Suite 204
>> >> > 1 (518) 371 3971 x113 | 28 Corporate Drive
>> >> >                      | Clifton Park NY 12065, USA
>> >> > _______________________________________________
>> >> > Powered by www.kitware.com
>> >> >
>> >> > Visit other Kitware open-source projects at
>> >> > http://www.kitware.com/opensource/opensource.html
>> >> >
>> >> > Follow this link to subscribe/unsubscribe:
>> >> > http://www.vtk.org/mailman/listinfo/vtk-developers
>> >> >
>> >> >
>> >> _______________________________________________
>> >> Powered by www.kitware.com
>> >>
>> >> Visit other Kitware open-source projects at
>> >> http://www.kitware.com/opensource/opensource.html
>> >>
>> >> Follow this link to subscribe/unsubscribe:
>> >> http://www.vtk.org/mailman/listinfo/vtk-developers
>> >>
>> >
>> >
>> > _______________________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://www.vtk.org/mailman/listinfo/vtk-developers
>> >
>> >
>> >
>
>

More information about the vtk-developers mailing list