Bug#467069: pango1.0: biarch support
On Tue, Feb 26, 2008, Javier Serrano Polo wrote: Would you propose glibc maintainers that libc6-i386 package should ship /etc/ld.so.conf.d/i486-linux-gnu.conf and the /lib/i486-linux-gnu and /usr/lib/i486-linux-gnu symlinks then? Not sure; perhaps this should simply be done when the personality is 32-bits (linux32 blahblah). -- Loïc Minier
Bug#467069: pango1.0: biarch support
On Sun, Feb 24, 2008, Javier Serrano Polo wrote: El dg 24 de 02 del 2008 a les 11:22 +0100, en/na Loïc Minier va escriure: Ok, but why not using usr/lib/$(DEB_HOST_GNU_TYPE)? There's no package using usr/lib/i486-linux-gnu or usr/lib/x86_64-linux-gnu. Those paths are even incorrect, compilation on amd64 would need overriding DEB_HOST_GNU_TYPE. And I won't use ../lib32. I'm not sure you're aware of what multiarch is about: it's not about building 32-bits packages under 64-bits or vice-versa, it's about having parallel installable libs for all arches. So you could even have an arm pango installed if you have a way to run arm binaries such as qemu-arm. The pathnames are not a pango1.0 invention, these have been agreed upon already; if you're running Debian, you probably have something like /etc/ld.so.conf.d/i486-linux-gnu or /etc/ld.so.conf.d/x86_64-linux-gnu.conf telling the runtime linker about these libs. (I don't understand your remark about ../lib32.) Your ld.so should find the libs and the modules should be found by pango. What's preventing you to use the multiarch pathnames or why are you insisting on using /usr/lib32 / the biarch pathnames? /usr/lib32 works, it's tested. It's standard. It's the one currently used by Debian; either this or /emul/ia32-linux/usr/lib. On the other hand, what's preventing the use of DEB_BUILD_OPTIONS=arch32bit? What packages are using usr/lib/$(DEB_HOST_GNU_TYPE)? As I explained in my first reponse, multiarch is a superset of biarch; biarch works, multiarch works; it would be quite complex to have a multiarch *and* a biarch version of pango, so I'd prefer not mixing these. Why is it needed? (What's the rpath pointing to and why is it problematic?) The rpath points to /usr/lib32. That shouldn't be a problem, but lintian complains because rpath is deprecated in Debian. Perhaps you already know this: http://wiki.debian.org/RpathIssue Ok, I was wondering whether you were required to strip this RPATH to fix a particular runtime issue; one way to fix it is to strip it like you did (I would expect libtool to not generate this RPATH if it properly supports biarch though, but I'm not interested in investigating), and it's nice for policy compliance. Yes, I know about the RpathIssue; the most common one is the other way around (/usr/lib64 being considered the standard and /usr/lib RPATHes being generated) which causes great trouble to enforce LD_LIBRARY_PATH on amd64, but that's another story. -- Loïc Minier
Bug#467069: pango1.0: biarch support
El dl 25 de 02 del 2008 a les 11:17 +0100, en/na Loïc Minier va escriure: The pathnames are not a pango1.0 invention, these have been agreed upon already; if you're running Debian, you probably have something like /etc/ld.so.conf.d/i486-linux-gnu or /etc/ld.so.conf.d/x86_64-linux-gnu.conf telling the runtime linker about these libs. Would you propose glibc maintainers that libc6-i386 package should ship /etc/ld.so.conf.d/i486-linux-gnu.conf and the /lib/i486-linux-gnu and /usr/lib/i486-linux-gnu symlinks then? (I don't understand your remark about ../lib32.) LIBDIR=/usr/lib/../lib32, never mind. I'll test your (potential) proposal.
Bug#467069: pango1.0: biarch support
It works and I can repackage it easily now. There are two lintian warnings, but I think they're false positives. I think future enhancements deserve their own bug. If you agree I'll close this one. I wonder however why the path is /usr/lib/host-type instead of /usr/share/host-type since all architectures should be able to handle the same files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467069: pango1.0: biarch support
On Sat, Feb 23, 2008, Javier Serrano Polo wrote: Well isn't DEB_BUILD_OPTIONS=multiarch doing what you want?! No, it sets usr/lib/$(DEB_HOST_GNU_TYPE) instead of usr/lib32. Ok, but why not using usr/lib/$(DEB_HOST_GNU_TYPE)? Your ld.so should find the libs and the modules should be found by pango. What's preventing you to use the multiarch pathnames or why are you insisting on using /usr/lib32 / the biarch pathnames? If you can pass params to debian/rules binary, you can also try overriding LIBDIR directly: fakeroot debian/rules binary LIBDIR=usr/lib32 (or MODULES_PATH, MODULE_FILES_D etc.; see pango1.0's debian/rules) That would do the trick. Is there a way to pass params from dpkg-buildpackage to debian/rules? No, you can by hand... :) Then I'd only need to add the extra chrpath call to keep lintian happy (attached). Why is it needed? (What's the rpath pointing to and why is it problematic?) -- Loïc Minier
Bug#467069: pango1.0: biarch support
El dg 24 de 02 del 2008 a les 11:22 +0100, en/na Loïc Minier va escriure: Ok, but why not using usr/lib/$(DEB_HOST_GNU_TYPE)? There's no package using usr/lib/i486-linux-gnu or usr/lib/x86_64-linux-gnu. Those paths are even incorrect, compilation on amd64 would need overriding DEB_HOST_GNU_TYPE. And I won't use ../lib32. Your ld.so should find the libs and the modules should be found by pango. What's preventing you to use the multiarch pathnames or why are you insisting on using /usr/lib32 / the biarch pathnames? /usr/lib32 works, it's tested. It's standard. It's the one currently used by Debian; either this or /emul/ia32-linux/usr/lib. On the other hand, what's preventing the use of DEB_BUILD_OPTIONS=arch32bit? What packages are using usr/lib/$(DEB_HOST_GNU_TYPE)? Why is it needed? (What's the rpath pointing to and why is it problematic?) The rpath points to /usr/lib32. That shouldn't be a problem, but lintian complains because rpath is deprecated in Debian. Perhaps you already know this: http://wiki.debian.org/RpathIssue
Bug#467069: pango1.0: biarch support
On Fri, Feb 22, 2008, Javier Serrano Polo wrote: Going back to the rebuild, I'd need a simple way to set the library path through DEB_BUILD_OPTIONS. pango1.0 is almost done. Packages gtk+2.0 and libao have the same problem (and probably 22 more packages). I'd like to know if I can count on you to help or accept my help, so I can automate this more reliably. Well isn't DEB_BUILD_OPTIONS=multiarch doing what you want?! If you can pass params to debian/rules binary, you can also try overriding LIBDIR directly: fakeroot debian/rules binary LIBDIR=usr/lib32 (or MODULES_PATH, MODULE_FILES_D etc.; see pango1.0's debian/rules) I still don't quite understand what your problem is, so that's a barrier to accepting the patches, but I welcome patches in general! ;) -- Loïc Minier
Bug#467069: pango1.0: biarch support
El ds 23 de 02 del 2008 a les 13:14 +0100, en/na Loïc Minier va escriure: Well isn't DEB_BUILD_OPTIONS=multiarch doing what you want?! No, it sets usr/lib/$(DEB_HOST_GNU_TYPE) instead of usr/lib32. If you can pass params to debian/rules binary, you can also try overriding LIBDIR directly: fakeroot debian/rules binary LIBDIR=usr/lib32 (or MODULES_PATH, MODULE_FILES_D etc.; see pango1.0's debian/rules) That would do the trick. Is there a way to pass params from dpkg-buildpackage to debian/rules? Then I'd only need to add the extra chrpath call to keep lintian happy (attached). --- pango1.0-1.18.4.orig/debian/rules 2008-02-23 13:55:50.0 +0100 +++ pango1.0-1.18.4/debian/rules 2008-02-21 00:18:38.0 +0100 @@ -238,6 +238,9 @@ # /usr/lib; see #432258 chrpath -d debian/$(UDEB_PKG)/$(LIBDIR)/*.so.* \ debian/$(UDEB_PKG)/$(MODULES_PATH)/*.so + # remove the rpath in more libs and modules + chrpath -d debian/$(SHARED_PKG)/$(LIBDIR)/*.so.* \ + debian/$(SHARED_PKG)/$(MODULES_PATH)/*.so # Remove the thai module to avoid extraneous dependencies rm -f debian/$(UDEB_PKG)/$(MODULES_PATH)/pango-thai-lang.so # empty the dependency_libs in the *.la files
Bug#467069: pango1.0: biarch support
Package: pango1.0 Version: 1.18.4-1 Severity: wishlist El dj 21 de 02 del 2008 a les 21:03 +0100, en/na Loïc Minier va escriure: On Thu, Feb 21, 2008, Javier Serrano Polo wrote: I'm working on ia32 libraries support and I had to recompile pango, using a different library path and an extra chrpath call. Hmm you shouldn't have to rebuild; copying the i386 build into ia32-libs is supposed to work. I should note first I'm not using ia32-libs, ia32-libs-gtk or any other library compilation. I'm using each library with its own package, preserving dependencies. The scheme is initially described in #464796. While most packages work out of the i386 box, by simple repackage, others make use of modules or private libraries. These are accessed through hard coded paths, so I need to configure with a different library path. I'm using /usr/lib32 instead of /emul/ia32-linux/usr/lib because it should be portable to other 32 bit archs. The final solution would be to build two new flavors (e.g., shared32 and static32) but I need to get the dependencies in first. This was considered when multiarch was implemented, but it was considered: - complex and messy, especially with multiarch at the same time - useless if we get multiarch The paths I mentioned are currently working, even /usr/lib32 is standard. I don't have any sign of another multiarch approach. Please correct me if I'm wrong. Anyway, I'll freeze the new flavors topic. It's useless without the needed dependencies. Going back to the rebuild, I'd need a simple way to set the library path through DEB_BUILD_OPTIONS. pango1.0 is almost done. Packages gtk+2.0 and libao have the same problem (and probably 22 more packages). I'd like to know if I can count on you to help or accept my help, so I can automate this more reliably.
