gcc 3.4 toolchain question

Amadeus amadeus at iksw-muees.de
Sat Oct 14 09:02:52 CEST 2006


On Saturday 14 October 2006 02:15, Bradley Remedios wrote:
> Ok, a little update, there is no dlopen in uCLibc because uCLibc is
> not being configured with support for shared objects (which dlopen,
> opens.)


> And there is no support for that because it is being 
> compiled without PIC support.

The RAM build (and most other builds) are using the compiler flags -fpic 
and -msingle-pic-base. So this should be fine.

> After enabling PIC Support I had to modify uCLibc as it has some
> naughty ldso code that declares a few statics as externs.

As far as I know (I have read some howto with google), dynamic linking 
is working with uCLinux + glibc and "non-working" with uCLInux and 
uClibc. "non-working" because you have to add static IDs to the dynamic 
libraries, and this will in turn lead to code bloat.

So I have decided against having shared libs. The "applets" in PIXIL are 
so small that it doesn't matter to link them all together in the 
executable. All we must do is to add a prefix to the non-static 
functions, and do some sort of applet registration.

Do you have evidence that shared libs are working fine in uCLinux + 
uClibc + FLT binaries?

We're back to the times when men were men 
and wrote their own device drivers.

(Linus Torvalds)

More information about the dslinux-devel mailing list