On 10/01/2012 10:39 AM, Bruce Korb wrote:
On 09/30/12 19:38, Mark H Weaver wrote:
In the current code, SCM_LIB_DIR and SCM_EXTENSIONS_DIR are only
added to the library search path when GUILE_SYSTEM_EXTENSIONS_PATH
is not set. Your patch mishandles this, because it _always_ acts
as if SCM_LIB_DIR and SCM_EXTENSIONS_DIR have been added to the search path.
Always inserting "GUILE_SYSTEM_EXTENSIONS_PATH=" into the environment
is a better fix than erasing LD_LIBRARY_PATH, but I hadn't read and
digested the source. Thanks for the pointer.
Are you deploying this fix in widely-used software, or just within your
private environment? If the latter, that's fine, and you can disregard
the rest of this message.
If the former, then we need to be careful. By setting
GUILE_SYSTEM_EXTENSIONS_PATH="", you will break Guile programs that need
to load extensions, not just within your own program, but within any
subprocesses that might be unrelated to your project.
Also, our internal hack of setting GUILE_SYSTEM_EXTENSIONS="" during the
Guile build is not documented as far as I know, and might change in the
future. It's actually a bad hack, for the same reasons given above.
For example, if 'gcc' started using Guile, then setting
GUILE_SYSTEM_EXTENSIONS="" within the Guile build could break gcc.
I admit that we created this mess by deploying a bad hack, but let's try
to avoid getting ourselves into an even bigger mess by deploying more
bad hacks that lock us into preserving our current hacks.
Before I spend any more time thinking about this, can you please answer
my question above?
Thanks,
Mark
