[uClibc] hiding uClibc internal symbols

Manuel Novoa III mjn3 at codepoet.org
Sat Oct 30 23:09:02 UTC 2004


Peter,

On Sat, Oct 30, 2004 at 11:33:07PM +0200, Peter S. Mazinger wrote:
> 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.

For your information, I spent most of last night and much of today
looking at issues involving the transition to using hidden symbols.
Given that we're talking about library-wide changes, this is not
something that we're going to jump into haphazardly.  I'm also not
willing to start making changes until all the issues are considered.
I plan on writing a tool to handle most of the transition.  This will
minimizing possibilities of errors, as well as give us the oppurtunity
to make other overall improvements.

The only reason I _did_ look at it now (as it is several items down on
the priority list) is to try to give you an idea of the blueprint I'd
like to see followed.  But the fact is, I've got a contract to finish
_plus_ an impending move for a new job and I simply don't have
sufficient time to spend on this at the moment.  Combined with the fact
that there are at least two customers asking for a stable release, the
hidden symbol stuff is on hold.

Regarding gentoo patches in general, I applied a number of them a while
back when solar asked me to look at them.  When he's comfortable asking
again (meaning they've been tested somewhat and appear stable), then I'd
look at them again and commit them _ASSUMING_ they were reasonably clean
_AND_ didn't conflict with a direction I wanted to move in.  The only 2
patches of your's that I've said anything about lately were 1) the utils
patch (both Erik and I told you why) and 2) a patch where you added cruft
to a system header.

Regarding "hardened" patches in particular, you NEED TO REALIZE that
they are not currently a priority item for us; they are a wishlist item.
NONE of our customers has EVER asked about that functionality, much less
requested it.  On the other hand, they have asked about a number of
other features.  So while I have nothing against including such patches,
they take a back seat to the stuff people actually pay us to do.  Until
someone asks us about them or until we run out of higher-priority
tasks, they will have to be tested in gentoo and then incrementally fed
to us after testing.

Regarding people using uClibc in distributions, I know I told you a
while back that as far as I'm concerned, uClibc isn't ready for such
use until we get to 1.0.  So I am not going to waste time worrying
about distribution maintenance implications of changes until then.

Manuel



More information about the uClibc mailing list