Opened 6 years ago

Last modified 3 years ago

#936 new task

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

Reported by: ak19 Owned by: ak19
Priority: moderate Milestone: 3.11 Release
Component: Greenstone2&3 Severity: major
Keywords: remote Cc:


For the GS287 release (rc1), 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.

Change History (2)

comment:1 by ak19, 6 years ago

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

Another ticket for the GS3 release:

check binary on El Capitan to make sure that after doing "source ./", 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/, which ends up being sourced by

The way to test that DYLD_FALLBACK_LIBRARY_PATH being set is the cause is to use a fresh xterm, not source, 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 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.


Dr Bainbridge's solution is to move the setting of (DY)LD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH from ext/imagemagick/ into gs2build/bin/script/

After doing this, ensure the regenerated GS3 binary's imagemagick works, by running to through the imagemagick tests described at in section "THINGS TO CHECK".

comment:2 by kjdon, 3 years ago

Milestone: 3.10 Release3.11 Release

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.