I've investigated this problem some more, and I am getting convinced
that the problem is this code in
ooo-build-3-2-0-9/patches/dev300/nsplugin-path.diff, which is
unprepared for a relative symlink:
# define SEARCH_SUFFIX "/program/libnpsoplug"
if (!(clobber = strstr (libFileName, SEARCH_SUFFIX)))
{
ssize_t len = readlink(libFileName, realFileName, NPP_PATH_MAX-1);
if (len == -1)
{
fprintf (stderr, "Couldn't read link '%s'\n", libFileName);
return 1;
}
realFileName[len] = '\0';
if (!(clobber = strstr (realFileName, SEARCH_SUFFIX)))
{
fprintf (stderr, "Couldn't find suffix in '%s'\n", realFileName);
return 1;
}
*clobber = '\0';
}
This is the link in question:
tjener:~# ls -l /usr/lib/mozilla/plugins/libnpsoplugin.so
lrwxrwxrwx 1 root root 41 14 feb. 10:11
/usr/lib/mozilla/plugins/libnpsoplugin.so ->
../../openoffice/program/libnpsoplugin.so
tjener:~#
I see two solutions to this problem. Either make the code capable of
handling relative symlinks. It can be done by using realpath() or
canonicalize_file_name() (GNU extention) instead of readlink. Or by
making the symlink absolute. I believe it is best to make the code
more robust and able to handle relative symlinks.
The code I found to create this symlink is this fragment in
debian/rules:
cd debian/mozilla-openoffice.org$(VER) && \
for b in iceape iceweasel mozilla mozilla-firefox firefox; do \
mkdir -p usr/lib/$$b/plugins && \
ln -sf /$(OOBRANDDIR)/program/libnpsoplugin.so \
usr/lib/$$b/plugins/libnpsoplugin.so; \
done
It seem to create absolute symlinks, so I am not quite sure what is
going on here. I checked the symlink on a Squeeze system.
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
