Hi, On 08/16/2014 08:10 AM, Clarkson, Matt wrote: > Thanks Sascha. > > Quick feedback: > 1. Our CLIs all run via a script. So I simply disabled auto-loading for > these modules, and removed some other debug from our code. This wasn’t a > problem before, in MITK-2013.09, as mitkCore didnt autoload lots of other > stuff. But I like the autoloading, it has enabled us to tidy up some other > code. i.e. unit tests don’t explicitly need to register factories, etc.etc. > So we have a workaround for now until 17581 is done.
Okay, we are working on it. > 2. It turned out to not be an LD_LIBRARY_PATH problem. Well…actually, it > was 2 things. We were running external apps like NiftyReg, which I needed to > recompile, as I was picking up an incorrect library which then had a > dependency i was unaware of. However, I also found lots of other problems in > the XML. In the last round of CLI changes, we made it so that all errors are > caught and a message box generated. This was not the case before, so things > that failed XML validation simply silently disappeared and never showed up in > the CLI plugin. Now we get an error message. So there was actual XML i needed > to fix to get past the strict validation. The error reporting is paying off now :-) > So, nothing for you to do. Good to know, thanks for the update. - Sascha > Thanks > > M > > On 7 Aug 2014, at 12:14, Sascha Zelzer <[email protected]> wrote: > >> Hi, >> >> On 08/07/2014 10:47 AM, Clarkson, Matt wrote: >>> Hi there, >>> >>> I just noticed the following after our recent MITK upgrade to 2014-03. >>> >>> 1. When a command line module is run, there can be lots of output on the >>> console std::out output to do with auto-loading of modules. Is there a way >>> to turn the output off, as it won’t be valid XML. >> In this moment, some of our guys are working on exactly that issue. This is >> bug http://bugs.mitk.org/show_bug.cgi?id=17581 . If everything goes well, >> this should be configurable soon. >> >>> 2. It appears (although I may have diagnosed it wrong), that command line >>> apps no longer have the library path set to be that of the calling >>> application. For example, when run on Linux, MITK provides bash scripts to >>> setup the LD_LIBRARY_PATH to be the bin folder plus bin/plugins. This now >>> appears to launch the main app ok, but command line modules are not run, as >>> they dont have the same path. >>> >>> Is that right? >> This is new to me. When starting MitkWorkbench from for the build directory, >> I don't use shell scripts but the few cmd line apps I am using just worked >> out of the box. The cmd line app process should actually inherit the >> environment from the parent process. >> >> It could also have to do with missing rpath information for specific cmd >> line apps, so their dependencies can not be resolved by the dynamic linker >> without extending LD_LIBRARY_PATH. >> >> Best, >> Sascha >> >> ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
