[23561] in Athena Bugs
Re: linux 9.2.15: mozilla
daemon@ATHENA.MIT.EDU (Robert A Basch)
Mon Aug 11 16:26:42 2003
Date: Mon, 11 Aug 2003 16:26:40 -0400
Message-Id: <200308112026.h7BKQe2L026709@abulia.mit.edu>
From: Robert A Basch <rbasch@MIT.EDU>
To: Robert A Basch <rbasch@MIT.EDU>
CC: Camilla R Fox <cfox@MIT.EDU>, bugs@MIT.EDU
In-reply-to: "[23536] in Athena Bugs"
> Yes, this is broken; history.txt should not be used. I don't know
> what might have happened to cause this, but the problem does not occur
> when I build from the source tree and install to and run from a
> separate local directory.
I did some more investigation, and believe that I now understand the
problem, though I am not yet sure of the best way to deal with it.
history.txt is part of a separate implementation of the history
interface, available in the embed_lite component. That component
gets installed when you do "make install", but is omitted (along
with some other stuff) when you tar up a distribution file. Thus,
in the binary distribution downloadable from mozilla.org, the
components directory does not contain the embed_lite library.
When both embed_lite and appcomps (which contains the desired
history interface) are present, it looks like the last one read
wins, so that which one you get is determined by the directory
order. That explains the different behavior in the release and
my test installation.
The fix for this will involve some sort of change to the build
system, but I have not yet figured out which will be the least
painful. Possibilities include: tar'ing up a distribution, and
unpacking it into the appropriate DESTDIR target (would require some
path fudging, especially to get the SDK); figuring out how to apply
the relevant rule for distribution to "make install"; hacking the
Makefile so we don't install the embed_lite component.
