FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 02-19-2009, 01:42 AM
Dan McGee
 
Default Dumping klibc (WAS: Changing raid/raid-partitions initcpio hooks)

On Wed, Feb 18, 2009 at 7:38 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> Tobias Powalowski schrieb:
>>
>> Now comes the point, to achive this, mdadm will be needed in initramfs
>> which means having a 900k static binary in early boot sequence.
>> (raid-partitions hook already uses this binary)
>
> I am really annoyed by the fact that almost nothing builds against klibc.
>
> Wouldn't it be easier to switch to uclibc and busybox? Both are much more
> powerful and we wouldn't need static binaries for lvm, cryptsetup or mdadm.
> We would also have much less problems with all the ABI changes that happen
> with klibc.
>
> I thought we needed a complete toolchain for that, but Jan claimed that it
> is possible to use our normal gcc and binutils for that.

I would be in support of this, as I have seen some of the headaches
you have had to deal with when it comes to klibc. Assuming the initrd
images wouldn't be insanely sized, I don't think this is a problem.

The only real point of klibc is that it is much much smaller than a
full-blown glibc, correct?

-Dan
 
Old 02-19-2009, 02:53 PM
Aaron Griffin
 
Default Dumping klibc (WAS: Changing raid/raid-partitions initcpio hooks)

On Wed, Feb 18, 2009 at 8:42 PM, Dan McGee <dpmcgee@gmail.com> wrote:
> On Wed, Feb 18, 2009 at 7:38 PM, Thomas Bächler <thomas@archlinux.org> wrote:
>> Tobias Powalowski schrieb:
>>>
>>> Now comes the point, to achive this, mdadm will be needed in initramfs
>>> which means having a 900k static binary in early boot sequence.
>>> (raid-partitions hook already uses this binary)
>>
>> I am really annoyed by the fact that almost nothing builds against klibc.
>>
>> Wouldn't it be easier to switch to uclibc and busybox? Both are much more
>> powerful and we wouldn't need static binaries for lvm, cryptsetup or mdadm.
>> We would also have much less problems with all the ABI changes that happen
>> with klibc.
>>
>> I thought we needed a complete toolchain for that, but Jan claimed that it
>> is possible to use our normal gcc and binutils for that.
>
> I would be in support of this, as I have seen some of the headaches
> you have had to deal with when it comes to klibc. Assuming the initrd
> images wouldn't be insanely sized, I don't think this is a problem.
>
> The only real point of klibc is that it is much much smaller than a
> full-blown glibc, correct?

I'd be for it too, but I'd like to actually SEE an implementation
before we commit to anything. This will increase our initramfs size,
but it will also give us more functionality.

I don't imagine much would need changing - just some of the tools used
in the base mkinitcpio hook... and maybe removal or recompilation of
much of the klibc-extras utilities.

At the very least, we could stick a uclibc package in extra so that we
could begin playing with this, right?
 
Old 02-20-2009, 07:06 AM
Tobias Powalowski
 
Default Dumping klibc (WAS: Changing raid/raid-partitions initcpio hooks)

Am Donnerstag 19 Februar 2009 schrieb Jan de Groot:
> On Thu, 2009-02-19 at 02:38 +0100, Thomas Bächler wrote:
> > I thought we needed a complete toolchain for that, but Jan claimed
> > that
> > it is possible to use our normal gcc and binutils for that.
>
> I'm using an unofficial debian package for uclibc. There's a package
> called uclibc-toolchain, which contains a script to munge the gcc spec
> file. After this script is used to munge the gcc spec file (we could
> alter the gcc specfile by default in the gcc package btw), there's a new
> flag for gcc: -uclibc. Whenever you compile something with this option,
> includefiles are diverted to /usr/i486-linux-uclibc/include and
> libraries are linked against uclibc instead of glibc. The only problem
> we have to solve is getting shared libraries like the ones from
> devicemapper installed in a way that it doesn't conflict with the ones
> that link against glibc.
Keepn in mind mdadm willl not work with uclib for x86_64, it's stated in the
Makefile.

greetings
tpowa
--
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa@archlinux.org
 

Thread Tools




All times are GMT. The time now is 11:08 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org