mock issues on ia64 with LoadLibrary("libc.so.6")

[Clark Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Doug Chapman wrote:
> On Thu, 2007-12-20 at 01:19 -0800, Roland McGrath wrote:
>> What mock is doing there is a little freaky.  Since the functions you want
>> are in libc and you know it's always going to be there, you don't really
>> need to ask for the right libc object by name.  
>> You can use dlsym (RTLD_DEFAULT, "function") to look up the functions in
>> the global scope that the python executable uses, which gets to libc.
>>
>> The python code doesn't seem to have a way to use RTLD_DEFAULT.
>> But, when you do:
>>
>> 	_libc = ctypes.cdll.LoadLibrary(None)
>>
>> That translates to dlopen (NULL, ...), which in fact works the same as
>> dlopen ("", ...), i.e. opens the executable itself (python).  Since libc is
>> a dependency of the executable, its symbols are found by dlsym on the
>> handle from dlopen (NULL, ...).
>>
>> In short, to the extent this whole kludge of the python code knowing the
>> ABI details of some libc symbols is sane at all, it's probably fine enough
>> to use "_libc = ctypes.cdll.LoadLibrary(None)" and be "portable".
>>
> 
> Roland,
> 
> Thanks for the tip.  I have verified this does indeed do the trick.
> 
> Could one of the mock maintainers make the fix?  Patch is below.
> 

Both Michael and I are in and out due to Christmas holidays, but I'll try and get
this (and the other patches) into a build by Monday.

Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkdthd4ACgkQHyuj/+TTEp3iGQCcD/McnKiPudrb99ZU3rDndWe5
DA4AnjHq66gLMUeMy5c/bhEjcUwL78gv
=+Plj
-----END PGP SIGNATURE-----