Remote GS environment and GS3 Imagemagick Env if it conflicts with wget

[ak19]

For the GS287 release (rc1), gsdlCGI.pm::setup_gsdl() started setting PERL_PERTURB_KEYS and WGETRC, newly added environment vars since the previous GS2 release.

However, we should think of renaming the current setup_gsdl to old_setup_gsdl. And then have setup_gsdl() call util::setup_greenstone_env(), to set all the env vars that are active upon calling setup.bash. setup_gsdl() would also have to continue setting any remote GS specific env vars.

[ak19]

Another ticket for the GS3 release:

check binary on El Capitan to make sure that after doing "source ./gs3-setup.sh", you can run wget without dynamically linked library issues. If they're present, then that will be due to DYLD_FALLBACK_LIBRARY_PATH being set in ext/imagemagick/setup.sh, which ends up being sourced by gs3-setup.sh.

The way to test that DYLD_FALLBACK_LIBRARY_PATH being set is the cause is to use a fresh xterm, not source gs3-setup.sh, go into gs2build/bin/darwin and run wget. If it has no issues running wget, as indicated by the wget usage help message that should appear, then the issue in the other x-term was caused by sourcing gs3-setup.

In the current xterm (that doesn't have the GS3 env vars set), set DYLD_FALLBACK_LIBRARY_PATH to what the other x-term set it to. Note that new MacOS does not show values for this or the DYLD_LIBRARY_PATH env vars, but hides them. Instructions on forcing display of hidden env vars' values is in greenstone2's makegs2.sh as a comment. Use that to find the DYLD_FALLBACK_LIBRARY_PATH value in the first x-term and set it in the second. See if that wget subsequently fails to run in the 2nd x-term with the same DLL related issues. (If not, also set DYLD_LIB_PATH in the 2nd x-term to what it was in the first, and try wget again.) wget will probably fail now.

SOLUTION:

Dr Bainbridge's solution is to move the setting of (DY)LD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH from ext/imagemagick/setup.sh into gs2build/bin/script/gs-magick.pl

After doing this, ensure the regenerated GS3 binary's imagemagick works, by running gs-magick.pl to through the imagemagick tests described at http://trac.greenstone.org/browser/gs2-extensions/imagemagick/trunk/README in section "THINGS TO CHECK".

[kjdon]

Ticket retargeted after milestone closed