Hi,
I recently had a look onto that, too.
In MitkWorkbench.cpp (shouldn't it be names mitkWorkbench?) the variable
QMap<QString, QString> preloadLibVersion;
is left unmodified.
Later on it is supposed to extend the pre-load library strings by the version.
preloadConfig += preloadLib + preloadLibVersion[preloadLib] + ",";
Is that ment to be an example but not used within mitkWorkbench?
I see in ctkPluginFrameworkContext::init() that the pure name without the version is working as well.
Can you give a use case to load a library of a different version?
Have a nice weekend,
Ingmar
--------------------------------------------------------------------
From: Sascha Zelzer <s.zelzer@...>
Subject: Re: Query about pre-loading library
Newsgroups: gmane.comp.lib.mitk.user
Date: 2015-01-15 10:57:54 GMT (4 weeks, 1 day and 4 minutes ago)
Subject: Re: Query about pre-loading library
Newsgroups: gmane.comp.lib.mitk.user
Date: 2015-01-15 10:57:54 GMT (4 weeks, 1 day and 4 minutes ago)
Hi, On 01/15/2015 09:59 AM, Clarkson, Matt wrote: > Hi there, > > following our upgrade to MITK 2014.10, it looks to me like the code for preloading libraries in MITK Workbench is a bit … er … not what I expect. > > In 2014.03 we had: > https://github.com/MITK/MITK/blob/eb025ddf02d2d7c60eada2f68dab39274420dea8/Applications/Workbench/MitkWorkbench.cpp > > In the latest master we have: > https://github.com/MITK/MITK/blob/master/Applications/Workbench/MitkWorkbench.cpp > > So, in 2014.03 we try to pre-load both liborg_mitk_gui_qt_ext and CTKDICOMCore (on non-windows platforms). > In 2014.10 we try to load only liborg_mitk_gui_qt_ext.
Yes, we fixed error/warning messages of libraries not being found on Windows and MacOS during pre-loading. > > Q1: Is CTKDICOMCore no longer needed to be pre-loaded. I seem to remember that some install path in some version of DCMTK was fixed (Andreas/Sascha maybe) so, maybe we don’t need to preload it. CTKDICOMCore was pre-loaded as a work-around to buggy static init/deinit code in static dcmtk libraries for Linux. Since some time, we are building dcmtk as a shared library which fixed the static issues we had. > > Q2: In both of these cases, the code looks to me like it will only pre-load one library. If you wanted to specify a list of libraries to pre-load, the 2014.03 version doesn’t contain a loop to set the path correctly for each library. In the latest master, there is a loop over the entries in a QStringList, which calculates either the build-tree path or the install-tree path, but then the preloadConfig variable simply ignores it, so the final value passed to extConfig->setString(berry::Platform::ARG_PRELOAD_LIBRARY, preloadConfig.toStdString()); will never contain the right path (on a Mac at least). > > Any thoughts? It looks wrong to me…. or I need more coffee today. More Coffee might helpThe first for loop calculates absolute paths and changes the entries in preloadLibs in-place. The second Q_FOREACH loop appends all library paths to the preloadConfig string variable (comma separated). Best, Sascha ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet
------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ mitk-users mailing list mitk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mitk-users
