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. 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.
So, nothing for you to do. 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 > > ------------------------------------------------------------------------------ _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
