[uClibc] hiding uClibc internal symbols

Peter S. Mazinger ps.m at gmx.net
Sat Oct 30 21:33:07 UTC 2004


On Sat, 30 Oct 2004, Erik Andersen wrote:

> On Sat Oct 30, 2004 at 10:14:26PM +0200, Peter S. Mazinger wrote:
> > Unhappy to hear that ;-(
> 
> How so?  Waiting a week or two before so we can push out a
> stable release starting massive internal restructuring does
> not seem unreasonable to me,

There are some patches, that didn't got into cvs yet (I am not speaking 
of the one heavily discussed and rejected). So after releasing 
uclibc-0.9.27, the gentoo version will be patched heavily for hardened 
uclibc stages and the test results there are again not relevant to the 
official 0.9.27 version and vice-versa, because they are too different.
(it's sure that the rejected patch has to go into all gentoo versions, 
and probably you will need it for uwoody too ;-)
Let's take for ex. the relro addition that is currently in testing and 
looks good. This will for sure be added at least to the hardened gentoo 
version, if you don't add it to the release there will be 2 "sets" of 
ldso bug-reports.

The same applies to ssp.c, current version in uClibc is 4 releases back.
And I can tell you, if someone wants to enable currently blindly that 
option and he does not know what he is doing, he will wrack his system.
Scenario:
1. He reads the comment of the option, goes to the URL, downloads a patch 
for gcc and rebuilds gcc
2. Rebuilds uClibc enabling ssp
3. Now he ends up w/ the same 2 symbols in 2 different libs (libc and 
libgcc_s) and either all builds will fail afterwards w/ a recent binutils 
having --as-needed support, or, if he is "lucky", and built gcc w/ an old 
binutils, then he won't be able to build c++ apps
Do you really want to have such bug-reports? Well, I don't want to support 
such bugs (and provide solutions to solve/circumvent), and I don't want to 
call such a "release" (I know there are not many on this list who use ssp, 
but more and more are using it in gentoo-land)

So the correct tests to enable/disable an option (as described in my 
proposal) should also be added to the release. These addons don't only add 
more options, they would also offer a more robust release.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list