Sun 23 Oct 2016 07:37:18 PM UTC, comment #22:
The package installs without error on 4.0.0 .
|
Mon 17 Oct 2016 06:21:12 PM UTC, comment #21:
Eric, I pushed one more change to the configure.ac in the dicom package. Could you pull and update your clone of the dicom package and try again?
I really think this is fixed now, can you confirm?
|
Fri 14 Oct 2016 03:51:32 PM UTC, comment #20:
I tried on Debian stretch and got the same error of undefined symbols. It all boils down to cmake --find-package returning no link flags for gdcm in Debian. I have found it on Debian bug tracker and commented there https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826048#34
If I understood the issue correctly (I'm not sure I did), then we'd have to manually set GDCM_LIBS with all the flags we need instead of relying on cmake.
|
Fri 14 Oct 2016 04:40:01 AM UTC, comment #19:
I get the following error in 4.0.0 . Unfortunately I cannot seem to build from the latest hg pull -- errors in yylex etc.
|
Thu 13 Oct 2016 04:09:26 PM UTC, comment #18:
That is a bug but it's different from the original bug report here (it is also limited to Octave 4.1+ and maybe 4.2). Can you try to install de generated tarball in Octave 4.0? And also on the new 4.2 (the bug you are seeing should have been fixed in core since)?
|
Thu 13 Oct 2016 03:23:58 PM UTC, comment #17:
p.s. If you decide it is a bug, I am happy to work on it, so long as there is someone who offers to be responsive to any questions that I have, as my knowledge of Octave is not yet very deep.
|
Thu 13 Oct 2016 03:21:39 PM UTC, comment #16:
Hi Carnë,
I get the following error in Octave 4.1.0+
I also received an error at home on 4.0.0 . I believe this was the same error but I have to check. I am not convinced that my version of 4.0 runs "clean" here now that I have installed 4.1 .
|
Tue 11 Oct 2016 08:17:18 PM UTC, comment #15:
Eric, I am unsure about your changes. You are patching the released tarball but there's been some changes on the development sources.
I have written a Makefile for that package that should help you with that. Can you please try this and see if it works:
That will create a new release from development sources inside the target directory. Can you give that a go and check if there's still an issue before we re-open it?
|
Sat 23 Jul 2016 08:31:44 AM UTC, comment #14:
Okay, I can confirm that the patched tarball installs on 4.0.3 on a second site. However it does not work with 4.1 due to one error in dicomread.
Shall I post this one 4.1 error to the bug tracker? It would be nice to have this 0.1.2 patch in place first, then address the 4.1 related bug separately.
I have attached the patch, below.
(file #37993)
|
Wed 20 Jul 2016 08:21:08 AM UTC, comment #13:
For anyone interested in using the DICOM package right away, I have created a functioning, installable tarball release of the dicom package, working off Carne's code, using a copy of meld and a little sweat.
It currently has hard coded paths in the Makefile for GDCM includes and headers. These will work for the latest pull of GDCM on a Linux installation, but can be edited for any other installation, or alternatively the user just needs the paths in his default path environment variables.
I have posted the proposed tarball to dropbox:
https://www.dropbox.com/s/hyqtw4jd4a2h5b5/dicom-0.1.2.tar.gz?dl=0
I will be able to test it on Octave 4.1 when I go into the office later today and I welcome any other testing.
|
Fri 15 Jul 2016 07:11:08 PM UTC, comment #12:
I can confirm that this builds with cmake 3.2.2, the latest pull of GDCM from github, and Octave 4.0.0 , with one warning, and passes make test.
The build seems to just have dropped .oct files in the src folder. Can anyone give me a hint here, how I can turn this into an an installable package? It is not apparent from the documentation I have been able to find. TIA
|
Fri 15 Jul 2016 06:05:27 PM UTC, comment #11:
To add the missing link flags, I instead changed configure to also use the ones found with cmake
http://hg.code.sf.net/p/octave/dicom/rev/c91635232dc2
So the only issue now is that installing requires cmake which I think is an issue with mxe-octave instead.
|
Fri 15 Jul 2016 05:34:58 PM UTC, comment #10:
I have amended the cset to only handle the issue with Octave_map and pushed http://hg.code.sf.net/p/octave/dicom/rev/f8c250dada13
|
Wed 13 Jul 2016 05:35:37 PM UTC, comment #9:
http://hg.code.sf.net/p/octave/dicom
|
Wed 13 Jul 2016 11:33:38 AM UTC, comment #8:
Can anyone suggest where I might get these developmental sources? A search yields nothing apparent. Or should I just patch up the tarball?
|
Wed 13 Jul 2016 10:22:24 AM UTC, comment #7:
> Sorry if I'm missing something obvious, ut this patch appears to bear no relation to the dicom-0.1.1.tar.gz currently available.
Yes, it bears no relation with the release tarball. This is a patch for the development sources. Your issue is also with development version of octave core.
|
Wed 13 Jul 2016 08:37:47 AM UTC, comment #6:
I took out the references to makefile and configure, and applied only the patches to the *.cpp files . That part of the patch works fine and resolves some issues. I was able to resolve some of the remaining issues.
I now am down to this error. Any quick help would be appreciated:
In file included from /usr/local/include/octave-4.1.0+/octave/../octave/Array.h:37:0,
from /usr/local/include/octave-4.1.0+/octave/../octave/boolMatrix.h:29,
from /usr/local/include/octave-4.1.0+/octave/../octave/mx-base.h:34,
from /usr/local/include/octave-4.1.0+/octave/../octave/Matrix.h:32,
from /usr/local/include/octave-4.1.0+/octave/../octave/oct.h:30,
from dicomread.cpp:25:
/usr/local/include/octave-4.1.0+/octave/../octave/dim-vector.h: In instantiation of ‘dim_vector::dim_vector(octave_idx_type, octave_idx_type, Ints ...) [with Ints = {unsigned int}; octave_idx_type = int]’:
dicomread.cpp:113:48: required from here
/usr/local/include/octave-4.1.0+/octave/../octave/dim-vector.h:215:5: error: unable to deduce ‘std::initializer_list<_Tp>&&’ from ‘{r, c, lengths#0}’
for (const auto l: {r, c, lengths...})
^
Makefile:44: recipe for target 'dicomread.oct' failed
|
Wed 13 Jul 2016 08:06:51 AM UTC, comment #5:
Sorry if I'm missing something obvious, ut this patch appears to bear no relation to the dicom-0.1.1.tar.gz currently available.
The patch calls src/Makefile.in and src/configure.ac
Neither of these files are in the octave dicom package . There is a Makefile in the src/ folder but it is just called Makefile. There is no configure.ac file in the src/ folder
I thought maybe this patch was for the octave source, but those files are not in the src/ folder there either.
Please advise?
I will try to get this library working, shall I post progress here?
|
Tue 12 Jul 2016 04:10:13 PM UTC, comment #4:
I don't think that the dependency on cmake should be handled. This package is dependent on gcdm which required Cmake to build. And gdcm provides cmake project files for any dependent to use so it is a dependent.
If the user does not want to have cmake, then it can configure the flags himself.
We should probably copy the CMAKE_FIND_PACKAGE macro to the package source tree tough.
|
Thu 07 Apr 2016 08:17:33 PM UTC, comment #3:
Still same for 4.0.1 - currently patched in mxe-octave for this issue and using gcdm 2.4
|
Tue 07 Jul 2015 04:59:42 PM UTC, comment #2:
Adding package maintainer to cc
|
Tue 07 Jul 2015 04:51:43 PM UTC, comment #1:
Attached patch on current hg works for me for Fedora Rawhide with octave 4.0.0.
|
Tue 24 Mar 2015 08:36:37 PM UTC, original submission:
The current released, and in mercurial version of dicom will not compile in octave due to depreciated use of Octave_map.
In addition, even if it did compile ok, it requires additional libraries to compile in mingw.
A related issue (although not really a dicom package problem) is that mxe-octave does not have a native cmake installed, so the build will fail as cmake is required in order to find where gdcm was installed.
The attached patch has changed Octave_map to octave_map, adds additional libraries required for mingw (which appear to work ok when also linked in Fedora Linux) and includes a backup search for gdcm if cmake wasn't found.
|