Philip Blundell <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]>, Adam Di Carlo writes: > >Philip Blundell <[EMAIL PROTECTED]> 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..<[EMAIL PROTECTED]>...<URL:http://www.onshored.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
