On Thursday 30 October 2008 02:12:59 Vladimir Dronnikov wrote:
> > > On mini-native/system-image:
> > > As you know I want to link all things statically. But the presence of
> >
> > *.so*
> >
> > > in /lib prevent some broken packages from respecting even "magnum"
> >
> > '-static
> >
> > > --static' LDFLAGS.
> >
> > Try putting it in CFLAGS, maybe?
>
> I even put them to all {C,LD,CPP}FLAGS -- no effect
>
> (Which packages are these?)
>
> e.g. hping2

URL?

> How do you ever build these things statically on
>
> > a normal host system (ala building 'em natively under Ubuntu?)
>
> I've been using toolchain that I've managed to build from scratch using
> buildroot a year or so ago. I spent long time to get them rid of shared
> libraries. Pity, I've lost that patches so can not reproduce the building
> process. Now I've finally decided to get rid of my toolchain in favour of
> yours. And am trying to make things work as I expect. Never been compiling
> smth under full-blown distros.

So the answer to my question is "you don't".  Sounds like the package's build 
needs to be patched.

As I posted to the FWL mailing list, I'm in the middle of getting uclibc++ to 
work so no new snapshot tonight.  (I've got a server set up and ready to add 
a cron job to, but I've been wrestling with C++ instead.)

> > How can I get the goal more elegantly?
> >
> > Could be a few ways, but I'd like to know more about the problem first.
>
> I'd manually remove *.so* from mini-native if you'd ship statically linked
> toolchain. You see, I'd like to remove any relation between the host, the
> building system and the target binaries. While toolchain depends on
> libraries, it is not "portable". The size increase will not be big, but the
> benefits are obvious (to me, at least).

That's what the BUILD_STATIC=1 variable is for.  Building a toolchain 
statically linked against uClibc involves building a uClibc toolchain and 
then rebuilding _under_ that, and the nightly builds for all targets already 
take several hours.  Statically linking against glibc's no fun (and leaks 
crud like libnss that gets dlopened anyway).

Lemme finish the current todo item before tackling the next one.  I still 
think a selective tree of symlinks is probably a good solution, but am a bit 
tired to plot it out in detail just now...

Rob
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Reply via email to