#121 Indexing plugins on ~/.SAGA breaks platform interoperability

SAGA Bugs (63)

Hi everybody,

we've got some problem with Saga at our site and whether you consider this as being a bug or not is up to you, of course...

At our site, we've got NFS mounted $HOMEs and several computing servers with different architectures and operating systems (Debian Lenny/x86_64 and Solaris10/SPARC, for example), each with a Saga installation on some NFS mounted directory (e.g. a "software tree"). The problem is, that Saga seems to index the plugins in ~/.SAGA and when our users switch to another platform, Saga tries to load the wrong plugins, resulting in "wrong ELF class" errors.

To clarify it:
/sw is the NFS mount
and there exist things like
So, the Solaris-Installation is also accessible from Lenny-machines and the other way around.

If anything of the above is unclear, please don't hestitate to ask for further details or whatever.

A possible solution would be not to index the plugins. A indexing encoding the architecture somehow will not suffice since there can (and at our site are) be different Linux Distibutions and versions be installed on the same architecture, for example Debian Lenny and Suse Linux Enterprise on x86_64.

Thank you very much for having a look!



  • Volker Wichmann

    Volker Wichmann - 2011-07-22

    How about keeping different versions of ~/.SAGA, each for one of your SAGA installations? It should be possible to use a script to start a SAGA session, copying the appropriate ~/.SAGA file to the user home (e.g. ~/.SAGA_lenny to ~/.SAGA) before starting SAGA. After closing SAGA, the script could then copy ~/.SAGA to ~/.SAGA_lenny again to save the current status.

    In case you are looking for the possibility to generally turn off/on the indexing of the modules in the ~/.SAGA file, we would need to introduce a global configuration parameter in SAGA GUI. But this would result in SAGA using the default fallback, i.e. to load all modules found within the modules folder automatically each time you start SAGA. I.e. you would have no control on which modules are loaded other than deleting modules from the installation path.

    I wouldn't treat this as bug but as a feature request.


  • Nicolai Stange

    Nicolai Stange - 2011-07-22

    Of course having a wrapper script that fiddles around with platform dependent files in $HOME is a solution and we've done this with some other, proprietary software in the past. I could even modify saga to force rereading the plugins at every start, I've got the sources ;).
    The question is not whether I can work around this issue, because I know I can (but thanks for your suggestions). For me the question is, whether you want to support this kind of setup or not.

    I've just reported this issue to make you aware of it. What you do with it depends on your policies.

    I chose "bug report" over "feature request" since the behaviour is unexpected for me, but of course, you're free to change this (or resolve it as WONTFIX).

  • Nicolai Stange

    Nicolai Stange - 2011-07-22

    Just for my interest (I'm not a GIS expert, but only a member of the IT services): What is the problem with simply loading all plugins? Startup time?

  • Volker Wichmann

    Volker Wichmann - 2011-07-22

    Some use this mechanism to keep the GUI simple (just load that modules which you usually need), developers use it to keep different versions or load modules from directories other than the installation path and finally some use it to keep free modules apart from commercial ones (which are usually placed within a separate directory).

    So I think in general this configuration option makes sense. Would be great if you could come up with an solution matching all the interests - patches welcome ;-)


  • Nicolai Stange

    Nicolai Stange - 2011-07-22

    Maybe a simple solution would be to encode paths to plugins within the prefix directory by sth. like <prefix>/lib/saga/libio_gdal.so instead of the "real" path /sw/lenny-x64/saga-2.0.7/lib/saga/libio_gdal.so in ~/.SAGA

    I don't know how the recognition of "new" plugins works, but I also wonder whether it would make more sense to maintain a blacklist rather than a whitelist since the default state of every plugin is "enabled".

  • Volker Wichmann

    Volker Wichmann - 2014-04-20
    • status: open --> wont-fix
    • Group: --> v2.1.0
  • Volker Wichmann

    Volker Wichmann - 2014-04-20

    I'm just working through older bug reports and came across this one. SAGA is still encoding the full path in the ~/.SAGA file, so nothing has changed. But I will close this report as wont-fix as you suggested as there are workarounds to this problem. You're still welcome to provide a patch or to issue a feature request.



Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks