On Mon, 19 May 1997, Mark W. Eichin wrote:
Is there a web page or other document that explains what our strategy
for libc6 is? I'm not talking about random comments on the list, I
mean something nailed down that I can refer to...
In particular, I've got a few issues to work out.
1)
On Tue, 20 May 1997, Tom Lees wrote:
3) can I drop the a.out-only dlltools package now? :-)
No. It is needed to build a.out versions of, e.g. svgalib. Some older
binary-only programs only come in a.out format (Doom, for example) :(.
Yes, it can be dropped _(;
1/ Doom comes without
No. xlib6 should be for libc6 (more long-term solution). Then create an
xlib6-libc5. How we handle the dependencies for this, I don't know. Fix
But then anyone upgrading xlib6 (the 6 for x11r6, not libc6!) will
end up with a libc6 version; Is that what we want to happen?
alt-xlib6-dev that
1/ Doom comes without any source, so dlltools won't be of any use.
Irrelevant -- *aout-svgalib* is what needs dlltools, not doom itself.
Debian still support a.out executables _execution_ but not a.out
_development_ anymore...
I guess I could believe that as long as the a.out development
Is there a web page or other document that explains what our strategy
for libc6 is? I'm not talking about random comments on the list, I
mean something nailed down that I can refer to...
In particular, I've got a few issues to work out.
1) libgdbm -- libc6 includes libdb, and therefore
On May 19, Mark W. Eichin wrote
Is there a web page or other document that explains what our strategy
for libc6 is? I'm not talking about random comments on the list, I
mean something nailed down that I can refer to...
yes, we need that !
1) libgdbm -- libc6 includes libdb, and
IIRC libgdbm is no longer developed, because even the author saw that
libdb was better, and that there was no reason for double work.
Nice theory; however, db can't read gdbm files, nor does it provide
the gnu-specific version of the interface... so the existing gdbm
will be needed provided
7 matches
Mail list logo
