On 4/12/2012 10:14 AM, Andy Buckle wrote: > On 11 April 2012 19:29, marco atzeri<marco.atz...@gmail.com> wrote: >> On 4/11/2012 7:20 PM, Andy Buckle wrote: >> >>> >>> In case someone asks about my longer term goal: >>> >>> My aim is to get the dicom package working on Windows. I have tried >>> cygwin and several different versions of octave built with mingw. With >>> these, it compiles fine, then crashes when I call one of the dicom >>> oct-files. If anyone is able to help me get it working, that would be >>> great. Note that it works fine on linux. Under windows gdb was not >>> helpful. >>> >> >> Hi Andy, >> I was playing with dicom / gdcm-2.2.0 on cygwin but >> I obtained only >> >> 83% tests passed, 31 tests failed out of 183 >> >> I noticed that the package need a deep cleaning about >> wrong cygwin assumptions, and I was trying, but >> I also suspect that the socketxx utility need a deep update >> and unfortunately the upstream development and bug fix >> http://www.linuxhacker.at/socketxx >> seems stopped; so the things are harder than I was originally expecting. >> >> I presume you have better understanding of dicom usage than me, >> so if you need an help on cygwin let me know >> >> Marco > > I don't think there are many cygwin/gdcm users. Did you come across > this bug too? I reported it against GDCM 2.0.18, and it is still > listed as open. > http://sourceforge.net/tracker/index.php?func=detail&aid=3469016&group_id=137895&atid=739587 > > The dicom package just deals with dicom files, and does not implement > any of the network bits. (Matlab also does not follow the networking > bits of the DICOM standard either). > > The networking functions are new to GDCM. Mathieu may well be > interested if the cygwin socketxx problems on the GDCM list/bug > tracker. > > I would be grateful if you could try to get the dicom package working > on cygwin octave. I have not tried GDCM 2.2 yet. If it is possible to > configure GDCM with no network functions, could you try that? Or go > back to 2.0.X. > >
Hi Andy it is that type of cleaning that I was playing around. I and others pushed for the change in CMAKE to simplify the development port to cygwin of several packages. Usually is fine but in this case not, due to the old style programming with a lot of conditional IF on platform code. It is why autoconf is a superior tool: "Test for feature not for platform" Cygwin is evolving and the package is not able to cope with the new behaviour and the additional functionalities available. I built gdcm with shared libs but I saw no way to disable the networking functionality. For this reason I was looking on cleaning sockecktxx before merging it back on gdcm. As soon I have some time I will pack a test cygwin gdcm package so we can work together Regards Marco ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
