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

Re: i18n and libnewt?



In message <[🔎] oak7w0f9de.fsf_-_@arroz.onshored.com>, Adam Di Carlo writes:
>Philip Blundell <philb@gnu.org> writes:
>> Finally, we could just make sure that the versions of newt and slang that 
end
>> up on single-locale boot floppies are the non-UTF8 ones.  This seems like 
the
>> most attractive proposition right now and I'm pretty sure it will make the
>> problem go away.
>
>Don't we do this already?  If not lets change it to make this so.

No, we don't.

The root of the problem (in fact, pretty much all the newt-related problems
we've been having) is that libnewt-utf8 and libnewt have the same soname but
are not actually binary compatible with one another.  Mklibs.py can't tell
the difference between them, so if you aren't careful you can end up with it
pulling objects out of libnewt_pic.a when actually libnewt-utf8_pic.a was
needed.

I think that the current situation is actually that we avoid the bug by not
doing any reduction on libnewt at all.  Luckily this isn't a particularly
big deal because libnewt is only 50k or so to start with.

>For the other thing, you can't seem to have both libnewt*-pic packages
>installed and have mklibs.py know to use the right one for the right
>image.  Isn't this going to cause serious problems with library
>reduction?

Right.  I don't know what the right way to fix it is, though.

I think our choices are:

1. Teach mklibs.py to handle newt specially (slang may need the same
treatment too).  This would involve finding someone who can tell Python
apart from line noise (ie not me).  

2. Fix libnewt8-utf8-0 to have a different soname so that it can coexist 
with libnewt0, at which point mklibs.py should just do the right thing
automatically.  Again, slang may be in the same boat.

3. Avoid the issue and try to work around it in the build machinery.

p.



Reply to: