Re: Those i386 libraries on amd64

[Lloyd Parkes <lloyd%must-have-coffee.gen.nz@localhost>]

On 19/09/2013, at 5:59 PM, Matt Thomas <matt%3am-software.com@localhost> wrote:

> 
> On Sep 18, 2013, at 8:16 PM, Lloyd Parkes 
> <lloyd%must-have-coffee.gen.nz@localhost> wrote:
> 
>> So I found all those i386 libraries in /usr/lib/i386 on my amd64 system and 
>> I found them really handy because I had just converted it from an i386 
>> system and I hadn't  prepared some of my apps as well as I should have. 
>> 
>> Where do those libraries come from? I've had a look, but it's buried deeper 
>> than I have the energy to dig at the moment, and it would be nice if someone 
>> could just tell me the answer. 
>> 
>> There is a bug in the Citrus I18N library such that when this special i386 
>> build is done, it doesn't know that it should use the new library path when 
>> trying to dlopen() modules that it wants and it tries loading a 64 bit 
>> library into a 32 bit program. This is a bug that all module loading 
>> software has when built this way, at least NetBSD does actually seem to 
>> supply all the right libraries.
>> 
>> Once I know how these libraries get built, I hope to be able to propose a 
>> possible solution and then PR it.
> 
> You need to use -m32 when building and the toolchain will do the magic needed.
> Look src/compat/amd64

I big nyetski on that. You missed the bit where I said "dlopen()". 

I built a test program with -m32 and it built just fine (which I think is 
completely awesome), but when the 32 bit program calls 
dlopen("/usr/lib/i18n/libUTF8.so.5.0"), there is no magic that will save it. 
The files in /usr/lib/i386/i18n are not shared libraries that a linker can 
find, instead they are explicitly loaded modules that the loading program (the 
Citrus stuff in libc in this case) must name.

My test program that core dumps with -m32 is:
#include <locale.h>
main ()
{
    printf ("%s\n", setlocale(LC_CTYPE, "en_NZ.UTF-8"));
}

A workaround is to specify the Citrus environment variable 
PATH_I18NMODULE=/usr/lib/i386/i18n when running 32 bit programs, but that does 
require the user to be psychic, so I can't see that winning much favour in the 
NetBSD community.

What I want is to work out when a cross-compilation (well, a 
cross-cross-compilation because all NetBSD compiles are cross-compilations) is 
occurring so that the default of /usr/lib/i18n can be changed to 
/usr/lib/i386/i18n in the appropriate header file.

Despite all of what I have just said, I have had a look at src/compat/amd64 and 
that is the specific answer to my specific question. Now that I know how the 
compiler is being invoked, I can work out what to do to fix the source. I'll 
probably look at adjusting the make file(s) for Citrus to pass the make 
variable LIBDIR in to the compiler as a C preprocessor symbol so that it can be 
used. That strikes me a simple and platform agnostic.

Cheers,
Lloyd