Re: multiarch and pkg-config
Peter Samuelson pe...@p12n.org writes: [Goswin von Brederlow] Then installing the i386 package on amd64 would create the symlink and make sources building for 64bit find the 32bit libraries. Verry bad idea. You completly missed the point. 1) People shouldn't be installing -dev packages from the wrong architecture. It is too early in the game to rely on that sort of thing yet. The point was to make the -dev package multiarch. That means installable for multiple architectures. While that is not a priority we were thinking ahead. 2) If some source package does not express a Build-Depends in such a way as to cause the correct architecture foo-dev package to be installed, I'd say that's a serious bug in either the source package, or the multi-arch design. The source Build-Depends on foo-dev and pkg-config. The problem is that a multiarch foo-dev then only works with a multiarch pkg-config. Normaly that would mean foo-dev Depends: pkg-config (= ver). But foo-dev does not depend on pkg-config as use of pkg-config is totaly optional. So foo-dev can express that version requirement on pkg-config other than Conflicts or Breaks. And adding that to (most) -dev packages would be ugly. 3) The dh_makeshlibs postinst logic _could_ only create the symlink if the architecture is the host architecture, however you detect that in multi-arch land. And indeed it could stop doing so if it detects that pkg-config is an appropriate version. Not everyone uses dh_makeshlibs and I would rather not see that logic in postinst scripts at all. That is the sort of thing multiarch was designed to not need. It is probably fine to fix pkg-config now and then later, maybe after squeeze, just assume it is new enough. Any early adopters that want to test multiarch -dev packages (in experimental) now can use Breaks. The -dev packages are not a high priority, unlike the libs themself, so there is time for a clean transition. That would only bother old-stable backports then. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
Josselin Mouette j...@debian.org writes: Le mercredi 03 février 2010 à 10:48 +0100, Goswin von Brederlow a écrit : If we want to support multiarch compilation, this sounds ok to me. I'm personally not convinced by the point of doing it. Though. We probably don't want multiarch compilation as such but cross compilation is a huge benfit for many people and multiarch dev packages would make it possible to cross compile without having to set a sysroot and without mangling packages during unpacking. Cross-compiling packages without a dedicated build root sounds like a very, very bad idea to me. The design of multiarch is so that you can install the arm deb on arm and compile or unpack it into a chroot and cross-compile or even install it in your real system and cross-compile there. The big change will be that you no longer need to compile a bunch of cross compile libraries but you can just use the debian packages as is. Also you probably want a build chroot. In there you need the native libs and tools and a cross-compiler. Do you then want to have a chroot in the chroot for the foreign libs? Or a single multiarch chroot for the native tools, cross-compiler and foreign libs? It also makes sense to compile sources with everything in the triplet dir. No point having the *.so link or .pc files in different libdirs. It is probably harder to not multiarchify the -dev packages as well. It is only marginally harder to make the .so symlink point to the .so.N in the arch-triplet directory. It is just the same as what is done with /lib. Setting the link different is simple. But then you need to edit the .pc file as well. It adds up. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
]] Hendrik Sattler Please don't send me copies, I'm subscribed and set my mail-followup-to as well as mail-copies-to. | Am Dienstag 02 Februar 2010 21:43:21 schrieb Tollef Fog Heen: | ]] Hendrik Sattler | | pkg-config actually does support relocation of the libraries but for a | | strange reason only on Windows. That means that for cross-compiling, | | you have to fixup all paths it returns. The patch would be trivial. | | Uhm, no. You make sure the generated .pc files are correct and it will | Just Work. | | The keyword here is _relocatable_ | With a hard-coded 'prefix', there is no correct. There's no way to generally support relocatable libraries and it's not something I'm interested in supporting, particularly not inside Debian. Just generate .pc files with the right prefix and you're good. | | The undocumented pcfiledir variable can be used to hack around it, | | probably better to convinve upstream to make pkg-config more | | cross-compile-friendly. Thus, it may be possible to a generic shell | | script as cross-pkg-config wrapper that does what you want (with many | | symlinks to make autotools happy). | | Feel free to try to convince me. | #!/bin/sh | | #find the GNU prefix | GNU_PREFIX=`basename $0 | sed -e 's/\(.*\)-pkg-config/\\1/'` | | #set the new search path for pkg-config | PKG_CONFIG_LIBDIR=/usr/lib/$GNU_PREFIX/pkgconfig:$PKG_CONFIG_LIBDIR | export PKG_CONFIG_LIBDIR This bit is fairly reasonable. | #get the location of the .pc file | PC_NONOPTS=`echo $@ | sed -e 's/\(--[^ ]* \)*//g'` | PC_FILEDIR=`pkg-config --variable=pcfiledir $PC_NONOPTS` | PC_RESULT=$? | test $PC_FILEDIR || exit $PC_RESULT This one is not, it won't work at all. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
Am Freitag 05 Februar 2010 09:04:45 schrieb Tollef Fog Heen: | #get the location of the .pc file | PC_NONOPTS=`echo $@ | sed -e 's/\(--[^ ]* \)*//g'` | PC_FILEDIR=`pkg-config --variable=pcfiledir $PC_NONOPTS` | PC_RESULT=$? | test $PC_FILEDIR || exit $PC_RESULT This one is not, it won't work at all. It does, at least for my use-case of pkg-config. Though I agree that this is not needed for you (only for relocation of libraries). But still, one simple wrapper is enough to support multiarch library dirs. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
[Goswin von Brederlow] Then installing the i386 package on amd64 would create the symlink and make sources building for 64bit find the 32bit libraries. Verry bad idea. 1) People shouldn't be installing -dev packages from the wrong architecture. It is too early in the game to rely on that sort of thing yet. 2) If some source package does not express a Build-Depends in such a way as to cause the correct architecture foo-dev package to be installed, I'd say that's a serious bug in either the source package, or the multi-arch design. 3) The dh_makeshlibs postinst logic _could_ only create the symlink if the architecture is the host architecture, however you detect that in multi-arch land. And indeed it could stop doing so if it detects that pkg-config is an appropriate version. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
Le mercredi 03 février 2010 à 10:48 +0100, Goswin von Brederlow a écrit : If we want to support multiarch compilation, this sounds ok to me. I'm personally not convinced by the point of doing it. Though. We probably don't want multiarch compilation as such but cross compilation is a huge benfit for many people and multiarch dev packages would make it possible to cross compile without having to set a sysroot and without mangling packages during unpacking. Cross-compiling packages without a dedicated build root sounds like a very, very bad idea to me. It also makes sense to compile sources with everything in the triplet dir. No point having the *.so link or .pc files in different libdirs. It is probably harder to not multiarchify the -dev packages as well. It is only marginally harder to make the .so symlink point to the .so.N in the arch-triplet directory. It is just the same as what is done with /lib. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: multiarch and pkg-config
Peter Samuelson pe...@p12n.org writes: [Goswin von Brederlow] But how would -dev packages signal that they need support for this? They do not depend on pkg-config as they are usable without. Should they Breaks: pkg-config ( ver)? Seems too strong. Alternatively, create a symlink into /usr/lib/pkgconfig/ in postinst, if one isn't already present. Indeed, dh_makeshlibs could do this in the same way it adds those 'ldconfig' calls. (Well, I suppose some shlib packages don't run dh_makeshlibs -s, instead using -p on each library package ... but they could if they wanted.) -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ Then installing the i386 package on amd64 would create the symlink and make sources building for 64bit find the 32bit libraries. Verry bad idea. I'm just missing a way to tell dpkg nicely: Depends: pkg-config (= 1.2-3) if something Build-Depends on me and pkg-config. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
]] Goswin von Brederlow | But how would -dev packages signal that they need support for this? They | do not depend on pkg-config as they are usable without. Should they | Breaks: pkg-config ( ver)? Seems too strong. Breaks sounds fine to me. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
Am Dienstag 02 Februar 2010 21:43:21 schrieb Tollef Fog Heen: ]] Hendrik Sattler | Am Dienstag 02 Februar 2010 16:14:27 schrieb Simon McVittie: | However, this would also require that pkg-config itself was multiarch | or otherwise supported cross-compilation | (/usr/bin/i486-linux-gnu-pkg-config, like AC_CHECK_TOOL would use? | pkg-config --arch=i486-linux-gnu? etc.); until then, it's not useful | for pkg-config-using libraries to be multiarch (if I have i386 and | amd64 versions of libdbus-1-dev, but only the one whose architecture | matches my version of pkg-config actually works, then I might as well | uninstall the other version of libdbus-1-dev). | | pkg-config actually does support relocation of the libraries but for a | strange reason only on Windows. That means that for cross-compiling, | you have to fixup all paths it returns. The patch would be trivial. Uhm, no. You make sure the generated .pc files are correct and it will Just Work. The keyword here is _relocatable_ With a hard-coded 'prefix', there is no correct. | The undocumented pcfiledir variable can be used to hack around it, | probably better to convinve upstream to make pkg-config more | cross-compile-friendly. Thus, it may be possible to a generic shell | script as cross-pkg-config wrapper that does what you want (with many | symlinks to make autotools happy). Feel free to try to convince me. #!/bin/sh #find the GNU prefix GNU_PREFIX=`basename $0 | sed -e 's/\(.*\)-pkg-config/\\1/'` #set the new search path for pkg-config PKG_CONFIG_LIBDIR=/usr/lib/$GNU_PREFIX/pkgconfig:$PKG_CONFIG_LIBDIR export PKG_CONFIG_LIBDIR #get the location of the .pc file PC_NONOPTS=`echo $@ | sed -e 's/\(--[^ ]* \)*//g'` PC_FILEDIR=`pkg-config --variable=pcfiledir $PC_NONOPTS` PC_RESULT=$? test $PC_FILEDIR || exit $PC_RESULT #we assume that the wanted prefix is the parent directory #of the directory where the .pc file was found PC_PREFIX=`dirname $PC_FILEDIR` exec pkg-config --define-variable=prefix=$PC_PREFIX $@ May that work as a preplacement for xxx-yyy-zzz-pkg-config? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
Tollef Fog Heen tfh...@err.no writes: ]] Simon McVittie | `pkg-config --debug 21 | grep i486` (on my i386) reveals that pkg-config | already looks in /usr/lib/pkgconfig/i486-linux-gnu; perhaps it could be made | to search /usr/lib/TRIPLET/pkgconfig too (hackish version: | /usr/lib/pkgconfig/TRIPLET could be a symlink there, on Debian). Yeah, I should probably change that around. It's just a configure option, and given I don't believe anybody uses the triplet dir today, I'll probably just move it. Seems simpler for sources as then setting libdir will do the right thing already. But how would -dev packages signal that they need support for this? They do not depend on pkg-config as they are usable without. Should they Breaks: pkg-config ( ver)? Seems too strong. | However, this would also require that pkg-config itself was multiarch or | otherwise supported cross-compilation (/usr/bin/i486-linux-gnu-pkg-config, | like AC_CHECK_TOOL would use? pkg-config --arch=i486-linux-gnu? etc.); until | then, it's not useful for pkg-config-using libraries to be multiarch (if | I have i386 and amd64 versions of libdbus-1-dev, but only the one whose | architecture matches my version of pkg-config actually works, then I might | as well uninstall the other version of libdbus-1-dev). | | I'd be interested to hear from Tollef what the plan is regarding pkg-config | and multiarch. I discussed this with Loïc Minier during UDS in Dallas and we did at least talk about using AC_CHECK_TOOL in pkg.m4. I'd then need to implement some magic in pkg-config which feels a bit hackish, but which I could live with. If somebody has feedback on the preferred way, I'm open to suggestions. There already seems to be a check in place at least in some sources. e.g cross building libxtst for arm: http://www.emdebian.org/buildd/?log=libxtst-arm-1216068648.logpkg=libxtst | checking for arm-linux-gnu-pkg-config... no | checking for pkg-config... /usr/bin/pkg-config | configure: WARNING: In the future, Autoconf will not detect cross-tools | whose name does not start with the host triplet. If you think this | configuration is useful to you, please write to autoc...@gnu.org. | checking pkg-config is at least version 0.9.0... yes | In the meantime, from the point of view of the multiarch cabal, which of these | is most correct? | | * pkg-config'd libraries should not be multiarch until pkg-config supports it, | but the .a, .so should go in /usr/lib/TRIPLET as soon as possible | | * pkg-config'd libraries should not be multiarch until pkg-config supports it, | and until then they should ensure that the .a, .so stay in /usr/lib | | * pkg-config'd libraries may do whichever of those is most straightforward If we want to support multiarch compilation, this sounds ok to me. I'm personally not convinced by the point of doing it. Though. We probably don't want multiarch compilation as such but cross compilation is a huge benfit for many people and multiarch dev packages would make it possible to cross compile without having to set a sysroot and without mangling packages during unpacking. It also makes sense to compile sources with everything in the triplet dir. No point having the *.so link or .pc files in different libdirs. It is probably harder to not multiarchify the -dev packages as well. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
[Goswin von Brederlow] But how would -dev packages signal that they need support for this? They do not depend on pkg-config as they are usable without. Should they Breaks: pkg-config ( ver)? Seems too strong. Alternatively, create a symlink into /usr/lib/pkgconfig/ in postinst, if one isn't already present. Indeed, dh_makeshlibs could do this in the same way it adds those 'ldconfig' calls. (Well, I suppose some shlib packages don't run dh_makeshlibs -s, instead using -p on each library package ... but they could if they wanted.) -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
Am Dienstag 02 Februar 2010 16:14:27 schrieb Simon McVittie: However, this would also require that pkg-config itself was multiarch or otherwise supported cross-compilation (/usr/bin/i486-linux-gnu-pkg-config, like AC_CHECK_TOOL would use? pkg-config --arch=i486-linux-gnu? etc.); until then, it's not useful for pkg-config-using libraries to be multiarch (if I have i386 and amd64 versions of libdbus-1-dev, but only the one whose architecture matches my version of pkg-config actually works, then I might as well uninstall the other version of libdbus-1-dev). pkg-config actually does support relocation of the libraries but for a strange reason only on Windows. That means that for cross-compiling, you have to fixup all paths it returns. The patch would be trivial. The undocumented pcfiledir variable can be used to hack around it, probably better to convinve upstream to make pkg-config more cross-compile-friendly. Thus, it may be possible to a generic shell script as cross-pkg-config wrapper that does what you want (with many symlinks to make autotools happy). HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
]] Simon McVittie | `pkg-config --debug 21 | grep i486` (on my i386) reveals that pkg-config | already looks in /usr/lib/pkgconfig/i486-linux-gnu; perhaps it could be made | to search /usr/lib/TRIPLET/pkgconfig too (hackish version: | /usr/lib/pkgconfig/TRIPLET could be a symlink there, on Debian). Yeah, I should probably change that around. It's just a configure option, and given I don't believe anybody uses the triplet dir today, I'll probably just move it. | However, this would also require that pkg-config itself was multiarch or | otherwise supported cross-compilation (/usr/bin/i486-linux-gnu-pkg-config, | like AC_CHECK_TOOL would use? pkg-config --arch=i486-linux-gnu? etc.); until | then, it's not useful for pkg-config-using libraries to be multiarch (if | I have i386 and amd64 versions of libdbus-1-dev, but only the one whose | architecture matches my version of pkg-config actually works, then I might | as well uninstall the other version of libdbus-1-dev). | | I'd be interested to hear from Tollef what the plan is regarding pkg-config | and multiarch. I discussed this with Loïc Minier during UDS in Dallas and we did at least talk about using AC_CHECK_TOOL in pkg.m4. I'd then need to implement some magic in pkg-config which feels a bit hackish, but which I could live with. If somebody has feedback on the preferred way, I'm open to suggestions. | In the meantime, from the point of view of the multiarch cabal, which of these | is most correct? | | * pkg-config'd libraries should not be multiarch until pkg-config supports it, | but the .a, .so should go in /usr/lib/TRIPLET as soon as possible | | * pkg-config'd libraries should not be multiarch until pkg-config supports it, | and until then they should ensure that the .a, .so stay in /usr/lib | | * pkg-config'd libraries may do whichever of those is most straightforward If we want to support multiarch compilation, this sounds ok to me. I'm personally not convinced by the point of doing it. Though. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
]] Hendrik Sattler | Am Dienstag 02 Februar 2010 16:14:27 schrieb Simon McVittie: | However, this would also require that pkg-config itself was multiarch or | otherwise supported cross-compilation (/usr/bin/i486-linux-gnu-pkg-config, | like AC_CHECK_TOOL would use? pkg-config --arch=i486-linux-gnu? etc.); | until then, it's not useful for pkg-config-using libraries to be multiarch | (if I have i386 and amd64 versions of libdbus-1-dev, but only the one | whose architecture matches my version of pkg-config actually works, then I | might as well uninstall the other version of libdbus-1-dev). | | pkg-config actually does support relocation of the libraries but for a | strange reason only on Windows. That means that for cross-compiling, | you have to fixup all paths it returns. The patch would be trivial. Uhm, no. You make sure the generated .pc files are correct and it will Just Work. | The undocumented pcfiledir variable can be used to hack around it, | probably better to convinve upstream to make pkg-config more | cross-compile-friendly. Thus, it may be possible to a generic shell | script as cross-pkg-config wrapper that does what you want (with many | symlinks to make autotools happy). Feel free to try to convince me. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
