water cooler :: Would it be time for DSL to shed its skin?



on the other hand, I'm good at building Xorg. So you can have Firefox and I'll take X..

florian: that would be ideal, but since programs hard-code glibc into /lib/libc.so, which will be uclibc and thus cannot be made a link to glibc, wouldn't work...
I still think that if DSL goes with a uclib base, MyDSL should provide glibc.unc for users that needs compatibility with legacy extensions

When compiling extension and base program for "uclib DSL", we should make sure to link to /lib/uclibc.so

The compatibility glibc.unc extension could create /lib/libc.so that the legacy MyDSL programs use.

-Florian
@florian: you're missing the point. If the link was replaced to another libc, only static and programs compiled for that libc would work. So after using that only the old extensions would work, not even tar or ls or any basic util would be available...

As libc.so is a shared library, programs load it everytime the programs are loaded..

@stupid_idiot: which target triplet and optimizations did you use?
As it's gonna be built from ground up, we should do everything we can to improve performance & size (triplet should be i486-pc-linux-uclibc, best optimization IMO would be "-Os -march=i486 -mtune=i686 -fomit-frame-pointer"
@Curaga: I think you missed my point in previous point as I never spoke about a symbolic link in my previous post

My point is that compilation should always explicitely define the uclibc name by uclib.so (can be done in gcc using something like -nodefaultlibs or -nostdlib flag). This is an hassle but this is the only way to ensure backward compatibility! .

This way legacy extensions would access  libc.so from the glibc.unc MyDSL compatibility extension, while core apps and newly "properly" compiled extension would still work against uclib.so

-Florian
Quote (curaga @ July 18 2007,22:49)
@stupid_idiot: which target triplet and optimizations did you use?
As it's gonna be built from ground up, we should do everything we can to improve performance & size (triplet should be i486-pc-linux-uclibc, best optimization IMO would be "-Os -march=i486 -mtune=i686 -fomit-frame-pointer"

In previous times, I did use the same flags you suggested.
Sadly, the additional optimized code from '-march' and '-mtune' increases the size of binaries somewhat. So does '-fomit-frame-pointer' - 'libwxgtk1.uci' is 2.0M with fp omitted and 1.8M without. So it led to me cheating; the added convenience doesn't hurt neither - I just use '-Os'.
That is when compiling libraries.
When compiling binaries, I also use
'-fdata-sections -ffunctions'
and
LDFLAGS='-Wl,--gc-sections'.

With buildroot, I used the default suggested CFLAGS:
"-Os -pipe"
Unfortunately, what buildroot does is prepend these flags to the command line. So it tends to get overridden by the default flags ('-O2 -something -something') of the packages. I am sure there is an easy way, somewhere, around this.
Next Page...
original here.