On Wed, Aug 27, 2008 at 12:29 AM, Rob Landley <[EMAIL PROTECTED]> 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 > [email protected] > http://busybox.net/cgi-bin/mailman/listinfo/uclibc _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
