Auditing the menuconfig help entries.

[Rob Landley]

On Tuesday 26 August 2008 08:03:03 you wrote:
> On Sun, Aug 24, 2008 at 06:56:44PM -0500, Rob Landley wrote:
> >Fiddling with menuconfig:
> >
> >DOPIC (Create only position independent code)
> >
> >  Does not say why you would or wouldn't want to do this.  (Does it
> > generate position independent code and non-position independent code? 
> > Should the .a files also be PIC, or just the .so files?  If you select
> > this are you telling it _not_ to generate any .a files, so static linking
> > isn't an option?  Is there a downside to statically linking PIC code?)
>
> Building pic code into an .a doesn't make sense to me.
> Anyway. If you're lucky (and e.g. on i386), it's possible to get away
> without pic even for .so. Don't try that at home unless you know exactly
> what you're doing.

PIC makes sense for .so files, but not for .a files.  When you dynamically 
link, you use .so files.  When you statically link, you use .a files.

This is why this option confuses me, is it saying "don't create .a files, we 
will never statically link"?  Is it saying "create bloated .a files"?  Is 
this platform-specific for certain platforms?

What is the benefit of creating _only_ position independent code?

> >LINUXTHREADS_OLD:
> >
> >  Ok, what does this currently mean?  This selects the old libpthreads
> >  implementation from the dawn of time, but what's the alternative?  The
> > new NPTL stuff hasn't been merged yet, so this intermediate version is...
> > what?
>
> OLD means the old version. !OLD is something newer. !UCLIBC_HAS_THREADS
> is what i do and the rest is a myth.

OLD works now.  In theory NPTL might be made to work someday.  The one in 
between doesn't seem to work and nobody's actually trying to improve it; does 
it have a reason for still being there?  (Is somebody, anywhere, successfully 
using it for anything?)

> >  (And while we're at it, what does this mean:
> >  ./libpthread/linuxthreads.old/sysdeps/x86_64/pt-machine.h:39: warning:
> >  register used for two global register variables )
>
> Which versions of binutils and gcc? DOMULTI set in configure?

It was whatever ubuntu came with (2.18 and 4.1.3), and using the .config I 
attached on sunday (which had DOMULTI set).

> >UCLIBC_HAS_STUBS
> >
> >  This is just "fork on nommu", right?  Shouldn't it be under nommu
> > sypport and depend on it?
>
> The additional comment is a bit misleading. Initially i ment it to just
> be the first paragraph with s/impossible/impossible or unwarranted/
>
> >UCLIBC_BUILD_RELRO
> >UCLIBC_BUILD_NOW
> >
> >  There are no help entries for these, and no _clue_ why one defaults to
> > on and the other off.
>
> man ld

I was thinking it might be a good idea to explain in the menuconfig help what 
the uClibc config options actually do.  Call me crazy...

I've looked at the LD man page, and although the "NOW" entry is fairly 
understandable:

>            now
>            When  generating  an  executable  or shared library, mark it
> to tell the dynamic linker to resolve all symbols when the program is
> started,  or  when  the  shared  library is linked to using dlopen,
> instead of deferring function call  resolution  to  the point when the
> function is first called.

It doesn't even speculate about the advantages/disadvantages of actually doing 
it.

After re-reading the man page, I still don't know what relro means:

>            relro
>                Create an ELF "PT_GNU_RELRO" segment header in the object.

>            norelro
>            Don’t create  an  ELF  "PT_GNU_RELRO"  segment  header  in
> the object.

I googled for PT_GNU_RELRO, but the first page of hits all assumed you knew 
what it meant.  Some had hopeful titles, but alas...

  http://sources.redhat.com/ml/libc-hacker/2004-01/msg00053.html

I tried several search variants and eventually found a blog entry on it:

  http://www.airs.com/blog/archives/189

Which itself spends the last paragraph talking about how obscure and 
poorly-documented a feature it is.

If we assume that five minutes of googling and reading per config entry is 
acceptable, with around 200 config entries, this would mean that configuring 
uClibc for the first time can be expected to take about 2 full work days.

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.