FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-02-2010, 02:14 PM
Simon McVittie
 
Default multiarch and pkg-config

On Tue, 02 Feb 2010 at 14:22:49 +0100, Goswin von Brederlow wrote:
> You can move headers, the *.so link and static libs. But .pc and .la
> files can not be in the triplet dir yet afaik. So that is a no go for
> now. But if you want you can try and see what changes libtool and
> pkgconfig would need for this.

Removing .la files (in the right order, leaf packages first) is a release goal
anyway, so I think it would be reasonable to say that only -dev packages that
have already lost their .la files (like dbus) can be multiarch.

`pkg-config --debug 2>&1 | 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).

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.

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

> /usr/include/triplet is at least preferable to
> /usr/lib/triplet/package/include as the former is in the default include
> path and works without -I option.

That defeats the purpose of using the dbus-1.0 subdirectory, which is precisely
to *not* be on the default inclusion path, for parallel-installability across
some future API break, perhaps to dbus-1.5 or dbus-2.0 or something (D-Bus
hasn't needed to do this, but the migration from Gtk 1.2 to 2.0 did, and
Qt 3 -> 4 appears to do the same).

Whether you personally consider this design broken or not, it exists and is
widespread, and multiarch should cope; the major advantage is that it avoids
the need for the mutual Conflicts seen in e.g. libdb4.x-dev.

In cases where an API-specific subdirectory is used by upstream for that
purpose, sticking to upstream's choice of
/usr/lib/TRIPLET/PACKAGE-API/include vs. /usr/include/TRIPLET/PACKAGE-API
is considerably easier than not, and I don't really see a technical argument
one way or the other when the default -I path is no longer relevant; is
there one that I'm missing?

> > (Some concrete examples: GLib and GDK also have one arch-specific header in
> > ${libdir} each; expat is one of several with a version of config.h in
> > /usr/include; Python has pyconfig.h in a /usr/include subdirectory.)
>
> Most of /usr/lib/glib-2.0/include/glibconfig.h is already arch
> independent or can trivialy be rewritten as such using C99.

GLib upstream supports pre-C99 compilers, so that's unlikely to be feasible
(unless you want Debian to fork GLib, which seems like a recipe for disaster).

Regards,
Simon


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-02-2010, 06:32 PM
Hendrik Sattler
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-02-2010, 07:24 PM
Tollef Fog Heen
 
Default multiarch and pkg-config

]] Simon McVittie

| `pkg-config --debug 2>&1 | 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 Loc 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-02-2010, 07:43 PM
Tollef Fog Heen
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-03-2010, 08:48 AM
Goswin von Brederlow
 
Default multiarch and pkg-config

Tollef Fog Heen <tfheen@err.no> writes:

> ]] Simon McVittie
>
> | `pkg-config --debug 2>&1 | 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.log&pkg=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 autoconf@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-03-2010, 10:29 PM
Peter Samuelson
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-04-2010, 04:37 PM
Goswin von Brederlow
 
Default multiarch and pkg-config

Peter Samuelson <peter@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-04-2010, 05:11 PM
Tollef Fog Heen
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-04-2010, 08:19 PM
Hendrik Sattler
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-05-2010, 07:04 AM
Tollef Fog Heen
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 09:43 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org