Re: ncurses & libc6
> > I was thinking about building ncurses 4.1 with libc6 when I saw > this file : > > README.glibc > > To compile this as an add-on for glibc, unpack it in the glibc source > tree and put ncurses on the add-on list when you do configure. > > [EMAIL PROTECTED] > 03/21/1997 > > > So it seems possible to compile libc6 and ncurses as a whole. > As libncurses is outdated and needs to be recompiled for libc6 why not use > this possibility ? > > David what do you think about this ? > > > Note : please CC mails about this to me, I'm not subscribed to the list. > Hello, I'm the new libc5 & libc6 maintainer. It is possible to include ncurses in the libc6 packages, but it is not much easier to compile using the glibc source tree than doing without. I contacted the ncurses maintainer, Michael Alan Dorman, last weekend and he promised to have a new package out RSN. Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
top and window resizing
Sam Ockman <[EMAIL PROTECTED]> wrote (in the thread on ncurses):
>: Now that I think about it, the program "top" is another offender that it
>: would be nice to figure out someway to make it so the xterm-window can
>: resize it.)
Well, it surely works for me (I wrote most of the currently used code
in top). top does a resize when it gets a SIGWINCH, which is what
xterm should send to it via the shell.
Could you please specify your problems?
Helmut
--
Helmut Geyer[EMAIL PROTECTED]
public PGP key available : finger [EMAIL PROTECTED]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 utmp and wtmp [Was: Re: official C library]
Miquel van Smoorenburg: > In article <[EMAIL PROTECTED]>, > Johnie Ingram <[EMAIL PROTECTED]> wrote: > > > >Am I correct in thinking the major players to be synchronized here are > >shellutils (who), sysvinit (last), netstd (rsh), login, ppp, procps, > >wu-ftpd, and ssh? > > Well, if the program that uses utmp is wellbehaved and uses getutent() > and friends, we could put a libc6-utmp emulation in libc5. > > Then you just let libc6 conflict with libc5 <= 5.4.23-6 so that installing > libc6 forces an install of a libc5 with the emulation layer. > > There are some programs though that read/write utmp not using the > library interface. Usually you can find them by running strings on the > program and checking for /var/run/utmp. > > I don't know what to do about those, but they should be fixed for libc6 > anyway so maybe we can fix them, recompile for libc5 and put them in > Debian-1.3.x. The programs that write to utmp are the worst, those are > probably just > > getty, in.rlogind, in.telnetd, pppd, sshd, rxvt, sessreg > [..] Well I have done a utmp wrapper for libc5 and am currently testing it. I was very reluctant to release it without heavy testing to unstable but it should appear this weekend on master. This changes the libc utmp functions. glibc 2.1.x will have a utmp daemon that monitors accesses to utmp and serves both old and new utmp formats. Until then we have to be careful of those bad behaved programs that access utmp directly. BTW, the same is true for lastlog but wihtout the benefit of existing libc functinos to access it. Please take a look at my release notice when they're available. Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: problem with /proc info
> Could anyone explain this to me? > > cat /proc/meminfo > total:used:free: shared: buffers: cached: > Mem: 96813056 95010816 1802240 122679296 11886592 37617664 > Swap: 65798144 229376 65568768 > MemTotal: 94544 kB<== > MemFree: 1760 kB > MemShared: 119804 kB<== > Buffers: 11608 kB > Cached: 36736 kB > SwapTotal:64256 kB > SwapFree: 64032 kB > Ganz einfach! Im Gegnsatz zu fruehen Linux-versionen (unter 1.2) ist MemShared _nicht_ der physikalische Speicher, der von Seiten belegt wird, die "shared" sind, sondern der Speicher der Durch das "sharen" gespart wird. in arch/i386/mm/init.c wird in si_meminfo fuer jede Seite einfach pagesize*(pagecount-1) zur Summe addiert. Wenn man dort folgenden Patch einfuegt, bekommst Du das, was Du willst: statt val->sharedram += mem_map[i].count - 1; folgendes einfuegen: if (mem_map[i].count>1) val->sharedram ++; (fuer 2.1 bitte noch atomic_reads einfuegen). Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: problem with /proc info
I'm sorry this wasn't meant to go to the list. The main point was that MemShared is counting the amount of memory spared by the use of shared pages, not the number of pages with a reference count greater than 1 (which corresponds to the physical memory/swap occupied by shared pages). Helmut -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New libc5 (5.4.33-2) for unstable - READ THIS BEFORE INSTALLING IT
Update on the packages I checked: ssh does _not_ use the libc functions when compiled with libc5. So ssh will corrupt the utmp file if used with hamm. Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6
> On Jun 11, Guy Maor wrote > > > I'm working on the xdaliclock package, and I will take it to libc6. I > > > have merely recompiled it, and all has worked fine, except perhaps some > > > warning (perhaps present with libc5: I have not installed alt-libc5 as > > > yet). This is suspect to me, because my X libs are compiled with libc5, > > > and in this list I've read that ncurses (simpler than X libs) give > > > problems with libc6 in compile time. Perhaps I'dont have understand well > > > the problem: can you explain it to me? > > > > Maybe I misunderstand, but it sounds like you're trying to compile a > > binary against libc5 versions of some libraries and libc6 versions of > > others. That will never work. > > No. The surprising thing is that it _does_ work. (e.g. take the DDD source > in a libc6 environment, with libc6 libg++272, libc5 ncurses, X etc. It > compiles and works). The problem is that there could be subtle problems from > the interaction between libc5 and libc6 libraries, which may be very > difficult to track. This means that maintainers who work in a libc6 > environment must check very carefully that all the libraries they link > against are really for use with libc6. > H.J. Lu and the XFree86 team did a lot of work to make this work. whether it works perfectly, I don't know but as X uses its own datatypes for most things one of the main problems of incompatibility between libc5 and libc6 is not present. Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: posix time / 822-date problem
Guy Maor <[EMAIL PROTECTED]> writes: > Andreas Jellinghaus <[EMAIL PROTECTED]> writes: > > > thank you. i had timezones 2.03 installed (is that related to glibc ?). > > removing it and re-installing timezone helped. > > Yes, but timezones should be using POSIX time by default, not right > time! Helmut, is it not? > Well it is. The problem is probably the backup of an old timezone package that will generate a /usr/lib/zoneinfo/localtime file when removed without purging. This file is read by all libc5 programs before /etc/localtime. removing it should make 822-date work again. I'll check for this file in the next package and remove it, if present. Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: thread support
Guenter Geiger <[EMAIL PROTECTED]> writes: > I am rather new to this list, so excuse me if this question has > already been dealt with. > > > Will there be kernel level thread support for Debian ? > > The Linuxthreads package from Xavier Leroy is a very good Thread > Library supporting Posix threads. In order to develop threaded > applications there should be some changes in different packages: > > - the libpthread0 packages comes without header files ! > > - libraries should be compiled reentrant > > This sounds like a big job, will it be worth it ? > According to the linuxthreads FAQ no distribution currently supports > reentrant libraries ( Xlib is very critical about that ) > The linuxthreads package is part of the libc6 packages, as it is an add-on to glibc 2. As the new libraray handles threads much better than libc5, you should base all work intended to do threading on libc6. Our aim for Debian 2.0 is to provide all libs as reentrant. It usually isn't enough just to compile it with -D_REENTRANT. You have to avoid static and global variables and do some mutex locking. XFree86 3.3. supports reentrant libraries when based on libc6. Helmut (Debian libc maintainer) -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Exim + Chos standard?
Christoph Lameter: > > Also we might think about replacing lilo with chos as the standard boot > loader from harddisk. lilo always is a difficulty for newbies, chos > offers: > > - Menudriven Boot Loader (Cryptic Prompt only on demand) > - Highly Customizable Color Menus. > - Simple configuration in passwd style file /etc/chos.conf > But chos can't yet load bzImages. The usptream maintainer promised me to look into it, so maybe it soon can. Until then, however, lilo should be the standard. Once it can, we max talk about it again. Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RFC: libc6 policy supplement 2nd try
Here is a reworked proposal:
-=-=-=-=-=-=-=-=-=-=-= SNIP -=-=-=-=-=-=-=-=-=-=-=-=-=-
Debian library policy supplement draft for libc5->libc6 migration
This document is meant to tell what a Debian package providing a
library should do to support both libc6 (glibc2) and libc5.
Note that these requirements are for Debian 2.0 (codename hamm).
Contents
1. Run time packages
2. Development packages
3. Requirements on libraries for Debian 2.0
4. Requirements on compiler packages
1. Run time packages
A package providing a shared library has to support both C library
packages, libc5 and libc6 based libraries. This must be done using
two Debian packages, each depending on the correct C library
package.
The package naming convention currently suggests to name these
packages as follows [1]. Some packages (mostly from base) may use
locations in /lib.
based on | package name | library location
libc6 | libfoo | /usr/lib/libfoo.so.
libc5 | libfoo-g | /usr/lib/libc5-compat/libfoo.so. [2]
If a library runtime package contains files that are needed by
both versions of the library, a new package should be made for
just these files that both other packages depend on.
This package naming convention does _not_ apply if a package uses
different sonames for libc5 and libc6 based packages
There are two exceptions from this rule. The shared linker
ld-linux.so.1 and the C library files libc.so.5 and libm.so.5
should still be located in /lib, not in /lib/libc5-compat.
Packages based on X have to use /usr/X11R6 as prefix, not /usr.
Note that the X libraries are designed to work with both C libraries.
2. Development packages
The Debian policy requires that all files needed for compiling/linking
other packages with the library are in a separate package, the
development package. Up to now this package simply was called
libfoo-dev. As packages based on libc5 and libc6 usually cannot
use the same development files there has to be a clear statement
how to separate these. So for now the following packages are
required:
based on | package name| hierarchy locations
---
libc6 | libfoo-dev | /usr/{lib,include}
libc5 | libfoo-g-altdev | /usr/i486-linuxlibc1/{lib,include}
Note that the choice to base Debian 2.0 on libc6 fixed the fact
that the main locations will be used for libc6 packages. The
alternate locations are used for libc5 based packages.
This decision does not necessarily mean that by default the
compiler uses the libc6 packages, please read section 4 for more
information. Using a four-way approach for library locations
(standard and alternate locations for libc6 and libc5 based
packages) will make Debian systems inconsistent with each other,
something we should avoid at (nearly) all costs.
3. Requirements on libraries for Debian 2.0
Libraries (regardless of which library they're compiled against) need
to have runtime dependencies on one of libc, libdl or libm to enable
the shared linker to determin which library to use for a binary.
In general we want libraries compiled for libc6 to be thread-safe.
This means that the following changes must be made to the library
packages:
- compile the library using -D_RENTRANT or -D_THREAD_SAFE
- there may be no permanent data residing in the library memory that
can be different for different threads.
this means in the first place no static or global variables that
are not in some way protected from access by a different threads.
- all write access to files from a library must be both protected
using some file locking mechanism in addition to using mutexes.
- library functions must be protected from being used at the same
time by two threads sharing the same memory space. This is done
using mutexes.
As these usually are all nontrivial changes to a library if it isn't
thread-safe already (in which case just using -D_RENTRANT should
be used in addition to whatever the library uses to support threads),
I suggest that noone starts doing this without getting in contact with
the upstream maintainer(s).
There will be a list available that lists all libraries part of
Debian and their current status regarding compliance with these
standard requirements. This list will be posted regularly to
debian-devel by Helmut Geyer <[EMAIL PROTECTED]>.
4. Requirements on compiler packages
The compiler and binutils packages have to provide working
development environments for both C libraries. Basically (that is
from the compiler standpoint) there is no real difference between
the two environments,
ftp problems to master
Hello! Currently it is impossible to ftp to master (even when logged in at master). All connections on port 21 are rejected. Could someone please look at it? Thanks, Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RFC: library conventions for libc5 and libc6 in hamm Take 3
ed in addition to whatever the library uses to support threads),
I suggest that noone starts doing this without getting in contact with
the upstream maintainer(s).
If a library has a thread-safe version, the debian package should
use this. The performance deficits usually are very small when not
linking to libpthreads so only if there are serious reasons, the
debian package may include the non-thread-safe version.
There will be a list available that lists all libraries part of
Debian and their current status regarding compliance with these
standard requirements. This list will be posted regularly to
debian-devel by Helmut Geyer <[EMAIL PROTECTED]>.
4. Requirements on compiler packages
The compiler and binutils packages have to provide working
development environments for both C libraries. Basically (that is
from the compiler standpoint) there is no real difference between
the two environments, only some paths and automatic definitions
have to be changed. All this can be done (and is in fact done) by
supplying a different specs file in a different location.
The gcc packages do this as follows:
The gcc package uses libc6 by default and is installed in /usr/bin.
The alt-gcc package uses libc5 by default and is located in
/usr/i486-linuxlibc1/bin. By prepending this to the path this can
be made the default.
These requirements are fulfilled by the current gcc packages.
Remarks:
[1] the name of a library package often includes the major version
number of the library. If so, the 'g' should come before this
number, e.g. libgdbmg1 as package name for the libc6 based
runtime package for libgdbm.
[2] The location ../libc5-compat was introduced in the ldso package. As
ldso is a package on all linus distributions we'll keep it for
compatibility with other distributons even though
/usr/i486-linuxlibc1/lib would be more consistent.
--
Helmut Geyer[EMAIL PROTECTED]
public PGP key available : finger [EMAIL PROTECTED]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: locale errors
Michael Meskes <[EMAIL PROTECTED]> writes:
> No! You cannot use libc5 compiled perl with glibc locales! Wait for a
> libc6 version of perl and everything should be fine again.
>
Yes, you can (at least I'm having no trouble at all whenusing glibc
2.0.4-1 and locales 2.0.4-1). _Please_ try these packages before
reporting another bug on locales. I'm simply not seeing them.
Helmut
--
Helmut Geyer[EMAIL PROTECTED]
public PGP key available : finger [EMAIL PROTECTED]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian target audience
Alex Yukhimets <[EMAIL PROTECTED]> writes: > > > The problem of having both libc5 and libc6 run-time libraries is minor, > > > the main one is that those stuck with libc5-dev cannot use other > > > newly-available versions of *libraries* from hamm. > > > > How do you mean? You can install the *libraries* just fine, it's just > > the development versions that fail to install. > > That's exactly what I meant, sorry if it wasn't clear. > > > > > And even then, why not install lib5-altdev? Then there is no problem > > whatsoever. > > > > I am sorry to say, but you are wrong. Even on this list there were > several postings regarding this matter. There are several known > problems and who knows how many unknown. You just can't afford to > experiment with "production" system this way. Anyway, I could take some > burden on myself to compile libc5 counterparts, but on my 486DX2/66 with > 2k/sec connection it would take years. > Nearly all of the problems mentioned here are _not_ problems with the -altdev packages but with the transition period while not all packages use this standard. There is a single problem with utmp, that will cause buggy (!) programs to have problems, i.e. programs that do _not_ use the C library functions to access utmp. Other than that there was the locale problem that has been fixed (at least for me) using libc 5.4.33 and glibc 2.0.4. For me these are not enough reasons to support a stable tree for libc5-only when we have fixed our transition problems fro hamm. Furthermore it is _far_ too early to talk about what we'll be doing when hamm is released as we first have to see how many problems there will be with a hamm system (currently there are next to no packages using the hamm conventions). Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: locale errors
Michael Meskes <[EMAIL PROTECTED]> writes:
> I'm sorry Helmut, but:
>
> gauss:meskes 124) dpkg -l libc5\* libc6\* locale\* perl\* | grep ii
> ii libc5 5.4.33-4 The Linux C library version 5
> (run-time libr
> ii libc5-altdev5.4.33-4 The Linux C library version 5
> (alternative d
> ii libc6 2.0.4-1The GNU C library version 2 (run-time
> files)
> ii libc6-dev 2.0.4-1The GNU C library version 2
> (development fil
> ii libc6-doc 2.0.4-1The GNU C library version 2
> (documentation f
> ii locales 2.0.4-1Locale data files and utilities.
> ii perl5.004-1Larry Wall's Practical Extracting and
> Report
> ii perl-curses 1.01-1 Curses interface for Perl
> ii perl-debug 5.004-1Allow debugging perl scripts (and
> perl).
> ii perl-suid 5.004-1Runs setuid perl scripts.
> ii perl-tk 400.202-2 Perl module providing the Tk graphics
> librar
> ii perlmagick 1.11-1 A perl interface to the libMagick
> graphics r
> ii perlmenu4.0-1 Menu and Template (curses-based) UI
> for Perl
> gauss:meskes 125) cat t
> #!/usr/bin/perl
>
> print "Hello World\n";
> gauss:meskes 126) ./t
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LC_ALL = "de_DE",
> LANG = (unset)
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> Hello World
>
> I would have expected this to work (once again libc5 locale support was
> taken from glibc) but apparently it doesn't.
> Do oyu have any idea where to look?
>
I will look into this mnore carefully tonight. If I can reproduce the
problem, I'll try to fix it. If I can't I'll tell you where you might
look for the problem.
Helmut
--
Helmut Geyer[EMAIL PROTECTED]
public PGP key available : finger [EMAIL PROTECTED]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
locale errors found & fixed
Well,
open mouth extract foot,..
When doing a complete reinstall of all involved packages,
I finally found out that I had a messed up locale directory. So
everything would work for me, but not for anyone else :(
So here's the problem: libc6 and libc5 use different magic numbers for
their locale files. These are defined in locale/localeinfo.h in the
libc source tree:
in libc5:
#define LIMAGIC(category) (0x960316de ^ (category))
in libc6:
#define LIMAGIC(category) (0x960617de ^ (category))
So of course it couldn't work. This is, however, very easy to fix.
I'll make a fixup release of the hamm libc5 packages and you should be
able to enjoy(?) all kind of messages in your native language.
Helmut
--
Helmut Geyer[EMAIL PROTECTED]
public PGP key available : finger [EMAIL PROTECTED]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
More locale problems for libc5 & libc6
Well, there really are some strange problems with the locales 2.0.4-1
package. Strangely some of the compiled locale files use the old
format, some the new one. I really cannot understand how this
happened, but it did.
All people having problems with locales should run the included
script. This will make some problems disappear. The libc5 I will
release tomorrow for hamm will understand these locale files (though
the current 5.4.33-4 doesn't). This should, however, fix some problems
with libc6 and locales. Anyone who had problems with libc6 programs
and locale settings, please try this and get back to me whether this
helped.
Helmut
#!/bin/bash
function do_locale {
localedef -c -i /usr/share/i18n/locales/$1 \
-f /usr/share/i18n/charmaps/$2 $1 ;
}
do_locale da_DK ISO-8859-1
do_locale de_AT ISO-8859-1
do_locale de_BE ISO-8859-1
do_locale de_CH ISO-8859-1
do_locale de_DE ISO-8859-1
do_locale de_LU ISO-8859-1
do_locale en_CA ISO-8859-1
do_locale en_DK ISO-8859-1
do_locale en_GB ISO-8859-1
do_locale en_IE ISO-8859-1
do_locale en_US ISO-8859-1
do_locale es_ES ISO-8859-1
do_locale et_EE ISO-8859-1
do_locale fi_FI ISO-8859-1
do_locale fo_FO ISO-8859-1
do_locale fr_BE ISO-8859-1
do_locale fr_CA ISO-8859-1
do_locale fr_CH ISO-8859-1
do_locale fr_FR ISO-8859-1
do_locale fr_LU ISO-8859-1
do_locale gr_GR ISO-8859-7
do_locale hr_HR ISO-8859-4
do_locale hu_HU ISO-8859-2
do_locale is_IS ISO-8859-1
do_locale it_IT ISO-8859-1
do_locale iw_IL ISO-8859-8
do_locale kl_GL ISO-8859-1
do_locale lt_LT BALTIC
do_locale lv_LV BALTIC
do_locale nl_BE ISO-8859-1
do_locale nl_NL ISO-8859-1
do_locale no_NO ISO-8859-1
do_locale pl_PL ISO-8859-2
do_locale pt_PT ISO-8859-1
do_locale ro_RO ISO-8859-1
do_locale ru_RU ISO-8859-5
do_locale sl_SI ISO-8859-2
do_locale sv_FI ISO-8859-1
do_locale sv_SE ISO-8859-1
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
RFC: library conventions for libc5 and libc6 in hamm Take 4
shared linker to determin which library to use for a binary. These runtime dependencies are _NOT_ dependencies in the Debian way, but dependencies generated by the linker when generating the shared library. See the binutils manual for more information. In general we want libraries compiled for libc6 to be thread-safe. This is, however, not practical or feasible for every library package. Making a library thread-safe involves quite a lot of work, much of it nontivial. Thread-safe means that the following changes must be made to the library packages: - compile the library using -D_RENTRANT or -D_THREAD_SAFE - there may be no permanent data residing in the library memory that can be different for different threads. this means in the first place no static or global variables that are not in some way protected from access by a different threads via mutexes. - all write access to files from a library must be both protected using some file locking mechanism in addition to using mutexes. - at least some library functions must be protected from being used at the same time by two threads sharing the same memory space. This is done using mutexes. As these usually are all nontrivial changes to a library if it isn't thread-safe already (in which case just using -D_RENTRANT should be used in addition to whatever the library uses to support threads), I suggest that noone starts doing this without getting in contact with the upstream maintainer(s). If a library has a thread-safe version, the debian package should use this. The performance deficits usually are very small when not linking to libpthreads so only if there are serious reasons, the debian package may include the non-thread-safe version. There will be a list available that lists all libraries part of Debian and their current status regarding compliance with these standard requirements. This list will be posted regularly to debian-devel by Helmut Geyer <[EMAIL PROTECTED]>. 5. Conflicts & Dependencies for hamm packages The libfoog package _has_ to conflict with all versions of the libfoo package before it was made to use the libc5-compat directory. Furthemore it should depend on libc6. The libfoog-dev package must depend on libc6-dev and the libfoog package of the same release. It has to conflict with the libfoo-dev package. The hamm libfoo package has to depend on libc6 and has to conflict with libfoo-dev and libc5-dev. The libfoo-altdev package has to depend on the libc5-altdev and libfoo package of the same release. 6. Handling bugfixes for Debian 1.3 (bo) Using the dependencies from Section 5. there will be problems with making bugfix releases for bo. These have to be handled carefully as otherwise there may be tremendous problems for people using hamm systems. As there is one package name used for both hamm and bo that stays the same (libfoo), we have to very careful. The following steps should be followed: i) when making a bo bugfix release, be sure to make a hamm release at the same time, using a higher release number for the hamm release. Update the hamm package's conflicts according to section 5. ii) Any bo package for libfoo _has_ to conflict with libc6, libfoo-altdev and libfoog. iii)The libfoo-dev package has to conflict with libc5-altdev and has to depend on libc5-dev. 7. Requirements on compiler packages The compiler and binutils packages have to provide working development environments for both C libraries. Basically (that is from the compiler standpoint) there is no real difference between the two environments, only some paths and automatic definitions have to be changed. All this can be done (and is in fact done) by supplying a different specs file in a different location. The gcc packages do this as follows: The gcc package uses libc6 by default and is installed in /usr/bin. The alt-gcc package uses libc5 by default and is located in /usr/i486-linuxlibc1/bin. By prepending this to the path this can be made the default. These requirements are fulfilled by the current gcc packages. Remarks: [1] the name of a library package often includes the major version number of the library. If so, the 'g' should come before this number, e.g. libgdbmg1 as package name for the libc6 based runtime package for libgdbm. [2] The location ../libc5-compat was introduced in the ldso package. As ldso is a package on all linus distributions we'll keep it for compatibility with other distributons even though /usr/i486-linuxlibc1/lib would be more consistent. [3] An example for relevant sections of the changelogs for a bugfix release for both bo and hamm (with the last bo release being libfoo 1.7.
RFC: library conventions for libc5 and libc6 in hamm Take 4
shared linker to determin which library to use for a binary. These runtime dependencies are _NOT_ dependencies in the Debian way, but dependencies generated by the linker when generating the shared library. See the binutils manual for more information. In general we want libraries compiled for libc6 to be thread-safe. This is, however, not practical or feasible for every library package. Making a library thread-safe involves quite a lot of work, much of it nontivial. Thread-safe means that the following changes must be made to the library packages: - compile the library using -D_RENTRANT or -D_THREAD_SAFE - there may be no permanent data residing in the library memory that can be different for different threads. this means in the first place no static or global variables that are not in some way protected from access by a different threads via mutexes. - all write access to files from a library must be both protected using some file locking mechanism in addition to using mutexes. - at least some library functions must be protected from being used at the same time by two threads sharing the same memory space. This is done using mutexes. As these usually are all nontrivial changes to a library if it isn't thread-safe already (in which case just using -D_RENTRANT should be used in addition to whatever the library uses to support threads), I suggest that noone starts doing this without getting in contact with the upstream maintainer(s). If a library has a thread-safe version, the debian package should use this. The performance deficits usually are very small when not linking to libpthreads so only if there are serious reasons, the debian package may include the non-thread-safe version. There will be a list available that lists all libraries part of Debian and their current status regarding compliance with these standard requirements. This list will be posted regularly to debian-devel by Helmut Geyer <[EMAIL PROTECTED]>. 5. Conflicts & Dependencies for hamm packages The libfoog package _has_ to conflict with all versions of the libfoo package before it was made to use the libc5-compat directory. Furthemore it should depend on libc6. The libfoog-dev package must depend on libc6-dev and the libfoog package of the same release. It has to conflict with the libfoo-dev package. The hamm libfoo package has to depend on libc6 and has to conflict with libfoo-dev and libc5-dev. The libfoo-altdev package has to depend on the libc5-altdev and libfoo package of the same release. 6. Handling bugfixes for Debian 1.3 (bo) Using the dependencies from Section 5. there will be problems with making bugfix releases for bo. These have to be handled carefully as otherwise there may be tremendous problems for people using hamm systems. As there is one package name used for both hamm and bo that stays the same (libfoo), we have to very careful. The following steps should be followed: i) when making a bo bugfix release, be sure to make a hamm release at the same time, using a higher release number for the hamm release. Update the hamm package's conflicts according to section 5. ii) Any bo package for libfoo _has_ to conflict with libc6, libfoo-altdev and libfoog. iii)The libfoo-dev package has to conflict with libc5-altdev and has to depend on libc5-dev. 7. Requirements on compiler packages The compiler and binutils packages have to provide working development environments for both C libraries. Basically (that is from the compiler standpoint) there is no real difference between the two environments, only some paths and automatic definitions have to be changed. All this can be done (and is in fact done) by supplying a different specs file in a different location. The gcc packages do this as follows: The gcc package uses libc6 by default and is installed in /usr/bin. The alt-gcc package uses libc5 by default and is located in /usr/i486-linuxlibc1/bin. By prepending this to the path this can be made the default. These requirements are fulfilled by the current gcc packages. Remarks: [1] the name of a library package often includes the major version number of the library. If so, the 'g' should come before this number, e.g. libgdbmg1 as package name for the libc6 based runtime package for libgdbm. [2] The location ../libc5-compat was introduced in the ldso package. As ldso is a package on all linus distributions we'll keep it for compatibility with other distributons even though /usr/i486-linuxlibc1/lib would be more consistent. [3] An example for relevant sections of the changelogs for a bugfix release for both bo and hamm (with the last bo release being libfoo 1.7.
Re: RFC: library conventions for libc5 and libc6 in hamm Take 4
[EMAIL PROTECTED] (joost witteveen) writes: > > 5. Conflicts & Dependencies for hamm packages > > > [..] > > > >The hamm libfoo package has to depend on libc6 and has to conflict > >with libfoo-dev and libc5-dev. > > Are you sure here? I'd say you mean this: > > The hamm libfoo package has to depend on libc5 and has to conflict > with libfoo-dev. > > - libfoo is libc5, so it should depend on libc5. > - Yes, we should try and get rid of libc5-dev, but I'm not sure it's > the job of random libries to force users to do that: as far as > I can see, nothing breaks when the two are installed together. > OK I will change the libc6 dependecy. However we must not have any -dev package in hamm that is a libc5-based package, i.e. libc5-dev may not be installed on a hamm system. It will break lots of stuff. Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RFC: conventions for libc5 and libc6 based library packages in hamm
o be thread-safe. This is, however, not practical or feasible for every library package. Making a library thread-safe involves quite a lot of work, much of it nontivial. Thread-safe means that the following changes must be made to the library packages: - compile the library using -D_RENTRANT or -D_THREAD_SAFE - there may be no permanent data residing in the library memory that can be different for different threads. this means in the first place no static or global variables that are not in some way protected from access by a different threads via mutexes. - all write access to files from a library must be both protected using some file locking mechanism in addition to using mutexes. - at least some library functions must be protected from being used at the same time by two threads sharing the same memory space. This is done using mutexes. As these usually are all nontrivial changes to a library if it isn't thread-safe already (in which case just using -D_RENTRANT should be used in addition to whatever the library uses to support threads), I suggest that noone starts doing this without getting in contact with the upstream maintainer(s). If a library has a thread-safe version, the debian package should use this. The performance deficits usually are very small when not linking to libpthreads so only if there are serious reasons, the debian package may include the non-thread-safe version. There will be a list available that lists all libraries part of Debian and their current status regarding compliance with these standard requirements. This list will be posted regularly to debian-devel by Helmut Geyer <[EMAIL PROTECTED]>. 5. Conflicts & Dependencies for hamm packages The libfoog package _has_ to conflict with all versions of the libfoo package before it was made to use the libc5-compat directory. Furthemore it should depend on libc6. The libfoog-dev package must depend on libc6-dev and the libfoog package of the same release. It has to conflict with the libfoo-dev package. The hamm libfoo package has to depend on libc5 and has to conflict with libfoo-dev. The libfoo-altdev package has to depend on the libfoo package of the same release and on libc5-altdev. 6. Handling bugfixes for Debian 1.3 (bo) Using the dependencies from Section 5. there will be problems with making bugfix releases for bo. These have to be handled carefully as otherwise there may be tremendous problems for people using hamm systems. As there is one package name used for both hamm and bo that stays the same (libfoo), we have to very careful. The following steps should be followed: i) when making a bo bugfix release, be sure to make a hamm release at the same time, using a higher release number for the hamm release. Update the hamm package's conflicts according to section 5. ii) Any newly uploaded bo package for libfoo _has_ to conflict with libc6, libfoo-altdev and libfoog. [3] iii)Any newly uploaded libfoo-dev package for bo has to depend on libc5-dev. As libc5-altdev conflicts with libc5-dev this will automatically make sure this apckage is not used on a hamm system. 7. Requirements on compiler packages The compiler and binutils packages have to provide working development environments for both C libraries. Basically (that is from the compiler standpoint) there is no real difference between the two environments, only some paths and automatic definitions have to be changed. All this can be done (and is in fact done) by supplying a different specs file in a different location. The gcc packages do this as follows: The gcc package uses libc6 by default and is installed in /usr/bin. The alt-gcc package uses libc5 by default and is located in /usr/i486-linuxlibc1/bin. By prepending this to the path this can be made the default. These requirements are fulfilled by the current gcc packages. Remarks: [1] the name of a library package often includes the major version number of the library. If so, the 'g' should come before this number, e.g. libgdbmg1 as package name for the libc6 based runtime package for libgdbm. [2] The location ../libc5-compat was introduced in the ldso package. As ldso is a package on all Linux distributions we'll keep it for compatibility with other distributons even though /usr/i486-linuxlibc1/lib would be more consistent. [3] The point is that a package submitted to bo which has a higher revision number may not be used in hamm. So any package that has a hamm release with a smaller release number has to conflict with libc6 and the rest mentioned. [4] An example for relevant sections of the changelogs for a bugfix release for both bo an
Re: NIS and libc6/hamm?
> > Hi! > > Can someone tell me if NIS is working in the current "hamm" release? > (Someone here mentioned that it is not, so I want to know for sure before > I upgrade my system.) > > Note, that the NIS server is still running Debian 1.2. The clients will be > eventually upgraded. > It works for me, but I haven't got any reply on my questions what was wrong for others. Important is to use "compat" as sole method for passwd, group and shadow in /etc/nsswitch.conf. The nis package still uses libc5 and has to be changed a little to compile with libc6. Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: NIS and libc6/hamm?
Miquel van Smoorenburg: > In article <[EMAIL PROTECTED]>, > Christian Schwarz <[EMAIL PROTECTED]> wrote: > > > >Hi! > > > >Can someone tell me if NIS is working in the current "hamm" release? > >(Someone here mentioned that it is not, so I want to know for sure before > >I upgrade my system.) > > It seems to work with this in /etc/nsswitch.conf: > > passwd: db files nis > > But it crashes when using: > > passwd: db files compat > > So using + entries in /etc/passwd for access control doesn't work. > Well, it works fine for me. BTW, compat includes the files and db method, so sou really should have only compat as method for passwd, group and shadow. Please tell me more about your problem. Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: problems compiling plan under libc6
Your problem is quite easy to solve: libc5 was not really POSIX-compliant even when _POSIX_SOURCE was defined. S_IFDIR is the macro used by BSD and SVID while POSIX uses __S_IFDIR. If you define _BSD_SOURCE, _SVID_SOURCE or _GNU_SOURCE instead of _POSIX_SOURCE (or simply change the macro to include the __) it should compile. Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ghostview and xxgdb
> > Did anyone volunteer to update ghostview and xxgdb before the release? > These are the last two packages that use the old "R6" naming scheme > for X11 packages. I'd like to update these packages before release. > > If nobody wants to do this, I will, but I already have too much to do. > I'd appreciate it if someone with a few hours in the evening could do > this. (It shouldn't take long.) I'll do it. tomorrow there will be new ones. Helmut ------ Helmut Geyer[EMAIL PROTECTED]
beware sysvinit 2.58 installation
Hi! There is a small problem with the new sysvinit (2.58-1) suite. Once you have installed it, you can't shutdown/reboot/halt the system as these use a different way of communicating than the 2.57* init (a FIFO, no longer a file). So please make copies of the old init,shutdown, halt and reboot programs and reboot right after installing sysvinit 2.58. After rebooting, you can delete the old files. Helmut -- Helmut Geyer[EMAIL PROTECTED]
Re: Bug#2092: procps needs an update for kernels > 1.3.53
> > Package: procps > > Kernel 1.3.53 seems to have changed the way memory use is reported (I > think it reports a new value in /proc/meminfo, "cached:", referring to > cached VM pages) and also has an internal process "kernel bdflush" that > has a space in its name. The result is that "top" and "ps" can dump > core with floating exceptions (divide by 0, I think) or bus errors. > Patches for ps are floating around on the kernel mailing list. > > 1.3.53 is significantly faster than previous kernels because of page > cacheing. > For most of these problems, patches already can be found on sunsite. Nevertheless this isn't all we need to cover. psupdate cannot be run on ELF compiled kernels and really is deprecated when you have access to the System.map file. I have sent several patches to the procps maintainer several months ago and he promised to release a new version RSN. As this didn't happen, I have put together a procps suite including the patches from sunsite and some other fixes (e.g. the signal and cmd handling are broken in procps as well). As I do not have current ncurses (needed for top and pstree) and the system should be tested before releasing it, I didn't make any binary package. The source package procps-test.tar.gz has been uploaded to ftp.debian.org. THIS IS NO PACKAGE MEANT FOR INSTALLING right now, please test it and tell me how yopu like it. The package relies on /boot/System.map existing. This is not currently done in /sbin/installkernel. Putting if [ $map ] then cp $map /boot/System.map-$ver ln -sf System.map-$ver /boot/System.map fi into installkernel and removing the psupdate stuff is all you have to do. There are two versions of top, one the original and a new one, resembling the kmem top. ps -s has two possible output formats, one the classical and the changed one as done in kmem-ps. If you are testing this, please tell me (beside any bugs) about which signal format for ps and which top you prefer. Helmut Geyer >From the CHANGES file of procps: Changes from 0.97-1.3.53 (more precisely from 0.97) -> current: By Helmut Geyer ([EMAIL PROTECTED]) __LIBPROC__ snarfed the System.map handling routines from kmem ps 1.2.7 (update_db) removed unneeded parts from update_db.c and snap.c, as a lot got deprecated This is needed for ELF kernels that are not readable by psupdate / ps -U cleaned up the psdatabase routines. Removed psupdate completely. fixed the signal and cmd display bugs (in snap.c) __FUSER__ brushed up output format, don't display fuser process. __PS__ Added new signal format from kmem ps. (the old one still can be used when defining OLD_SIG_FMT while compiling). some minor fixes due to ELF programs behaving differently (e.g. the SIZE fields are no longer near equivalent, use ps -m for exact info). I still haven't found a way to do the lrs (shared Library) field when using ELF. The way it is done for a.outs is not portable to ELF at all. __TOP__ new top, more like the kmem one, configurable fields, ... run it and type h for more info. I like this better (who would've guessed), but it generates higher load, so YMMV. The old one is still available as oldtop. some fixes as to ps to make it do something useful when running ELF programs on a ELF kernels. Changes from 0.97-1.3.48 -> 0.97-1.3.53: By: Andrew Kieschnick ([EMAIL PROTECTED]) needed changes to /proc/meminfo handling Changes from 0.97-1.3.39 -> 0.97-1.3.48: By: ??? (from sunsite) This patch fixes a 'nice' related bug in procps-0.97-1.3.39, and also get the signal names from /usr/include/asm/signal.h since this is where they are in newer kernels. Changes to 0.97-1.3.39: By: Henry Shieh ([EMAIL PROTECTED]) This patch file is for 256 ptys to let 'ps' show correct tty info that uses the new pty major number. Use the shell script "mknewpty" to create 256 ptys using the new major number. Changes from 0.97 --> 0.97-1.3.39: By: Karl Keyte ([EMAIL PROTECTED]) o Changed some symbols to get rid of reserved name conflicts o Changed Makefile to pick up kernel definitions for those modules which require it. Also changed default optimisation and binary stripping. o Changed process default priority default to be consistent with version 1.3.39 o Added a check to 'fuser.c' to stop it SEGVing -- Helmut Geyer[EMAIL PROTECTED]
Bug#2095: man doesn't render manpages using latin1 characters correctly
Package: man Version: 2.3.10-6 Man doesn't display correctly any manpages containing latin1 characters. Just try 'man iso_8859_1' and 'man -Tlatin1 iso_8859_1 | less' I'd suggest to use latin1 as standard device for manpages, not ascii as both X and the linux console use latin1 encoding as standard. Helmut ------ Helmut Geyer[EMAIL PROTECTED]
Re: Bug#2092: procps needs an update for kernels > 1.3.53
I lost the reference, but someone said that System.map/psdatabase are obsoleted by /proc/ksyms in more recent kernels. I didn't know exactly then, so I checked it at home. This simply isn't true. ksyms holds a lot less information (only those symbols as generated by genksyms, not all symbols from the link map). So the way to go is to use System.map on ELF systems. Helmut ------ Helmut Geyer[EMAIL PROTECTED]
Re: Bug#4261: Ghostview and virtual package postscript_viewer
> > Package: ghostview > Version: 1.5-8 > > Ghostview should install itself into the /etc/mailcap entry so mime > compatible programs can use it to view postscript documents. > > I suggest making ghostview "Recommends: mime-support" and adding the > following to the install scripts: > > debian.postinst > ~~~ > if [ -x /usr/sbin/install-mime ] > then > install-mime--install --package=ghostview > --content=application/postscript \ > --description="Postscript Formatted Output" > --nametemplate="%s.ps" \ > --test='test "$DISPLAY" != ""' \ > --view='/usr/bin/X11/ghostview %s' \ > --comment="Ghostview is a fairly good front-end for viewing > postscript \ > and should probably be given a reasonably high > priority." > fi > > debian.prerm > > if [ -x /usr/sbin/install-mime ] > then > install-mime --remove --package=ghostview > fi > > No, that isn't what should be done, or at least not the only thing. I'm on my way to produce a second posctscript-viewer (front-end to gs) called gv, that is in some ways much better than ghostview, though there are too many differences in the user interface to drop ghostview instead. I propose to have a virtual package postscript_viewer installing a /etc/alternatives - managed binary /usr/bin/X11/ps_view and handling the stuff via update-alternatives. mime-support should either put/usr/bin/X11/ps_view into mailcap by default (which is what I propose), or we install it from ghostview and gv using install-mime. Helmut
RFC: policy supplement for library packages
Hi Folks!
The late discussion here on migration to libc6 indicates that a
statement on the requirements of library run time and development
packages is to be included in the policy manual. This is how I recall
the discussion we had about this topic some weeks ago. It might be
that I am a little biased, so feel free to correct me if you recall it
differently. Neither is this meant to be a fixed thing but we
definitely _need_ something so I started writing.
As I am taking over libc5 and libc6 from David Engel I will be heavily
involved in this anyway.
Helmut
-=-=-=-=-=-=-=-=-=-=-= SNIP -=-=-=-=-=-=-=-=-=-=-=-=-=-
Debian library policy supplement draft for libc5->libc6 migration
This document is meant to tell what a Debian package providing a
library should do to support both libc6 (glibc2) and libc5.
Note that these requirements are for Debian 2.0 (codename hamm).
Contents
1. Run time packages
2. Development packages
3. Requirements on libraries for Debian 2.0
4. Requirements on compiler packages
1. Run time packages
A package providing a shared library has to support both C library
packages, libc5 and libc6 based libraries. This must be done using
two Debian packages, each depending on the correct C library
package.
The package naming convention currently suggests to name these
packages as follows. Some packages (mostly from base) may use
locations in /lib.
based on | package name | library location
libc6 | libfoo | /usr/lib/libfoo.so.
libc5 | libfoo-libc5 | /usr/lib/libc5-compat/libfoo.so.
If a library runtime package contains files that are needed by
both versions of the library, a new package should be made for
just these files that both other packages depend on.
There are two exceptions from this rule. The shared linker
ld-linux.so.1 and the C library files libc.so.5 and libm.so.5
should still be located in /lib, not in /lib/libc5-compat.
Packages based on X have to use /usr/X11R6 as prefix, not /usr.
2. Development packages
The Debian policy requires that all files needed for compiling/linking
other packages with the library are in a separate package, the
development package. Up to now this package simply was called
libfoo-dev. As packages based on libc5 and libc6 usually cannot
use the same development files there has to be a clear statement
how to separate these. So for now the following packages are
required:
based on | package name| hierarchy locations
---
libc6 | libfoo-dev | /usr/{lib,include}
libc5 | libfoo-libc5-altdev | /usr/i486-linuxlibc1/{lib,include}
For the transition time there may be packages based on libc5 which
use the standard location. These have to conflict with libc6-dev,
however.
libc5 | libfoo-libc5-dev| /usr/{lib,include}
No such packages may be part of Debian 2.0.
Note that the choice to base Debian 2.0 on libc6 fixed the fact
that the main locations will be used for libc6 packages. The
alternate locations are used for libc5 based packages.
This decision does not necessarily mean that by default the
compiler uses the libc6 packages, please read section 4 for more
information. Using a four-way approach for library locations
(standard and alternate locations for libc6 and libc5 based
packages) will make Debian systems inconsistent with each other,
something we should avoid at (nearly) all costs.
3. Requirements on libraries for Debian 2.0
make libraries
thread-safe,
There will be a list available that lists all libraries part of
Debian and their current status regarding compliance with these
standard requirements. This list will be posted regularly to
debian-devel by Helmut Geyer <[EMAIL PROTECTED]>.
4. Requirements on compiler packages
The compiler and binutil packages have to provide working
development environments for both C libraries. Basically (that is
from the compiler standpoint) there is no real difference between
the two environments, only some paths and automatic definitions
have to be changed. All this can be done (and is in fact done) by
supplying a different specs file in a different location.
The compiler package has to supply a way to make one of the two
environments the default one.
Two ways this can be done are:
- using /usr/i486-linuxlibc1/bin for the libc5 based gcc. Just by
prepending this to the path this can be made the default.
This is the standard way such things are handled for
cross-compilers but has the disadvantage that each user has to
do this in order to make this change. As this has better
flexibility this may be considered a feature
uploaded libc (5.4.23-6 (i386 source) to master
-BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Thu, 22 May 1997 21:38:26 +0200 Source: libc Binary: libc5 libc5-pic localebin libc5-dbg libc5-dev Architecture: source i386 Version: 5.4.23-6 Distribution: frozen Urgency: high Maintainer: Helmut Geyer <[EMAIL PROTECTED]> Description: libc5 - The Linux C library version 5 (run-time libraries). libc5-dbg - The Linux C library version 5 (debug files). libc5-dev - The Linux C library version 5 (development files). libc5-pic - Kit for building specialized versions of the shared C library. localebin - The locale binaries of the Linux C library version 5. Changes: libc (5.4.23-6) frozen; urgency=high . * fix packaging mess up for frozen: add libc5-pic and localebin packages again. Remove libc5-altdev package. Files: 4e3bb6927a826b08e70a1ea6903189d9 689 libs required libc_5.4.23-6.dsc f85c6b2eef81306c0c7b0e4123f15064 652069 libs required libc_5.4.23-6.diff.gz a7f87b0bb19369a721f9870d96be1bea 259152 base required libc5_5.4.23-6_i386.deb 22fd42916bc6508365137a44b6c68f96 857602 devel standard libc5-dev_5.4.23-6_i386.deb b36f10ac2a6f743bc9f019f52f1e76fe 1188992 devel optional libc5-dbg_5.4.23-6_i386.deb 426e496049024d7a2f64291fc70b1d6f 849486 devel optional libc5-pic_5.4.23-6_i386.deb e64fe94e794fbf7993d0c4ffe9459bdb 44820 devel optional localebin_5.4.23-6_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQCVAwUBM4TTNtr+2q4pQAYJAQEWpQP/ZwAkjVllfPVzi84agag8Fn2aJIxXvGsc XaTDcmI5xGWc1C4aMqAFAYnLwqJ74sVC7REjKMM6HQea65TRpq1tD8kByE27G97m 8wpHmVBZHT7LGwlD5gOs9XwDybS8IDjGPw29C8gdA2hcl0kdS+T2kM9o/33nSteW 2BjDwJ55aTA= =xcx1 -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
IMPORTANT: libc5 5.4.23-6 has to be in bo
Hi! This package include a bug to a serious bug in the NIS code of libc5. It definitely should be part of bo. Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
