DragonFly BSD
DragonFly submit List (threaded) for 2004-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Import widechar support from FreeBSD


From: Andreas Hauser <andy@xxxxxxxxxxxxxxx>
Date: 1 Nov 2004 19:20:58 -0000

joerg wrote @ Mon, 1 Nov 2004 18:05:08 +0100:

> After looking at both FreeBSD's and NetBSD's multibyte support, I want
> to express that I don't like the static inclusion at all.

It's < 10 encodings and those are supposed to get less and not more.
So can you elaborate a bit more, why it is so bad ?
If we are talking about object size, it can't be too much..
If it is speed, please show figures 8-)

> NetBSD's citrus derived source does a dlopen of the modules, which isn't
> _currently_ supported for static binaries. But adding a hack for that
> is easier than to include all supported character sets into any static
> binary using wide character support. Besides, once we have a minimal
> dlopen implementation for static binaries, it will work much better.

I think something more clever than rtld is wanted anyways.
So we could make that more generic. Maybe some VFS magic that
maps the right module in the process space.

Some loose strings that could maybe tied together:
- ELF shared objects
  Getting rid of rtld ?
  Letting programms only see the specified lib versions etc.
- Static libraries synamic loading
  Sounds wierd, but maybe move on to a unified .so .a arch
- resident(8)
  exploit it finally

Someone good at ties ?

> I'm currently working on getting the Citrus code ready for inclusion.
> One important problem is that because of how FreeBSD 4 historically
> handled e.g. ctype macros, I will have to create some compatibility
> functions to keep the ABI intact. I don't want to bump libc's major
> at this time.

Mixing the libcs will make it more difficult for us.
I'm not sure if this is worth it, i tend to say no.

Getting citrus in now looks like a dirty thing. Let's solve the
generic problems of our ELF first and think about it again then,
since, i think, when we have the infrastructure, things might look
different and the disadvantages of the FreeBSD version might vanish
together with the NetBSD ones. And we can then choose freely.
In the meantime we can use the easy to integrate FreeBSD version.


Andy



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]