Tim,
I traced the build failure to a Debian patch from Debian bug report 357775. The specific patch is 11_fix_get_libdir_name.diff, which can be viewed here, about midpoint in the page:
http://lists.alioth.debian.org/pipermail/pkg-kde-commits/2006-June/003702.ht...
I reversed the patch and then was able to build on 64-bit. Ignoring obvious file size differences, my 64-bit package looks exactly the same as my 32-bit package.
In my patch I added some informational text to help debugging because the specific build failure message appears in three different locations. Here is my proposed patch:
=========================================================== diff -urN pytdeextensions/setup.py pytdeextensions.new/setup.py --- pytdeextensions/setup.py 2012-05-27 17:59:26.000000000 -0500 +++ pytdeextensions.new/setup.py 2012-06-13 20:12:18.000000000 -0500 @@ -135,7 +135,7 @@ if self.clib!=None: self.clib = glob.glob(os.path.join(self.clib,'libgcc*.a'))[0] if self.clib is None: - raise SystemExit, "Failed to find a suitable libgcc library" + raise SystemExit, "setup.py: Failed to find a suitable libgcc library" self.announce("Using %s for clib" % self.clib)
# Make a list of places to look for python .so modules diff -urN pytdeextensions/src/kdedistutils.py pytdeextensions.new/src/kdedistutils.py --- pytdeextensions/src/kdedistutils.py 2012-06-13 11:01:28.000000000 -0500 +++ pytdeextensions.new/src/kdedistutils.py 2012-06-13 20:17:43.000000000 -0500 @@ -660,7 +660,7 @@ if self.clib!=None: self.clib = glob.glob(os.path.join(self.clib,'libgcc*.a'))[0] if self.clib is None: - raise SystemExit, "Failed to find a suitable libgcc library" + raise SystemExit, "kdedistutils.py (1): Failed to find a suitable libgcc library" self.announce("Using %s for clib" % self.clib)
# Make a list of places to look for python .so modules @@ -1591,7 +1591,7 @@ if self.clib!=None: self.clib = glob.glob(os.path.join(self.clib,'libgcc*.a'))[0] if self.clib is None: - raise SystemExit, "Failed to find a suitable libgcc library" + raise SystemExit, "kdedistutils.py (2): Failed to find a suitable libgcc library" self.announce("Using %s for clib" % self.clib)
# Make a list of places to look for python .so modules @@ -2229,7 +2229,7 @@
########################################################################### def get_libdir_name(): - #if os.uname()[4] in ['x86_64','mips64','ppc64','sparc64','s390x']: - # return 'lib64' - #else: + if os.uname()[4] in ['x86_64','mips64','ppc64','sparc64','s390x']: + return 'lib64' + else: return 'lib' ===========================================================
Do you want me to push this patch to GIT or do you want to first run a Debian/Ubuntu test build?
Darrell
Tim,
I traced the build failure to a Debian patch from Debian bug report 357775. The specific patch is 11_fix_get_libdir_name.diff, which can be viewed here, about midpoint in the page:
http://lists.alioth.debian.org/pipermail/pkg-kde-commits/2006-June/003702.ht...
I reversed the patch and then was able to build on 64-bit. Ignoring obvious file size differences, my 64-bit package looks exactly the same as my 32-bit package.
<snip>
Push it. That patch should never have found its way into GIT in the first place.
Tim
I traced the build failure to a Debian patch from Debian bug report 357775. The specific patch is 11_fix_get_libdir_name.diff, which can be viewed here, about midpoint in the page:
http://lists.alioth.debian.org/pipermail/pkg-kde-commits/2006-June/003702.ht...
I reversed the patch and then was able to build on 64-bit. Ignoring obvious file size differences, my 64-bit package looks exactly the same as my 32-bit package.
Push it. That patch should never have found its way into GIT in the first place.
Pushed in GIT hash 32d597f9.
Darrell
On 14 Jun 2012, Darrell Anderson outgrape:
- if os.uname()[4] in ['x86_64','mips64','ppc64','sparc64','s390x']:
return 'lib64'
- else: return 'lib'
This is distro-specific. A significant number of distros (even those not using multiarch) put 64-bit libraries into lib/ and 32-bit libraries into lib32/.
Can't you use a configure- or cmake-driven libdir here? That'll always be right.
On 14 June 2012 11:51, Nix nix@esperi.org.uk wrote:
On 14 Jun 2012, Darrell Anderson outgrape:
- if os.uname()[4] in ['x86_64','mips64','ppc64','sparc64','s390x']:
- return 'lib64'
- else:
return 'lib'
This is distro-specific. A significant number of distros (even those not using multiarch) put 64-bit libraries into lib/ and 32-bit libraries into lib32/.
Can't you use a configure- or cmake-driven libdir here? That'll always be right.
Yes, archlinux does this.
It seems to make sense to only use /lib64 or lib32 when that is not the native arch. ( you wouldn't say /bin32 if you're on a 32 bit system)
Calvin
On 14 Jun 2012, Calvin Morrison stated:
It seems to make sense to only use /lib64 or lib32 when that is not the native arch. ( you wouldn't say /bin32 if you're on a 32 bit system)
Debian (and I) agree with you. RH et al do not :(
(though binaries are a different matter. You very rarely have two versions of the same binary, one 32-bit and one 64-bit, so one directory will suffice in any case. This situation is downright common with libraries, so two directories are essential.)
- if os.uname()[4] in ['x86_64','mips64','ppc64','sparc64','s390x']:
return 'lib64'
- else: return 'lib'
This is distro-specific. A significant number of distros (even those not using multiarch) put 64-bit libraries into lib/ and 32-bit libraries into lib32/.
Can't you use a configure- or cmake-driven libdir here? That'll always be right.
Yes, archlinux does this.
It seems to make sense to only use /lib64 or lib32 when that is not the native arch. ( you wouldn't say /bin32 if you're on a 32 bit system)
Okay, so we need to allow the old patch for some distros and remove the patch for others. Would one of you two create a proper patch for the problem? One that allows supporting all distros?
Darrell
On 15 Jun 2012, Darrell Anderson uttered the following:
Okay, so we need to allow the old patch for some distros and remove the patch for others. Would one of you two create a proper patch for the problem? One that allows supporting all distros?
Unfortunately because python-trinity is neither a configure nor a cmake-using project, it's hard :( however it is reasonable to do it by inspecting the system configuration, and assuming that if /usr/lib32 exists then we want a 64-bit lib and a 32-bit lib32. (You cannot do the opposite and look for lib64, because a some distros have a lib32, a lib64 *and* a lib, with one of those being a symlink to one of the others: but in all such cases that I am aware of, lib is 64-bit.)
(Why yes, this *is* a bloody mess. Bring on Debian-style multiarch! Which would mean more changes to python-trinity of course.)