The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Which libc should we use in the future?

David Engel:
[..]
> 
> There is one catch with libc 5.4.x that people need to be aware of.
> Programs built with it may not run with libc 5.3.x or lower.  What
> this means is that once someone installs libc 5.4.x and programs built
> with it on their system, they can't downgrade back to libc 5.2.18
> without risking breaking things.  This could be a real problem for a
> developer who needed to update a package in the stable tree because it
> would need to be built with libc 5.2.18.  
> 
> The way I was going to handle this was to make a special libc5-dev
> package using libc 5.2.18 which did not depend on the corresponding
> libc5 run-time package (i.e. the symlinks for libc.so and libm.so
> would be replaced with real files).  This way, a developer could
> install this libc5-dev package when needed instead of the normal one
> without having to downgrade the libc5 run-time package.
> 
This is _very_ hard to do (not because of the libs, that's easy) as you have
to support two include file trees /usr/include fo rthe standard include files.
They are incompatible.
There are basically two ways to do this:
1.  You would have to make some mechanism like having three directories:
   /usr/include-5.2.18, /usr/include-5.4.7 and /usr/include.
   All non-libc includefiles are in /usr/include, the libc includes are
   managed using an automated script and symlinks.
   i.e. some script 'turn-on-libc <version>'
2. same as above but use -I directives. This is very complicated, as
   the directory gets appended to the include path, so the gcc includes may be
   read before the libc include. This can, of course, be changed using 
   additionally -nostdinc which ahs teh disadvantage that you have to
   specify the gcc include path explicitly. This could be done using a
   special gcc script (which is updated when gcc is).
3. have a non-standard gcc to support the different structures. This is, IMHO,
   overkill and shouldn't be done.
>[..]

what do you think,

	Helmut

------------------------------------------------------------------------------
Helmut Geyer                                Helmut.Geyer@iwr.uni-heidelberg.de
public PGP key available :         finger geyer@kalliope.iwr.uni-heidelberg.de

--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com