Auditing the menuconfig help entries.

[Will Newton]

On Wed, Aug 27, 2008 at 12:29 AM, Rob Landley <rob at landley.net> wrote:
> 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?

Historically the distinction has been that i386 can deal with non-PIC
code in situations where other architectures can't. There are now
other wrinkles such as PIE code (e.g. I may want a statically linked
PIE executable) and I suspect the NOMMU architectures may need some
special casing as well.

A .a file is a ar archive, it may be used as a static linked library
but it may also be linked into a shared library in which case it must
be PIC. I'm not aware of any particular case where this would happen
in uClibc, but it can happen.

> 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?)

Yes, I use it and it works.

>> >  (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.
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc