[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: Bug#957360: insighttoolkit4: ftbfs with GCC-10



Hi Steven,

Steven Robbins, on 2020-08-08 17:25:05 -0500:
> On Saturday, August 8, 2020 4:34:39 P.M. CDT Étienne Mollier wrote:
> > > 2. I wonder whether some of the older patches (dating from 2016) should be
> > > dropped; in particular:
> > > 
> > > atomic_load.patch
> > 
> > I'm missing context, and the issue tracker pointed to by the URL
> > in the header does not seem to have migrated to the current
> > platform unfortunately.  :/
> 
> I managed to find it here: https://insightsoftwareconsortium.atlassian.net/
> browse/ITK-3413
> 
> But that doesn't shed a lot of light.  The only thing I see relevant is "Make 
> the Load operation truly atomic - doesn't change anything on amd64 or i386, 
> but it may be of interest for other archs. "   However, the patch removes one 
> usage of __sync_synchronize, but leaves another in the Store() function, which 
> seems suspect.  I would believe that there may have been a bug in the x86 
> codegen in 2016, but we've got 4 years of compiler fixes since then, so I am of 
> the opinion to remove this on that basis.  And the basis that upstream ITK has 
> not incorporated this change in 4 years.

Okay, I guess this might be removed then.

> > > itk4.10.0-python-wrapping.patch
> > 
> > I have the impression that this second one is needed to avoid
> > use of included third party libraries and use the one provided
> > by Debian.
> 
> You must be looking at a different patch.

Indeed I erroneously had a look at the nifti patch; let's say
that it was late in my TZ.  :)

> This one is:
> 
> --- a/Modules/Filtering/ImageGrid/wrapping/itkResampleImageFilter.wrap
> +++ b/Modules/Filtering/ImageGrid/wrapping/itkResampleImageFilter.wrap
> @@ -8,6 +8,7 @@
>    foreach(d ${ITK_WRAP_IMAGE_DIMS})
>      foreach(t ${to_types})
>        itk_wrap_template("${ITKM_VI${t}${d}}${ITKM_VI${t}${d}}" "${ITKT_VI${t}
> ${d}},${ITKT_VI${t}${d}}")
> +      itk_wrap_template("${ITKM_I${t}${d}}${ITKM_I${t}${d}}" "${ITKT_I${t}$
> {d}},${ITKT_I${t}${d}}")
>      endforeach()
>    endforeach()
>  
> I don't see any motivation to adding the extra wrapping.  This patch was added 
> in 2016, along with itk4.10.0_itkTriangleHelper.h.patch (since removed) to fix 
> a build failure on amd64 (see #835761).  The bug traces to ITK issue https://
> insightsoftwareconsortium.atlassian.net/browse/ITK-3466 which was said to be 
> addressed in 4.10.1 with this commit: https://github.com/
> InsightSoftwareConsortium/ITK/commit/be1e9f88ff036048148d4b8b887b8671739307d4
> This commit amounts to the content of the former 
> itk4.10.0_itkTriangleHelper.h.patch.  
> 
> I have run the build with this patch removed to no noticable effect -- only 
> test failure remains Test #2625: PythonExtras.
> 
> This seems safe to remove.

Agreed, assuming upstream fixed the corresponding issue somehow.

> > > itk4.12.0-resource_cprobe.patch
> > 
> > This last one seems needed for i386 support, but might require
> > to check how behaves the targeted equipment before drop.  Maybe
> > I can attempt a build without the patch on my i386 alarm clock.
> 
> I ran the build with this patch removed to no noticable effect -- only test 
> failure remains Test #2625: PythonExtras.  But this was amd64.  I'll do it 
> again on x86 before comitting the removal.

I triggered a build on i386 without those patches, will see how
it goes.  I'm doing it on real hardware, so it smells like it
will take quite a long time, hope it won't melt with these days'
heat.

About the Test #2625: PythonExtras, I failed to reproduce any
issue at build time.  Actually I see no such test there, as if
something might have been missing on my side.  I triggered an
autopkgtest, in case I haven't been looking at the proper
location.

Kind Regards,
-- 
Étienne Mollier <etienne.mollier@mailoo.org>
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.

Attachment: signature.asc
Description: PGP signature


Reply to: