gcc 3.4 toolchain question
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,
> 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.
More information about the dslinux-devel