Quantcast

dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

Olaf Till-2
On Tue, Feb 21, 2017 at 08:46:25PM +0000, lostbard wrote:
> Is the real fix the ability to find the settings no matter the OS,
> or the ability to provide a way to get the package to compile ie:
> being able to provide additional parameters if needed to get it to
> compile?

The latter... but by reliably determining the architecture for which
the compilation is intended.

Ideally, cmake should have the architecture compiled in and include
the correct /usr/lib/<target> path in its search for gdcm
configuration information. (But as we know now, cmake doesn't do this
correctly.)

So we have to manually get the intended architecture:

- Asking the compiler suite would probably make us dependent on a
  specific compiler, so not good.

- Fortunately we can ask Octave: 'octave-config -p
  CANONICAL_HOST_TYPE'. This may return a quadruplett instead of a
  triplett -- in this case the second component must be removed to get
  <target> above.

We can try to use this information in one of the following ways:

1. Provide the information to 'cmake --find-package' to make it find
   the gdcm configuration information. If this is possible, it seems
   the correct way to me, better than 2. . (We don't need an m4 makro
   to call 'cmake --find-package'.)

2. Search for gdcm includes and libs independently from cmake. But
   what if gdcm decides to take on an unforeseen directory name or
   uses an additional directory (say
   /usr/include/gdcm-extra-<version>/, or something like that).

Olaf

> Playing around a little, I see there is a bug with cmake.m4 in the
> repo, so that if you provide your own GDCM_CXXFLAGS and GDCM_LIBS,
> it stilll sets them via cmake - I will push a change up for that
>
> For autoconf, it would somehow have to check all include paths for
> all versions of gcdm.
>
> You are right though, more discusion should go on the maintainers list.




