RFC: DOPIC etc

[Peter S. Mazinger]

On Thu, 13 Oct 2005, Peter S. Mazinger wrote:

> On Thu, 13 Oct 2005, Erik Andersen wrote:
> 
> > On Thu Oct 13, 2005 at 04:21:15PM +0200, Peter S. Mazinger wrote:
> > > Hello!
> > > 
> > > Currently we have DOPIC/HAVE_NO_PIC/HAVE_SHARED/HAVE_NO_SHARED options 
> > > that are somewhat overlapping. What do we need of these?
> > 
> > The HAVE_NO* options are there because of limitations of the
> > config system.  Ideally we would be consistant though -- we
> > currently have an evolutionaly mix of HAVE_NO*, HAS_NO*, and
> > a few others just to mix things up...
> > 
> > > Cases:
> > > 1. archs that do not have shared lib support and/or shared lib loader (the 
> > > latter is overlapping w/ another option BUILD_UCLIBC_LDSO/ARCH_HAS_NO_LDSO)
> > > 2. user does not want shared libs
> > > 3. user wants overall PIC code also in lib*.a (shared libs should be PIC, 
> > > unselectable)
> > > What else has to be covered ?
> > > 
> > > nios* and v850 have HAVE_NO_PIC/HAVE_NO_SHARED/ARCH_HAS_NO_LDSO set
> > > sh2a is somewhat different, but results in the same
> > > sh2 has only ARCH_HAS_NO_LDSO defined, results in !BUILD_UCLIBC_LDSO
> > > 
> > > What are the real cases?
> > 
> > 
> > BUILD_UCLIBC_LDSO dates back to a time when uClibc only had
> > (mostly broken) shared library support for i386 and nothing else.
> > I added that option to allow uClibc to be built using the glibc
> > shared library loader.  uClibc has since matured so we can
> > probably lose this option.
> > 
> > HAVE_NO_SHARED was used to address case #2, where the user does
> > not wish to build shared libraries.
> > 
> > Both nios* and v850 and sh2 all result in the same thing:
> > 
> > 1.a arch does not have a native uClibc ldso since nobody has
> >     written a working one yet.
> > 
> > And of course support for loadiing and handling shared libraries
> > on mmu-less processors has been done by a few companies, but has
> > never been added to uClibc.  So for the time being
> > 
> > 1.b  ARCH_HAS_NO_MMU implies ARCH_HAS_NO_LDSO.
> > 
> > As I recall, I added PIC/HAVE_NO_PIC as an easy way to decide
> > whether or not code should be pic.  So while this is clearly
> > ought to be set when building shared libraries, there are cases,
> > such as with uClinux, where folks need to build static libraries
> > that are pic.  glibc does something interesting here, in that it
> > compiles every file twice, once non-pic (foo.o) and once as pic
> > (foo.os) and then uses the pic code for shared libs and such, and
> > the non-pic code for static libs.  That would allow us to make
> > our static libs smaller.  Then we would construct our shared libs
> > from libuClibc_pic.a and such.  I've been thinking about doing
> > such a thing for a while, but never gotten round to it.
> > 
> > > libdl.a is not built if we do not have BUILD_UCLIBC_LDSO enabled. Is this 
> > > correct, or there are cases where w/o shared lib support and/or 
> > > UCLIBC_LDSO libdl.a may be used?
> > 
> > There seems to be little point in trying to load shared libraries
> > when a shared library loader is not present...
> >
> >  -Erik
> 
> Would then following be ok:
> ARCH_HAS_NO_MMU sets ARCH_HAS_NO_LDSO
> ARCH_HAS_NO_LDSO is set for archs not having support done (are these not 
> 	having a ldso/ldso/TARGET_ARCH dir ?)
> HAVE_SHARED depends on !ARCH_HAS_NO_LDSO
> HAVE_SHARED enables ldso/libdl and all lib*.so and is optional (what 
> 	should happen w/ ldso and libdl if HAVE_SHARED is disabled ?)
> DO_PIC enables building everything as PIC, if not set only shared libs are 
> 	built with PIC

What about HAVE_ELF ? Which cases/archs are not ELF?
All those with HAVE_ELF set may have LDSO and HAVE_SHARED, right ?
Also CTOR_DTOR is HAVE_ELF dependent (and should use [S]crt1.o, else 
crt0.o -if we support this latter case in future without init/fini)

ARCH_CFLAGS/ARCH_LDFLAGS/LIBGCC_CFLAGS not used

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