On Thursday 25 February 2010 06:19:26 pm Matt Taggart wrote:
> > Well, I don't see why they do the rpath thingy. "-lextractor" should be
> > all that is needed. Now, if fossology internally messes with libltdl's
> > lt_dlsetsearchpath and somehow removes the entries added by libextractor.
> > That *would* cause trouble for LE finding its plugins (which could be in
> > turn
> >
> > worked around using rpath; however, removing existing entries from the
> > lt_dlsearchpath is then the real issue that should be resolved if
> > possible).
> >
> > The ChangeLog of the Makefile suggest that they were trying to resolve a
> > problem with plugins not being found. Now, I don't know under which
> > conditions and when that problem occurred, but the fix using rpath is
> > certainly not what I would recommend -- it should not be needed. So if
> > you ca n
> > find out what breaks and why if the rpath is removed, that'd be better.
>
> Hi Christian,
>
> I just learned that Fedora ran into this bug as well
>
> https://bugzilla.redhat.com/show_bug.cgi?id=452504
>
> and here is the patch they used to fix it
>
> http://tinyurl.com/ylkehu6
>
> What do you think? If you agree the problem is in libextractor I'll
> transfer the Debian bug there.
Hi!
Looking at that patch, I'm not even sure HOW it fixes the problem :-(. Here
is how it primarily should work:
configure decides to put the plugins somewhere, like typically
"/usr/lib/libextractor/". Then, when 'make' is run, it gives the following
arguments to gcc (in Extractor/src/main/):
make[1]: Entering directory `/home/grothoff/svn/Extractor/src/main'
/bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -
I../.. -I../../src/include -DPLUGINDIR=\"libextractor\" -
DPLUGININSTDIR=\"/usr/lib/libextractor\" -fno-strict-aliasing -g -Wall -
Werror -O0 -MT libextractor_la-extractor.lo -MD -MP -MF .deps/libextractor_la-
extractor.Tpo -c -o libextractor_la-extractor.lo `test -f 'extractor.c' ||
echo './'`extractor.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/include -
DPLUGINDIR=\"libextractor\" -DPLUGININSTDIR=\"/usr/lib/libextractor\" -fno-
strict-aliasing -g -Wall -Werror -O0 -MT libextractor_la-extractor.lo -MD -MP
-MF .deps/libextractor_la-extractor.Tpo -c extractor.c -fPIC -DPIC -o
.libs/libextractor_la-extractor.o
Note the "-DPLUGININSTDIR" which #define's PLUGININSTDIR. The library then
primarily and first tries to find plugins in that path. Various alternative
strategies may be tried also, but this is what should work (especially if
nobody decided to move binaries around the file system...). What I do know is
that the current code's OTHER plugin path determination methods (see my
previous e-mail) do not really support auto-detection with library directories
called "lib64/", they expect simply "lib/", but that does not seem to be the
issue on Debian anyway.
So what I would like to know first (wrt to the Debian issue):
1) On setups where fossology doesn't work, does the "extract" binary work?
=> If "extract" works, fossology must be doing something to the search
path and we can blame fossology and the problem has nothing to do
with the RedHat bug and this is also not an LE package bug.
2) Assuming "extract" does not work, what were the 'gcc' arguments when
'extractor.c' was compiled? Is the path the same as where the plugins
are?
=> If not, why not? If there is a good reason for relocation, then we have
to look at which of the other heuristics fails. But if (using chroot,
etc.) we can make the paths match, we're done (and this was an LE
package bug)
3) If the path matched AND the plugins are still not found, or if the
other heuristics are insufficient (in combination with relocation of the
library after compilation due to package management), then we have
an upstream issue and looking at an "strace" might be useful, even though
I'd probably prefer a gdb run looking at each of the heuristic functions
that are called to see which paths they generate (and compare with what we
might want them to do). But last time I tried the Debian package already
(1) was not true (extract binary worked!), so I somehow doubt we will
end up here.
My 2 cents
Christian
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