> ** [package-releases:#296] dimcom-0.2.0**
> <https://sourceforge.net/p/octave/package-releases/296/>


--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

Olaf Till-2
On Wed, Feb 22, 2017 at 11:06:27AM +0100, Olaf Till wrote:
> So we have to manually get the intended architecture:
>
> - Asking the compiler suite would probably make us dependent on a
>   specific compiler, so not good.
>
> - Fortunately we can ask Octave: 'octave-config -p
>   CANONICAL_HOST_TYPE'. This may return a quadruplett instead of a
>   triplett -- in this case the second component must be removed to get
>   <target> above.

Sorry, forget the above... we should use AC_CANONICAL_TARGET. So the
target is guessed or specified by the user. Better for cross
compiling.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

Olaf Till-2
On Wed, Feb 22, 2017 at 11:06:27AM +0100, Olaf Till wrote:
> We can try to use this information in one of the following ways:
>
> 1. Provide the information to 'cmake --find-package' to make it find
>    the gdcm configuration information. If this is possible, it seems
>    the correct way to me, better than 2. . (We don't need an m4 makro
>    to call 'cmake --find-package'.)

It worked with setting CMAKE_LIBRARY_ARCHITECTURE:

...$ cmake --find-package -DNAME=GDCM -DCOMPILER_ID=GNU -DLANGUAGE=CXX -DMODE=COMPILE
GDCM not found.
CMake Error: Problem processing arguments. Aborting.

...$ cmake --find-package -DNAME=GDCM -DCOMPILER_ID=GNU -DLANGUAGE=CXX -DMODE=COMPILE -DCMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu
-I/usr/include/gdcm-2.4

So this should be a feasible strategy:

1. determine architecture with AC_CANONICAL_TARGET,

2. if necessary, remove 2nd component from found target to get a
   triplett <target> (as x86_64-linux-gnu above),

3. don't use the m4 macro, but manually call cmake --find-package by
   specifying -DCMAKE_LIBRARY_ARCHITECTURE=<target>.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

Olaf Till-2
The attached patch works for me (i.e. installation succeeds).

I mean it worked for me before your latest changeset, but not
afterwards. It seems to me that your changeset causes 'cmake
--find-package ...'  never to be called.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

Olaf Till-2
On Wed, Feb 22, 2017 at 02:21:45PM +0100, Olaf Till wrote:
> The attached patch works for me (i.e. installation succeeds).
>
> I mean it worked for me before your latest changeset, but not
> afterwards. It seems to me that your changeset causes 'cmake
> --find-package ...'  never to be called.

Oops, this time with the attachment. Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

multiarch-fix.cset (2K) Download Attachment
signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

John Donoghue-2
I pushed a fix for my cmake.m4 fix

On Wed, Feb 22, 2017 at 8:23 AM, Olaf Till <[hidden email]> wrote:
On Wed, Feb 22, 2017 at 02:21:45PM +0100, Olaf Till wrote:
> The attached patch works for me (i.e. installation succeeds).
>
> I mean it worked for me before your latest changeset, but not
> afterwards. It seems to me that your changeset causes 'cmake
> --find-package ...'  never to be called.

Oops, this time with the attachment. Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

Olaf Till-2
On Wed, Feb 22, 2017 at 09:00:14AM -0500, John Donoghue wrote:
> I pushed a fix for my cmake.m4 fix

Works again, adapted changeset is attached.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

multiarch-fix.cset (2K) Download Attachment
signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

John Donoghue-2
Works in fedora - will try in Windows

On Wed, Feb 22, 2017 at 9:12 AM, Olaf Till <[hidden email]> wrote:
On Wed, Feb 22, 2017 at 09:00:14AM -0500, John Donoghue wrote:
> I pushed a fix for my cmake.m4 fix

Works again, adapted changeset is attached.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

Olaf Till-2
On Wed, Feb 22, 2017 at 12:31:12PM -0500, John Donoghue wrote:
> cross compile in mxe works when specifying CMAKE_BINARY with the correct
> toolchain file, similar to other cmake programs buil in mxe.
>
> DO you want to push up your changeset?

I've pushed it.

> I'll bump the dicom version and regenerate a new pakage

You needn't bump the version. We'll just move the tag, this is
possible in mercurial and I can do it for you when pushing the
release. (In the future we'll probably advise to tag only after the
release, or we'll do it ourselves at pushing time if possible.)

I paste the test output, for the case you still want to do something
about it before the release (note that in manual testing, dicomread()
with imshow() worked well). Note that I had to symlink all .cpp files
to .cc for runtests() to work.

Olaf

------ test output follows ----------

octave:7> runtests (".")
Processing files in /home/olaf/devel/octave-forge/package-repositories/all/octave-forge/dicom/src:

  dicomdict.cc ...........................................warning: implicit conversion from scalar to sq_string
 PASS    4/4  
  dicominfo.cc ...........................................warning: implicit conversion from scalar to sq_string
Error: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx, line 332, function bool gdcm::Reader::InternalReadCommon(const T_Caller&) [with T_Caller = gdcm::details::DefaultCaller]
No File


 PASS    5/5  
Error: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx, line 332, function bool gdcm::Reader::InternalReadCommon(const T_Caller&) [with T_Caller = gdcm::details::DefaultCaller]
No File


  dicomread.cc ........................................... PASS    4/4  
  dicomuid.cc ............................................warning: implicit conversion from null_matrix to sq_string
Error: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx, line 332, function bool gdcm::Reader::InternalReadCommon(const T_Caller&) [with T_Caller = gdcm::details::DefaultCaller]
No File


 PASS    5/5  
Warning: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmMediaStorage.cxx, line 504, function bool gdcm::MediaStorage::SetFromModality(const gdcm::DataSet&)
Unknown/Unhandle MediaStorage, but Pixel Data element found


  dicomwrite.cc ..........................................warning: implicit conversion from null_matrix to sq_string
warning: implicit conversion from null_matrix to sq_string
Warning: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmMediaStorage.cxx, line 504, function bool gdcm::MediaStorage::SetFromModality(const gdcm::DataSet&)
Unknown/Unhandle MediaStorage, but Pixel Data element found


Warning: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmMediaStorage.cxx, line 504, function bool gdcm::MediaStorage::SetFromModality(const gdcm::DataSet&)
Unknown/Unhandle MediaStorage, but Pixel Data element found


 PASS    7/7  
  isdicom.cc ............................................. PASS    3/3  

The following files in /home/olaf/devel/octave-forge/package-repositories/all/octave-forge/dicom/src have no tests:

_gendicomdict.cc


--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

JohnD

On Wed, Feb 22, 2017 at 12:31:12PM -0500, John Donoghue wrote:
> cross compile in mxe works when specifying CMAKE_BINARY with the correct
> toolchain file, similar to other cmake programs buil in mxe.
>
> DO you want to push up your changeset?

I've pushed it.

> I'll bump the dicom version and regenerate a new pakage

You needn't bump the version. We'll just move the tag, this is
possible in mercurial and I can do it for you when pushing the
release. (In the future we'll probably advise to tag only after the
release, or we'll do it ourselves at pushing time if possible.)

I paste the test output, for the case you still want to do something
about it before the release (note that in manual testing, dicomread()
with imshow() worked well). Note that I had to symlink all .cpp files
to .cc for runtests() to work.

Olaf

------ test output follows ----------

octave:7> runtests (".")
Processing files in /home/olaf/devel/octave-forge/package-repositories/all/octave-forge/dicom/src:

  dicomdict.cc ...........................................warning: implicit conversion from scalar to sq_string
 PASS    4/4
  dicominfo.cc ...........................................warning: implicit conversion from scalar to sq_string
Error: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx, line 332, function bool gdcm::Reader::InternalReadCommon(const T_Caller&) [with T_Caller = gdcm::details::DefaultCaller]
No File


 PASS    5/5
Error: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx, line 332, function bool gdcm::Reader::InternalReadCommon(const T_Caller&) [with T_Caller = gdcm::details::DefaultCaller]
No File


  dicomread.cc ........................................... PASS    4/4
  dicomuid.cc ............................................warning: implicit conversion from null_matrix to sq_string
Error: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx, line 332, function bool gdcm::Reader::InternalReadCommon(const T_Caller&) [with T_Caller = gdcm::details::DefaultCaller]
No File


 PASS    5/5
Warning: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmMediaStorage.cxx, line 504, function bool gdcm::MediaStorage::SetFromModality(const gdcm::DataSet&)
Unknown/Unhandle MediaStorage, but Pixel Data element found


  dicomwrite.cc ..........................................warning: implicit conversion from null_matrix to sq_string
warning: implicit conversion from null_matrix to sq_string
Warning: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmMediaStorage.cxx, line 504, function bool gdcm::MediaStorage::SetFromModality(const gdcm::DataSet&)
Unknown/Unhandle MediaStorage, but Pixel Data element found


Warning: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmMediaStorage.cxx, line 504, function bool gdcm::MediaStorage::SetFromModality(const gdcm::DataSet&)
Unknown/Unhandle MediaStorage, but Pixel Data element found


 PASS    7/7
  isdicom.cc ............................................. PASS    3/3

The following files in /home/olaf/devel/octave-forge/package-repositories/all/octave-forge/dicom/src have no tests:

_gendicomdict.cc

 

 

There was a fix to octave in order to support .cpp files in the dev version at least

In dicom, the tests get extracted out from the src and installed as part of the package now

 

The octave warnings look valid for the some of the tests being run: ie: trying to load a integer instead of a filename

 

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

John Donoghue-2
In reply to this post by Olaf Till-2


On Wed, Feb 22, 2017 at 2:33 PM, Olaf Till <[hidden email]> wrote:
On Wed, Feb 22, 2017 at 12:31:12PM -0500, John Donoghue wrote:
> cross compile in mxe works when specifying CMAKE_BINARY with the correct
> toolchain file, similar to other cmake programs buil in mxe.
>
> DO you want to push up your changeset?

I've pushed it.

> I'll bump the dicom version and regenerate a new pakage

You needn't bump the version. We'll just move the tag, this is
possible in mercurial and I can do it for you when pushing the
release. (In the future we'll probably advise to tag only after the
release, or we'll do it ourselves at pushing time if possible.)

I paste the test output, for the case you still want to do something
about it before the release (note that in manual testing, dicomread()
with imshow() worked well). Note that I had to symlink all .cpp files
to .cc for runtests() to work.

Olaf

------ test output follows ----------

octave:7> runtests (".")
Processing files in /home/olaf/devel/octave-forge/package-repositories/all/octave-forge/dicom/src:

  dicomdict.cc ...........................................warning: implicit conversion from scalar to sq_string
 PASS    4/4
  dicominfo.cc ...........................................warning: implicit conversion from scalar to sq_string
Error: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx, line 332, function bool gdcm::Reader::InternalReadCommon(const T_Caller&) [with T_Caller = gdcm::details::DefaultCaller]
No File


 PASS    5/5
Error: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx, line 332, function bool gdcm::Reader::InternalReadCommon(const T_Caller&) [with T_Caller = gdcm::details::DefaultCaller]
No File


  dicomread.cc ........................................... PASS    4/4
  dicomuid.cc ............................................warning: implicit conversion from null_matrix to sq_string
Error: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx, line 332, function bool gdcm::Reader::InternalReadCommon(const T_Caller&) [with T_Caller = gdcm::details::DefaultCaller]
No File


 PASS    5/5
Warning: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmMediaStorage.cxx, line 504, function bool gdcm::MediaStorage::SetFromModality(const gdcm::DataSet&)
Unknown/Unhandle MediaStorage, but Pixel Data element found


  dicomwrite.cc ..........................................warning: implicit conversion from null_matrix to sq_string
warning: implicit conversion from null_matrix to sq_string
Warning: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmMediaStorage.cxx, line 504, function bool gdcm::MediaStorage::SetFromModality(const gdcm::DataSet&)
Unknown/Unhandle MediaStorage, but Pixel Data element found


Warning: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmMediaStorage.cxx, line 504, function bool gdcm::MediaStorage::SetFromModality(const gdcm::DataSet&)
Unknown/Unhandle MediaStorage, but Pixel Data element found


 PASS    7/7
  isdicom.cc ............................................. PASS    3/3

The following files in /home/olaf/devel/octave-forge/package-repositories/all/octave-forge/dicom/src have no tests:

_gendicomdict.cc


--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

I added a check that input was a string on the tests that were showing a warning about not beig given a string


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

John Donoghue-2


On Wed, Feb 22, 2017 at 10:15 PM, John Donoghue <[hidden email]> wrote:


On Wed, Feb 22, 2017 at 2:33 PM, Olaf Till <[hidden email]> wrote:
On Wed, Feb 22, 2017 at 12:31:12PM -0500, John Donoghue wrote:
> cross compile in mxe works when specifying CMAKE_BINARY with the correct
> toolchain file, similar to other cmake programs buil in mxe.
>
> DO you want to push up your changeset?

I've pushed it.

> I'll bump the dicom version and regenerate a new pakage

You needn't bump the version. We'll just move the tag, this is
possible in mercurial and I can do it for you when pushing the
release. (In the future we'll probably advise to tag only after the
release, or we'll do it ourselves at pushing time if possible.)

I paste the test output, for the case you still want to do something
about it before the release (note that in manual testing, dicomread()
with imshow() worked well). Note that I had to symlink all .cpp files
to .cc for runtests() to work.

Olaf

------ test output follows ----------

octave:7> runtests (".")
Processing files in /home/olaf/devel/octave-forge/package-repositories/all/octave-forge/dicom/src:

  dicomdict.cc ...........................................warning: implicit conversion from scalar to sq_string
 PASS    4/4
  dicominfo.cc ...........................................warning: implicit conversion from scalar to sq_string
Error: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx, line 332, function bool gdcm::Reader::InternalReadCommon(const T_Caller&) [with T_Caller = gdcm::details::DefaultCaller]
No File


 PASS    5/5
Error: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx, line 332, function bool gdcm::Reader::InternalReadCommon(const T_Caller&) [with T_Caller = gdcm::details::DefaultCaller]
No File


  dicomread.cc ........................................... PASS    4/4
  dicomuid.cc ............................................warning: implicit conversion from null_matrix to sq_string
Error: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx, line 332, function bool gdcm::Reader::InternalReadCommon(const T_Caller&) [with T_Caller = gdcm::details::DefaultCaller]
No File


 PASS    5/5
Warning: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmMediaStorage.cxx, line 504, function bool gdcm::MediaStorage::SetFromModality(const gdcm::DataSet&)
Unknown/Unhandle MediaStorage, but Pixel Data element found


  dicomwrite.cc ..........................................warning: implicit conversion from null_matrix to sq_string
warning: implicit conversion from null_matrix to sq_string
Warning: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmMediaStorage.cxx, line 504, function bool gdcm::MediaStorage::SetFromModality(const gdcm::DataSet&)
Unknown/Unhandle MediaStorage, but Pixel Data element found


Warning: In /build/gdcm-2.4.4/Source/DataStructureAndEncodingDefinition/gdcmMediaStorage.cxx, line 504, function bool gdcm::MediaStorage::SetFromModality(const gdcm::DataSet&)
Unknown/Unhandle MediaStorage, but Pixel Data element found


 PASS    7/7
  isdicom.cc ............................................. PASS    3/3

The following files in /home/olaf/devel/octave-forge/package-repositories/all/octave-forge/dicom/src have no tests:

_gendicomdict.cc


--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

I added a check that input was a string on the tests that were showing a warning about not beig given a string



I need to regenerate new tarballs and attach to the release ticket ?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

Olaf Till-2
On Wed, Feb 22, 2017 at 10:18:45PM -0500, John Donoghue wrote:
> I need to regenerate new tarballs and attach to the release ticket ?

No, since we check 'make release' anyway, I can do that (in the next 2
hours, I think).

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom on multiarch (was: Re: [octave:package-releases] #296 dimcom-0.2.0)

John Donoghue-2
Nice and thanks to everybody who reviewed, made changes etc to get the package released!

On Thu, Feb 23, 2017 at 12:44 AM, Olaf Till <[hidden email]> wrote:
On Wed, Feb 22, 2017 at 10:18:45PM -0500, John Donoghue wrote:
> I need to regenerate new tarballs and attach to the release ticket ?

No, since we check 'make release' anyway, I can do that (in the next 2
hours, I think).

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

Loading...