DragonFly BSD
DragonFly kernel List (threaded) for 2005-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: libc changes and freebsd-4 compatible binaries

From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Tue, 3 May 2005 19:40:56 +0200
Mail-followup-to: kernel@crater.dragonflybsd.org

On Tue, May 03, 2005 at 09:33:43AM -0700, Matthew Dillon wrote:
> :That's not true, it just doesn't work for LC_* != C. Well, even that is
> :not entirely true, e.g. LC_COLLATE should still work.
> :
> :> Can't the sources producing libc.so.4 be made to call the sources producing 
> :> libc.so.5, or what?
> :
> :The problem is not creating it, the problem is that both are installed into
> :the same location.
> :
> :Joerg
>     Is it a big deal to move the citrus locale files to a different
>     directory ?  I would like to maintain FreeBSD-4 compatibility as much
>     as possible... well, actually, not so much because it would be 
>     FreeBSD-4 compatibility, but because it would be DragonFly-1.2
>     compatibility as well.

Moving the citrus files isn't much better either, since /usr/share/locale
is the canonical location on ALL other systems. It would be confusing to
change that. It's a much cleaner solution to move the default location of
the compat libs and just ignore statically linked binaries.

I don't completely understand the big fuss here. The applications still
work, just with the default POSIX locale. You could even rename the locale
and use a shell wrapper or so for the binaries you can't just recompile.
For most applications there isn't any noticable difference. If you
have Opera for example, the worst case is a bad message and monetary
formating [once I toughted that too]. The effect of the ctype change should
be very small for most programs.


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