Re: should google-glog be ok with libunwind7-dev? [Was: Orthanc 0.7.2 backport of wheezy]
Hi,
Thanks to Daigo's -2 of glog with suggested tune up of build-depends,
I have uploaded backport build of orthanc for wheezy straight into
NeuroDebian wheezy just to give it a try...
Fine! Could you give the link to the repository containing your backport?
Would it be possible for you to integrate this backport into the main
Debian Med repository?
initial catch was the re-located *.dic files provided by libdcmtk2
(under /usr/share/dcmtk in wheezy and /usr/share/libdcmtk2/ in sid now):
orthanc silently failed to start. log msgs just finished with log lines
stating that it was "Loading the external DICOM dictionary" without any
failure/error msg following.
This is very strange. Here is what I get when I use a bad path to the
dictionaries, with Orthanc 0.7.2:
jodogne@rth-l-0065:~/Subversion/Orthanc/Build$ ./Orthanc
W0213 09:51:43.822284 10679 OrthancInitialization.cpp:82] Using the
configuration from:
/home/jodogne/Subversion/Orthanc/Resources/Configuration.json
W0213 09:51:43.825232 10679 DicomServer.cpp:87] Loading the external
DICOM dictionary "/usr/share/dcmtkeec/dicom.dic"
E: DcmDataDictionary: Cannot open file: /usr/share/dcmtkeec/dicom.dic
E0213 09:51:43.825423 10679 main.cpp:446] EXCEPTION [Internal error]
W0213 09:51:43.825594 10679 main.cpp:457] Orthanc has stopped
So, in my case, there is no silent failure.
Sebastien, do you think could you make discovery of the path 'automagic'
thus avoiding necessity to patch for the path? probably the best it
could be achieved through cmake's find_file looking under common
suspect paths (/usr/share/dcmtk /usr/share/libdcmtk2) if
DCMTK_DICTIONARY_DIR was not specified (and thus avoiding its hard-coded
specification in debian/rules)?
Yes, certainly, this is an interesting suggestion! I have just added it
to the roadmap [1].
Cheers,
Sébastien-
[1] https://trello.com/c/f2PFTdRw
Reply to: