I am in the process of trying to build fedora on ia64. I updated to the latest mock today in order to get the new --copyin functionality which I think will help with a lot of the dependency issues I am having (very cool functionality by the way!).
However, I have found that other changes made at some point after mock-0.7.6-1 breaks mock on ia64.
The problem is it tries to load the libc.so.6 library. On ia64 this does not exist since it uses libc.so.6.1 (FYI, that is the case both on F8 and on RHEL5 for ia64). This also concerns me since if the version of the library changes mock will cease to work on other platforms as well.
This bit of code is in both util.py and uid.py:
import ctypes _libc = ctypes.cdll.LoadLibrary("libc.so.6")
If I change it to libc.so.6.1 on my ia64 system it works OK. I tried just specifying libc.so but python is very unhappy about that (I tried that on x86_64 also and it is also unhappy with libc.so).
Does anybody have ideas on how we can make this more portable?
thanks,
- Doug
On Wed, 19 Dec 2007 15:49:47 -0500, Doug Chapman wrote:
Does anybody have ideas on how we can make this more portable?
The path to libc.so.6* is in libc.so: $ cat /usr/lib/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-ia64-little) GROUP ( /lib/libc.so.6.1 /usr/lib/libc_nonshared.a )
: cat /usr/lib64/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) )
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".
Thanks, Roland
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.
thanks,
- Doug
diff -up mock-0.9.3/py/mock/uid.py.broken mock-0.9.3/py/mock/uid.py --- mock-0.9.3/py/mock/uid.py.broken 2007-12-20 09:23:05.000000000 -0500 +++ mock-0.9.3/py/mock/uid.py 2007-12-20 09:23:26.000000000 -0500 @@ -70,7 +70,7 @@ class uidManager(object): # python doesnt have native versions of these. :(
import ctypes -_libc = ctypes.cdll.LoadLibrary("libc.so.6") +_libc = ctypes.cdll.LoadLibrary(None) _errno = ctypes.c_int.in_dll(_libc, "errno")
def getresuid(): diff -up mock-0.9.3/py/mock/util.py.broken mock-0.9.3/py/mock/util.py --- mock-0.9.3/py/mock/util.py.broken 2007-12-20 09:22:57.000000000 -0500 +++ mock-0.9.3/py/mock/util.py 2007-12-20 09:23:15.000000000 -0500 @@ -193,7 +193,7 @@ personality_defs = { }
import ctypes -_libc = ctypes.cdll.LoadLibrary("libc.so.6") +_libc = ctypes.cdll.LoadLibrary(None) _errno = ctypes.c_int.in_dll(_libc, "errno") _libc.personality.argtypes = [ctypes.c_ulong] _libc.personality.restype = ctypes.c_int
-----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
On Sat, Dec 22, 2007 at 03:47:10PM -0600, Clark Williams wrote:
-----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.
I didnt see this pushed to the git repo, so I just pushed it. This is now in upstream git and will make it into the next fedora push. I dont have solid plans for another fedora push yet, unless Clark wants to do one.
Thanks for the patch. -- Michael
On 12/19/2007 09:49 PM, Doug Chapman wrote:
I am in the process of trying to build fedora on ia64. I updated to the latest mock today in order to get the new --copyin functionality which I think will help with a lot of the dependency issues I am having (very cool functionality by the way!).
However, I have found that other changes made at some point after mock-0.7.6-1 breaks mock on ia64.
The problem is it tries to load the libc.so.6 library. On ia64 this does not exist since it uses libc.so.6.1 (FYI, that is the case both on F8 and on RHEL5 for ia64). This also concerns me since if the version of the library changes mock will cease to work on other platforms as well.
This bit of code is in both util.py and uid.py:
import ctypes _libc = ctypes.cdll.LoadLibrary("libc.so.6")
If I change it to libc.so.6.1 on my ia64 system it works OK. I tried just specifying libc.so but python is very unhappy about that (I tried that on x86_64 also and it is also unhappy with libc.so).
Does anybody have ideas on how we can make this more portable?
I just want to mention, that the same is true for alpha!
-of
buildsys@lists.fedoraproject.org
-
Christian Iseli -
Clark Williams -
Doug Chapman -
Michael E Brown -
Oliver Falk -
Roland McGrath