Re: i18n and libnewt?
Philip Blundell <philb@gnu.org> writes:
> 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.
How can you be sure we're not doing reduction? After all, 'make
check' in i18n mode demands libnewt-utf8-pic is installed.
Perhaps we need to demand that in fact no libnewt*pic packages are
installed for "heterogenous" i18n builds such as i386 where some
flavors are i18n and some are not.
> >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).
Not me either.
> 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.
That's the correct solution, but I don't know if soname changes at
this point in the process...
> 3. Avoid the issue and try to work around it in the build machinery.
This is what we should probably do...
--
...Adam Di Carlo..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>
Reply to: