SourceMage Grimoire Bug List

[bugzilla-daemon AT bugs.sourcemage.org]

http://bugs.sourcemage.org/show_bug.cgi?id=15016


Remko van der Vossen <wich AT sourcemage.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wich AT sourcemage.org




--- Comment #4 from Remko van der Vossen <wich AT sourcemage.org>  2009-08-28 
11:30:12 ---
This actually is a bug in cleanse, or rather a very crude way to get around
issues caused by stupid software using wrapper scripts which set
LD_LIBRARY_PATH before launching the actual binary.

Okay, so the issue is:

check_self runs an ldd on vim, which should fail, and indeed does fail if you
run it manually, however check_self runs ldd with a very big LD_LIBRARY_PATH
set which means the dynamic loader actually can find libperl.so when in fact 
it
shouldn't, leading the check_self to succeed.

You may ask yourself, how does the loader normally find libperl then? That is
what the RPATH entry in the vim ELF binary is for (you can see it by running
readelf -d `which vim`) and you'll see it pointing to the perl path
corresponding to the perl config vim was compiled with. As the path of
libperl.so is changed by changing the threading config option this gets 
broken.

So there are a few options to fix this:

1. The most crude option; change the check_self trigger into a cast_self
trigger, which is overkill since you will rarely switch the threading config
option and the check_self should be sufficient for all other cases, in fact it
should probably also be sufficient for the spells that already do have a
cast_self trigger on perl.

2. The better option is to conditionally trigger a cast_self or a check_self
depending on whether the threading option actually was toggled or not, but
that's a bit fickle.

3. The real solution is to fix cleanse to only use the LD_LIBRARY_PATH it
should be using for a given spell, or given dynamic object even. 
Idealistically
we should go even further and do it with only the LD_LIBRARY_PATH as set by 
the
user and don't touch it. LD_LIBRARY_PATH is not intended to be used in the way
it is used by some software, and truthfully we should bug people upstream 
about
these kind of issues and make sure they use the proper means for this, i.e.
DT_RUNPATH. Unfortunately though it's a matter of fact we need to live with.
So, the question is how to do this properly... again we have a few options:

3a. For each spell, look at the files installed by the spell and see if
LD_LIBRARY_PATH is set in any installed scripts. This is fickle though, 
because
we'd have to check for all kinds of scripts, and people could even be using
compiled programs for it. Secondly how do we determine the actual
LD_LIBRARY_PATH that is set by these scripts, without actually running the
script, this can become a mess fast.

3b. Somehow indicate the LD_LIBRARY_PATH needed (may be scriptable) in some QA
script/config in the spells that need it and adapt cleanse to use those
settings instead of using the massive LD_LIBRARY_PATH that it uses now.

This thing could be hiding other issues out there, so I think this is 
something
we should fix properly, and I'm for option 3b. The problem however is of 
course
that we'd need to do some work for the spells that need it...

Okay, enough preaching from me...

-- 
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.