Bug#643341: [pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
Control: close 643341 1.33-3 hi all-- libgpg-error 1.33 is now in unstable, and it ships a pkg-config file. Thanks to NIIBE for all his work on this! as of 1.33-3, i'vem also added an autopkgtest that uses the pkg-config file to ensure that a simple build works as expected. Could any of the folks who found older versions of gpg-error painful for cross-compiling take a crack at using this version for their cross-compilation? I'm closing this bug report because i think the pkg-config file solves the problem for cross-compilation to other debian architectures. If it doesn't solve the problem for you, then please reopen the bug and explain more. All the best, --dkg signature.asc Description: PGP signature
Bug#643341: [pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
Simon McVittie wrote:
> The multiarch tuple used to form ${libdir} on Debian is not always
> identical to the GNU host.
[...]
> There's a Debian-specific option "gcc -print-multiarch" added by a
> Debian patch, although not all of our compilers have a similar patch
> (gcc does but clang doesn't).
I see. Thanks for your teaching. I realized that there are more detail
than I had expected.
Today, I updated the change [0] to allow CC as one of clang. I'm going
to push this change, soon.
My intention is to show our support making gpg-error-config script
architecture independent on multiarch environment, to avoid having many
-gpg-error-config scripts. I wish we will have co-installable
libgpg-error-dev:amd64 and libgpg-error-dev:i386 on Debian, and we won't
need any change for gpg-error.m4 (and updating it in several packages).
Now, I think that more changes (Debian specific) are better to be left
to Debian Maintainer of libgpg-error.
FYI, upstream discussion is here [1].
[0] https://dev.gnupg.org/D467
[1] https://dev.gnupg.org/T4085
--
Bug#643341: [pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
On Wed, 17 Oct 2018 at 14:31:50 +0900, NIIBE Yutaka wrote:
> At configure time, if it detects libdir for multiarch, it lets
> gpg-error-config script architecture independent to dynamically define
> PKG_CONFIG_LIBDIR (by CC or gcc -dumpmachine).
The multiarch tuple used to form ${libdir} on Debian is not always
identical to the GNU host. On some architectures (mainly i386 and the
32-bit ARM family) it's a normalized form of the GNU host, using the
oldest or most generic compatible CPU: for instance Debian i386:
% dpkg-architecture -ai386 -qDEB_HOST_MULTIARCH
i386-linux-gnu
# in current Debian/Ubuntu (older Debian used i486, i586 here)
# same as gcc -dumpmachine
% dpkg-architecture -ai386 -qDEB_HOST_GNU_TYPE
i686-linux-gnu
and similarly the multiarch tuple for 32-bit ARM is something like
arm-linux-gnueabi, not armv5tel-linux-gnueabi.
There's a Debian-specific option "gcc -print-multiarch" added by a
Debian patch, although not all of our compilers have a similar patch
(gcc does but clang doesn't).
I think it would probably be better for Debian to patch
src/gpg-error-config-new.in in our version of gpg-error, rather than
trying to solve this generically upstream, because we can make a lot
more assumptions about install paths than you can.
smcv
Bug#643341: [pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
Hello, again,
Simon McVittie wrote:
> For Debian, I wonder whether we might be able to patch the script to
> remove this part, which looks like the only architecture variation:
>
> prefix=@prefix@
> exec_prefix=@exec_prefix@
> libdir=${PKG_CONFIG_LIBDIR:-@libdir@}
> PKG_CONFIG_PATH="$PKG_CONFIG_PATH${PKG_CONFIG_PATH:+:}${libdir}/pkgconfig"
How about a change like this?
https://dev.gnupg.org/D467
At configure time, if it detects libdir for multiarch, it lets
gpg-error-config script architecture independent to dynamically define
PKG_CONFIG_LIBDIR (by CC or gcc -dumpmachine).
With this, we don't need to have -gpg-error-config.
--
Bug#643341: [pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
Hello,
Thanks for your explanation. I learn.
Let me explain from GnuPG development side. We care traditional UNIXen
and unusual OSes. (minimum version of) GnuPG should be able to be built
and installed in early stage of development.
Simon McVittie wrote:
> Control: tags -1 - wontfix
OK.
> That will fix cross-compilation if dependent packages are changed to
> use (for example) PKG_CHECK_MODULES([GPG_ERROR], [gpg-error >= 1.33])
> instead of AM_PATH_GPG_ERROR([1.33]).
Yup. That is my intention.
But... please note that, we don't have an idea doing like that for GnuPG
and its friends. For building GnuPG, pkg-config (or its alternatives)
should not be one of requirements.
> Is
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=blob;f=src/gpg-error-config-new.in
> the new script?
Yes.
> It's very unusual to parse .pc files "by hand" like this.
I know. Someone has to do unusual thing to break a tie. I don't think
it's a good solution, but it makes sense in this situation. Ugly
compromise, but I did my best to provide gpg-error.pc from upstream.
> The usual way to consume .pc files is to run pkg-config (the reference
> implementation in C) or pkgconf (a reimplementation in Perl).
Perhaps, you mean PkgConfig. It seems it lacks PKG_CONFIG_SYSROOT_DIR
support.
There is another alternative, pkgconf in FreeBSD. This looks easier
to build.
> For Debian, I wonder whether we might be able to patch the script to
> remove this part, which looks like the only architecture variation:
>
> prefix=@prefix@
> exec_prefix=@exec_prefix@
> libdir=${PKG_CONFIG_LIBDIR:-@libdir@}
> PKG_CONFIG_PATH="$PKG_CONFIG_PATH${PKG_CONFIG_PATH:+:}${libdir}/pkgconfig"
For Debian, where we can assume good environment, package maintainer(s)
can do many things. I'd suggest something like:
(1) Having architecture independent -dev package _and_
architecture dependent -dev package,
(2) by installing original gpg-error-config as
-gpg-error-config,
(3) ... and installing Debian specific gpg-error-config
which detects architecture dependent path dynamically.
Just an idea. I don't know this feasibility.
> This is not usually possible. If I run gpg-error-config, for example like
> this:
>
> https://sources.debian.org/src/deja-dup/38.0-1/meson.build/?hl=60#L60
>
> how do you know which architecture I wanted?
Should libdir have the triplet in multiarch environment?
Or simply invoking 'dpkg-architecture -qDEB_HOST_GNU_TYPE'?
* * *
These posts from me are basically to inform forthcoming upstream
changes. I don't insist changes for Debian packaging. It's up to
Debian.
On the other hand, we are welcom to improve libgpg-error to be Debian
friendly (but not Debian specific).
--
Bug#643341: [pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
On Tue, 16 Oct 2018 09:51, s...@debian.org said: > However, none of this solves co-installability in Debian: > libgpg-error-dev:amd64 and libgpg-error-dev:armhf can't be > installed at the same time, because they have different content in > /usr/bin/gpg-error-config, and that will be a problem for as long as /usr/bin/gpg-error-config should only be used for native building. For cross-building it is expected that a dedicated gpg-error-config script is installed in the root directory of the host platform (e.g. as /usr/i686-w64-mingw32/bin/gpg-error-config) and only that gpg-error-config should ever be considered. In past this required manual configuration but meanwhile SYSROOT seems to be an accepted standard and we can make use of it. This means to only look there for the config script to get the right version and not take whatever we find and only print a warning if the platform is wrong. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp3e0bdhz6hy.pgp Description: PGP signature
Bug#643341: [pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
Control: tags -1 - wontfix
On Tue, 16 Oct 2018 at 10:00:03 +0900, NIIBE Yutaka wrote:
> Simon McVittie wrote:
> > The wontfix tag was because upstream are not willing to add pkg-config
> > metadata
>
> It was. Now, it has been changed.
Removing the tag, then. Thanks!
> In the next version of libgpg-error (1.33), we will offer gpg-error.pc
> (if nothing is going wrong). I believe this change helps
> cross-compiling other packages with libgpg-error.
It does help. Thank you for reconsidering this! The macros in pkg.m4
look for -pkg-config before pkg-config, and in Debian,
-pkg-config is created by a dpkg hook that sets up the search
path correctly for the host architecture, so everything
automatically works as it should.
That will fix cross-compilation if dependent packages are changed to
use (for example) PKG_CHECK_MODULES([GPG_ERROR], [gpg-error >= 1.33])
instead of AM_PATH_GPG_ERROR([1.33]).
If you are willing to change the implementation of AM_PATH_GPG_ERROR
and AM_PATH_GPGRT, then it would be possible to make them use
PKG_CHECK_MODULES, something like this:
PKG_CHECK_EXISTS(
[gpg-error >= $min_gpg_error_version],
[
dnl Found via pkg-config.
dnl Populate GPG_ERROR_CFLAGS, GPG_ERROR_LIBS
PKG_CHECK_MODULES([GPG_ERROR], [gpg-error >= $min_gpg_error_version])
dnl Populate gpg-error-specific extra variables
PKG_CHECK_VAR([GPG_ERROR_MT_CFLAGS], [gpg-error], [mtcflags])
GPG_ERROR_MT_CFLAGS="$GPG_ERROR_CFLAGS${GPG_ERROR_CFLAGS:+
}$GPG_ERROR_MT_CFLAGS"
PKG_CHECK_VAR([GPG_ERROR_MT_LIBS], [gpg-error], [mtlibs])
GPG_ERROR_MT_LIBS="$GPG_ERROR_LIBS${GPG_ERROR_LIBS:+
}$GPG_ERROR_MT_LIBS"
]
dnl
[
dnl Not found via pkg-config
... The old implementation using gpg-error-config ...
])
However, none of this solves co-installability in Debian:
libgpg-error-dev:amd64 and libgpg-error-dev:armhf can't be
installed at the same time, because they have different content in
/usr/bin/gpg-error-config, and that will be a problem for as long as
gpg-error-config exists. That's what I was trying to address on this
bug. I don't think this can be fully solved upstream, but patches like
the ones I sent earlier can at least solve it for Debian (because knowing
we're using a Debian package lets us make some assumptions that wouldn't
be valid upstream, like gpg-error being installed into /usr).
> Currently, in our development version (to be 1.33), gpg-error-config
> script itself is not architecture independent (having architecture
> dependent string), because it needs to find the gpg-error.pc file in
> architecture dependent path, just like pkg-config does.
Is
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=blob;f=src/gpg-error-config-new.in
the new script?
It's very unusual to parse .pc files "by hand" like this. The usual way
to consume .pc files is to run pkg-config (the reference implementation
in C) or pkgconf (a reimplementation in Perl).
For Debian, I wonder whether we might be able to patch the script to
remove this part, which looks like the only architecture variation:
prefix=@prefix@
exec_prefix=@exec_prefix@
libdir=${PKG_CONFIG_LIBDIR:-@libdir@}
PKG_CONFIG_PATH="$PKG_CONFIG_PATH${PKG_CONFIG_PATH:+:}${libdir}/pkgconfig"
and replace it with something more like this:
PKG_CONFIG_PATH="$(PKG_CONFIG:-pkg-config) --variable=pc_path pkg-config"
because we know that Debian packages install their .pc files into
pkg-config's default search path anyway? But I'm not sure whether that
will give the right answer when cross-compiling.
> I'm not sure if it's worth to have -gpg-error-config command,
> when we have gpg-error.pc.
In any case that would only be useful if AM_PATH_GPG_ERROR was changed
to look for it with AC_PATH_TOOL instead of AC_PATH_PROG; and if you're
going to change the implementation of AM_PATH_GPG_ERROR, it would
probably be better to change it to try using pkg-config in preference
to gpg-error-config.
>From https://codesearch.debian.net/search?q=gpg-error-config=1 it
looks as though libaacs and libassuan already have a (patched?) version
of gpg-error.m4 that uses AC_PATH_TOOL, so they are already trying to
find -gpg-error-config before falling back to gpg-error-config?
> Nevertheless, I think that it is possible to improve gpg-error-config
> script to detect architecture dependent path dynamically
This is not usually possible. If I run gpg-error-config, for example like
this:
https://sources.debian.org/src/deja-dup/38.0-1/meson.build/?hl=60#L60
how do you know which architecture I wanted?
smcv
Bug#643341: [pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
Simon McVittie wrote: > The wontfix tag was because upstream are not willing to add pkg-config > metadata It was. Now, it has been changed. In the next version of libgpg-error (1.33), we will offer gpg-error.pc (if nothing is going wrong). I believe this change helps cross-compiling other packages with libgpg-error. IIUC, Debian offers its (special) script named pkg-config-crosswrapper, then, users can use -pkg-config command generated by pkg-config-dpkghook. Currently, in our development version (to be 1.33), gpg-error-config script itself is not architecture independent (having architecture dependent string), because it needs to find the gpg-error.pc file in architecture dependent path, just like pkg-config does. I'm not sure if it's worth to have -gpg-error-config command, when we have gpg-error.pc. Nevertheless, I think that it is possible to improve gpg-error-config script to detect architecture dependent path dynamically... to be Debian friendly (possibly), so that Debian can offer -gpg-error-config command. --
Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
On Wed, 25 Jul 2018 at 21:59:55 +0100, Simon McVittie wrote: > While looking at this bug as a result of a package I maintain (ostree) > gaining a direct dependency on libgpg-error, it occurred to me that for > the special case of Debian, there's no reason why the -config script > needs to know about @libdir@ at all: passing -L/usr/lib/x86_64-linux-gnu > to the linker is unnecessary, because that's in our version of gcc's > search path anyway. > > This is probably the only reason why it's possible to cross-compile > packages that depend on libgpg-error, in fact. > > gpg-error-config does include another architecture-dependent string, > which is its response to the --host command-line argument. However, > that command-line argument is undocumented, and only seems to be used > by gpg-error.m4 (and its clone gpgrt.m4), which copes gracefully if > it's rejected: a gpg-error-config for which --host fails is treated > as potentially being from any architecture. > > So perhaps [1] would be suitable? It seems to work. I see there has been an upload of libgpg-error recently. Would you mind reconsidering whether the wontfix tag on this bug is appropriate? The wontfix tag was because upstream are not willing to add pkg-config metadata (which I personally think would have been a better solution, but they get to choose how their compile-time interfaces work), but the patches I suggested in [1] don't actually require that. Thanks, smcv [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643341#88
Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
Control: tags -1 + patch
On Tue, 04 Feb 2014 at 01:34:19 +0900, Osamu Aoki wrote:
> I recently packaged a package with custom *-config and hit by multiarch
> bug for -dev package like this one
[...]
> Since this was caused by hardcoding @libdir@ path into shell code,
> I replaced that @libdir@ part of code with
>
> /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)
While looking at this bug as a result of a package I maintain (ostree)
gaining a direct dependency on libgpg-error, it occurred to me that for
the special case of Debian, there's no reason why the -config script
needs to know about @libdir@ at all: passing -L/usr/lib/x86_64-linux-gnu
to the linker is unnecessary, because that's in our version of gcc's
search path anyway.
This is probably the only reason why it's possible to cross-compile
packages that depend on libgpg-error, in fact.
gpg-error-config does include another architecture-dependent string,
which is its response to the --host command-line argument. However,
that command-line argument is undocumented, and only seems to be used
by gpg-error.m4 (and its clone gpgrt.m4), which copes gracefully if
it's rejected: a gpg-error-config for which --host fails is treated
as potentially being from any architecture.
So perhaps the attached would be suitable? It seems to work.
smcv
>From 460fb6dc7fcfb2058becd3a55c269526271f84ba Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Wed, 25 Jul 2018 11:56:39 +0100
Subject: [PATCH 1/2] Add a simple compile/link/execute autopkgtest for
libgpg-error
---
debian/tests/build | 37 +
debian/tests/control | 3 +++
2 files changed, 40 insertions(+)
create mode 100755 debian/tests/build
diff --git a/debian/tests/build b/debian/tests/build
new file mode 100755
index 000..611deff
--- /dev/null
+++ b/debian/tests/build
@@ -0,0 +1,37 @@
+#!/bin/sh
+
+set -e
+exec 2>&1
+set -u
+
+: "${AUTOPKGTEST_TMP:="${ADTTMP}"}"
+
+if [ -z "${HOME-}" ] || ! [ -w "${HOME}" ]; then
+export HOME="${AUTOPKGTEST_TMP}"
+fi
+
+cd "$AUTOPKGTEST_TMP"
+
+cat > use-lib.c <<'EOF'
+#include
+
+#include
+
+int main (void)
+{
+printf ("# %s\n", gpg_strerror (GPG_ERR_NO_ERROR));
+return 0;
+}
+EOF
+
+gcc -o use-lib use-lib.c $(gpg-error-config --cflags --libs)
+test -x use-lib
+./use-lib
+echo "ok 1 - normal build"
+
+gcc -o use-lib-mt use-lib.c $(gpg-error-config --mt --cflags --libs)
+test -x use-lib-mt
+./use-lib-mt
+echo "ok 2 - thread-safe build"
+
+echo "1..2"
diff --git a/debian/tests/control b/debian/tests/control
index 4218b49..fc1ec54 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,3 +1,6 @@
+Tests: build
+Depends: build-essential, libgpg-error-dev
+
Test-Command: ./libgpg-error-mingw-w64 i686
Depends: libgpg-error-mingw-w64-dev, wine, wine32, libgpg-error-dev
--
2.18.0
>From a69ce1aad22c798e8f332ca65d6317d07a82b415 Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Wed, 25 Jul 2018 12:06:04 +0100
Subject: [PATCH 2/2] Modify /usr/bin/foo-config to be architecture-independent
To do this, I've made use of some convenient properties:
* The libdir hard-codes a multiarch-varying path, but for Debian
systems, -L$libdir is unnecessary anyway, because we install
libgpg-error.so into the compiler's default search path for all
architectures.
* The gpg-error-config --host option is also multiarch-varying, but
is undocumented, and its use in gpgrt.m4 and gpg-error.m4 is
robust against a nonzero exit status, so we can just make it fail.
* Nothing else in this script is architecture-varying.
Closes: #643341
---
debian/control| 1 +
...-foo-config-architecture-independent.patch | 63 +++
debian/patches/series | 1 +
3 files changed, 65 insertions(+)
create mode 100644 debian/patches/Make-usr-bin-foo-config-architecture-independent.patch
diff --git a/debian/control b/debian/control
index 1ff8e2e..13e8482 100644
--- a/debian/control
+++ b/debian/control
@@ -20,6 +20,7 @@ Rules-Requires-Root: no
Package: libgpg-error-dev
Section: libdevel
Architecture: any
+Multi-Arch: same
Depends:
libgpg-error0 (= ${binary:Version}),
${misc:Depends},
diff --git a/debian/patches/Make-usr-bin-foo-config-architecture-independent.patch b/debian/patches/Make-usr-bin-foo-config-architecture-independent.patch
new file mode 100644
index 000..756e6cf
--- /dev/null
+++ b/debian/patches/Make-usr-bin-foo-config-architecture-independent.patch
@@ -0,0 +1,63 @@
+From: Simon McVittie
+Date: Wed, 25 Jul 2018 20:50:04 +0100
+Subject: Make /usr/bin/foo-config architecture-independent
+
+The libdir hard-codes a multiarch-varying path, but for Debian
+systems, -L$libdir is unnecessary anyway, because we install
+libgpg-error.so into the compiler's default search path for all
+architectures.
+
+The gpg-error-config --host option is also multiarch-varying, but
+is undocumented, and its use in gpgrt.m4 and gpg-error.m4 is
+robust against
Bug#643341: [Pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
On 09/16/2014 02:49 AM, Helmut Grohne wrote: On Mon, Sep 15, 2014 at 05:17:06PM -0400, Daniel Kahn Gillmor wrote: we would need to move /usr/include/gpg-error.h to /usr/include/$ARCH/gpg-error.h (since that file varies by architecture). This move has benefits on its own. See https://lists.debian.org/debian-devel-announce/2014/08/msg00013.html section 3.4. Can you implement it even if it does not solve this bug on its own? I've made this change with libgpg-error 1.16-1, which i just uploaded to unstable. Standard autotools nowadays check whether host architecture differs from build architecture and if that is the case, prefer build tools that are prefixed with the gnu triplet of the host architecture. This mechanism is well tested for pkg-config and works. In particular, the autotools come with relevant macro files that do this for pkg-config, so library users hardly get this wrong. In contrast, guile-config (another problem of this kind) is always executed without that prefix and causes the very same problem as does gpg-error-config. What does this mean for libgpg-error? First and foremost, both libgpg-erorr upstream and Debian should start providing $PREFIX/bin/$HOST_TRIPLET-gpg-error-config as a symbolic link to gpg-error-config. Once this is in place, we need to approach library users to prefer this way of calling gpg-error-config. A good citizen in this respect is libgcrypt20. Quoting from its cross build log: | checking for x86_64-linux-gnux32-gpg-error-config... no | checking for gpg-error-config... /usr/bin/gpg-error-config Once all library users are switched, the problem is solved from an upstream POV. Hm, this is interesting. What if we actually shipped gpg-error-config as /usr/bin/$HOST_TRIPLET-gpg-error-config and made /usr/bin/gpg-error-config the symlink via the /etc/alternatives mechanism? This might let us mark gpg-error-config M-A:same, while still building cleanly by default for native builds and cross-builds for well-behaved dependencies. That means that only cross-building for poorly-behaved dependencies would be adversely affected, which seems like a much more narrow scope. For Debian there still is a problem, because native builds still need the script without architecture prefix. We need to deprecate using build tools without architecture prefix and entirely move away from that. sure, but that's only critically relevant for cross-building of debian core, right? So while this bug certainly cannot be fixed soonish, it still shows a number of sub-issues that can be solved today. guile is in the very same position and will not mark its -dev package M-A:same today, but guile chose to move to pkg-config and will be able once all guile-config users have been killed. Alas, i'm pretty sure that gpg-error upstream won't move to pkg-config (see the thread starting at [0] for example). What do you think of the approach i describe above (shipping gpg-error-config with a tuple prefix, and using /etc/alternatives for gpg-error-config)? --dkg [0] http://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028473.html signature.asc Description: OpenPGP digital signature
Bug#643341: [Pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
On Thu, Sep 18, 2014 at 12:09:03PM -0400, Daniel Kahn Gillmor wrote: On 09/16/2014 02:49 AM, Helmut Grohne wrote: On Mon, Sep 15, 2014 at 05:17:06PM -0400, Daniel Kahn Gillmor wrote: we would need to move /usr/include/gpg-error.h to /usr/include/$ARCH/gpg-error.h (since that file varies by architecture). I've made this change with libgpg-error 1.16-1, which i just uploaded to unstable. Thanks! What do you think of the approach i describe above (shipping gpg-error-config with a tuple prefix, and using /etc/alternatives for gpg-error-config)? It's terrible (at least for now). By making it an alternative you effectively remove gpg-error-config from the API provided by the libgpg-error-dev package. If I install libgpg-error-dev for two architectures and build a reverse dependency, dpkg-checkbuilddeps will tell me that Build-Depends are satisfied. However, if I choose the wrong alternative my build will fail. Since the behaviour of gpg-error-config now depends on an administrator choice, packages that Build-Depend on libgpg-error-dev can no longer expect gpg-error-config to work. At this point we'll have to teach all build-rdeps to use the triplet prefixed version. At least for now, this solution sounds terrible to me, because it may cause breakage and when it does, it is subtle and hard to spot. That said, I am still in favour of shipping TRIPLET-gpg-error-config now and moving reverse dependencies to calling it by that name. At a later point, we may want to rebuild all reverse dependencies with /usr/bin/gpg-error-config removed and if that succeeds revisit your proposal. Alternatively, stop caring about this bug for now, because those aspects that make cross-building work reliably are implemented now. The package that needs libgpg-error both for build and for host has yet to be found. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643341: [Pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
On Mon, Sep 15, 2014 at 05:17:06PM -0400, Daniel Kahn Gillmor wrote: we would need to move /usr/include/gpg-error.h to /usr/include/$ARCH/gpg-error.h (since that file varies by architecture). This move has benefits on its own. See https://lists.debian.org/debian-devel-announce/2014/08/msg00013.html section 3.4. Can you implement it even if it does not solve this bug on its own? But the last remaining piece of doing this work is to deal with /usr/bin/gpg-error-config, which differs by architecture. The first recommendation here: https://wiki.ubuntu.com/MultiarchCross#Executables_in_-dev_packages is to help upstream switch to pkg-config, which Werner has explicitly stated he has no interest in doing, so that's out. All of the recommendations seem pretty problematic, actually, in terms of forcing an archive transition -- we'd require our downstream dependencies to change how they invoke gpg-error-config. One other approach, i suppose, is to modify gpg-error-config itself somehow to be able to invoke it with a different triplet (but have it default to something sane?) I'm really not sure what the best way to approach this is, but i'm open to specific suggestions. Well put. This issue boils down to upstream providing an inexact API. It cannot be fixed without help from both upstream and library users. Let me explain why switching to pkg-config would magically solve this and draft an upstream-acceptable solution from there. Standard autotools nowadays check whether host architecture differs from build architecture and if that is the case, prefer build tools that are prefixed with the gnu triplet of the host architecture. This mechanism is well tested for pkg-config and works. In particular, the autotools come with relevant macro files that do this for pkg-config, so library users hardly get this wrong. In contrast, guile-config (another problem of this kind) is always executed without that prefix and causes the very same problem as does gpg-error-config. What does this mean for libgpg-error? First and foremost, both libgpg-erorr upstream and Debian should start providing $PREFIX/bin/$HOST_TRIPLET-gpg-error-config as a symbolic link to gpg-error-config. Once this is in place, we need to approach library users to prefer this way of calling gpg-error-config. A good citizen in this respect is libgcrypt20. Quoting from its cross build log: | checking for x86_64-linux-gnux32-gpg-error-config... no | checking for gpg-error-config... /usr/bin/gpg-error-config Once all library users are switched, the problem is solved from an upstream POV. For Debian there still is a problem, because native builds still need the script without architecture prefix. We need to deprecate using build tools without architecture prefix and entirely move away from that. So while this bug certainly cannot be fixed soonish, it still shows a number of sub-issues that can be solved today. guile is in the very same position and will not mark its -dev package M-A:same today, but guile chose to move to pkg-config and will be able once all guile-config users have been killed. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643341: [Pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
On Wed 2014-09-03 17:30:30 -0400, Daniel Kahn Gillmor wrote: On 09/03/2014 04:25 PM, Helmut Grohne wrote: One thing that libgpg-error can do nonetheless is to move /usr/include/gpg-error.h to /usr/include/triplet/gpg-error.h. This avoids accidental inclusion of a wrong-architecture header. Refer to 20140829095214.gv19...@stoneboat.aleph1.co.uk section 3.4 for details or ask me. In any case, turning libgpg-error-dev M-A:same should be a goal (and arguably this is the current meaning of the bug being discussed). For this reason alone, I argue that it should be kept open (and possibly retitled to make libgpg-error-dev Multi-Arch:same). Colin, does this sound reasonable to you? I did some reading about what i think the goal is here: https://wiki.ubuntu.com/MultiarchCross Already, the .so and .a files present in libgpg-error-dev are at an arch-specific path. we would need to move /usr/include/gpg-error.h to /usr/include/$ARCH/gpg-error.h (since that file varies by architecture). Thus far, no problems. But the last remaining piece of doing this work is to deal with /usr/bin/gpg-error-config, which differs by architecture. The first recommendation here: https://wiki.ubuntu.com/MultiarchCross#Executables_in_-dev_packages is to help upstream switch to pkg-config, which Werner has explicitly stated he has no interest in doing, so that's out. All of the recommendations seem pretty problematic, actually, in terms of forcing an archive transition -- we'd require our downstream dependencies to change how they invoke gpg-error-config. One other approach, i suppose, is to modify gpg-error-config itself somehow to be able to invoke it with a different triplet (but have it default to something sane?) I'm really not sure what the best way to approach this is, but i'm open to specific suggestions. --dkg pgpJPdN0WHgW2.pgp Description: PGP signature
Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
Hi Colin, On Tue, Sep 27, 2011 at 01:15:27PM +0100, Colin Watson wrote: libgpg-error-dev ships its own gpg-error-config program which dependent packages are supposed to use. Unfortunately this doesn't play particularly well with standard cross-build setups; nothing knows that per-architecture versions of gpg-error-config need to be installed in some kind of per-architecture path, so if you try to cross-build anything that build-depends on libgpg-error-dev (such as libgcrypt11) it fails because it tries to link against libgpg-error libraries for the architecture you're building on rather than the architecture you're building for. I have problems reproducing this issue in rebootstrap[1]. Since libgpg-error-dev is M-A:no, a cross builder will just pull in the host version of libgpg-error-dev. This actually works out quite well, because gpg-error-config is a shell script and thus executable for the build architecture. Of course, this means that trying to use it in a native compile will result in garbage. Still crossing reverse build dependencies of libgpg-error-dev such as libgcrypt11 or libgcrypt20 just work in my experience. Their configure scripts first check for triplet-gpg-error-config, which is not found, and then fall back to gpg-error-config, which works. So are you talking about cross building in a packaging context (where I do not see a problem) or about cross building for users (where there currently is no packaged toolchain)? Thanks for clarifying Helmut [1] http://wiki.debian.org/HelmutGrohne/rebootstrap -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
On Wed, Sep 03, 2014 at 06:34:29PM +0200, Helmut Grohne wrote: On Tue, Sep 27, 2011 at 01:15:27PM +0100, Colin Watson wrote: libgpg-error-dev ships its own gpg-error-config program which dependent packages are supposed to use. Unfortunately this doesn't play particularly well with standard cross-build setups; nothing knows that per-architecture versions of gpg-error-config need to be installed in some kind of per-architecture path, so if you try to cross-build anything that build-depends on libgpg-error-dev (such as libgcrypt11) it fails because it tries to link against libgpg-error libraries for the architecture you're building on rather than the architecture you're building for. I have problems reproducing this issue in rebootstrap[1]. Since libgpg-error-dev is M-A:no, a cross builder will just pull in the host version of libgpg-error-dev. This actually works out quite well, because gpg-error-config is a shell script and thus executable for the build architecture. Of course, this means that trying to use it in a native compile will result in garbage. Still crossing reverse build dependencies of libgpg-error-dev such as libgcrypt11 or libgcrypt20 just work in my experience. Their configure scripts first check for triplet-gpg-error-config, which is not found, and then fall back to gpg-error-config, which works. So are you talking about cross building in a packaging context (where I do not see a problem) or about cross building for users (where there currently is no packaged toolchain)? I filed this report before multiarch cross-building was a thing, so it was more complicated to arrange to use the host architecture version. From that point of view I expect it is indeed less of a problem nowadays. That said, the problem hasn't gone away entirely as we'll encounter it as soon as we have something like a package that needs to build both build and host architecture versions of a package linked against libgpg-error. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643341: [Pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
On 09/03/2014 01:28 PM, Colin Watson wrote: That said, the problem hasn't gone away entirely as we'll encounter it as soon as we have something like a package that needs to build both build and host architecture versions of a package linked against libgpg-error. Can you point to such a package? Do you have a recommended solution for a situation like this? I'm unaware of any package that needs this particular requirement, and it seems to me that any -dev package currently in the archive would have the same issue, no? If there's nothing that needs this right now, and we don't forsee something like this arising, i'm inclined to close #643341 (marked wontfix), and let the actual circumstances dictate what changes need to be made when they do arise (possibly including re-opening this bug, or just referring to the history here). --dkg signature.asc Description: OpenPGP digital signature
Bug#643341: [Pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
On Wed, Sep 03, 2014 at 03:58:59PM -0400, Daniel Kahn Gillmor wrote: I'm unaware of any package that needs this particular requirement, and it seems to me that any -dev package currently in the archive would have the same issue, no? I do not know about the situation Colin has in mind, but the general requirement does exist in the archive right now. An example is src:guile-2.0. src:gnutls28 build-depends on guile-2.0-dev (i.e. it needs the host version) and also build-depends on autogen, which is M-A:foreign and indirectly also depends on guile-2.0-dev (i.e. it needs the build version). This situation currently is unsatisfiable, because guile-2.0-dev is M-A:no until #757591 is fixed. If there's nothing that needs this right now, and we don't forsee something like this arising, i'm inclined to close #643341 (marked wontfix), and let the actual circumstances dictate what changes need to be made when they do arise (possibly including re-opening this bug, or just referring to the history here). If there was something like this in the archive already, then it should have been identified by botch[1] at http://bootstrap.debian.net/cross.html, but thus far I can only see guile there and not libgpg-error. That said, botch was wrong in the past. One thing that libgpg-error can do nonetheless is to move /usr/include/gpg-error.h to /usr/include/triplet/gpg-error.h. This avoids accidental inclusion of a wrong-architecture header. Refer to 20140829095214.gv19...@stoneboat.aleph1.co.uk section 3.4 for details or ask me. In any case, turning libgpg-error-dev M-A:same should be a goal (and arguably this is the current meaning of the bug being discussed). For this reason alone, I argue that it should be kept open (and possibly retitled to make libgpg-error-dev Multi-Arch:same). Helmut [1] https://gitorious.org/debian-bootstrap/botch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643341: [Pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
On 09/03/2014 04:25 PM, Helmut Grohne wrote: One thing that libgpg-error can do nonetheless is to move /usr/include/gpg-error.h to /usr/include/triplet/gpg-error.h. This avoids accidental inclusion of a wrong-architecture header. Refer to 20140829095214.gv19...@stoneboat.aleph1.co.uk section 3.4 for details or ask me. In any case, turning libgpg-error-dev M-A:same should be a goal (and arguably this is the current meaning of the bug being discussed). For this reason alone, I argue that it should be kept open (and possibly retitled to make libgpg-error-dev Multi-Arch:same). Colin, does this sound reasonable to you? --dkg signature.asc Description: OpenPGP digital signature
Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
On Mon, Aug 12, 2013 at 10:16:17PM +0200, Daniel Leidert wrote: tags 643341 + wontfix thanks Hi, Upstream has refused to add pkg-config files for all of its libraries (see e.g. #659168). I'm therefor tagging this wontfix. Given the importance of libgpg-error in the cross-building stack, regardless of upstream's position, I think it would be helpful for the Debian package maintainer to figure out something that improves the cross-building story. In any case, upstream says that pkg-config isn't sufficient for the job at hand. Fine - I haven't checked the details there. But that doesn't mean this bug is wontfix; I asked for cross-building support to be improved, and suggested pkg-config as a possible approach that usually helps. I see no suggestion in the upstream bug report that they are hostile to improvements to cross-building support in general. Have you tried cross-building things against libgpg-error? If you don't already have a suitable setup, https://wiki.ubuntu.com/CrossBuilding has some advice that should be easily adaptable to Debian, and I think there's some material on the Debian wiki too. Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
tags 643341 + wontfix thanks Hi, Upstream has refused to add pkg-config files for all of its libraries (see e.g. #659168). I'm therefor tagging this wontfix. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful
Package: libgpg-error-dev Version: 1.10-1 Severity: wishlist User: crossbu...@debian.org Usertags: cross libgpg-error-dev ships its own gpg-error-config program which dependent packages are supposed to use. Unfortunately this doesn't play particularly well with standard cross-build setups; nothing knows that per-architecture versions of gpg-error-config need to be installed in some kind of per-architecture path, so if you try to cross-build anything that build-depends on libgpg-error-dev (such as libgcrypt11) it fails because it tries to link against libgpg-error libraries for the architecture you're building on rather than the architecture you're building for. While it might be possible to add a pile of special-case code to cross-building systems to handle gpg-error-config specially, it would be much simpler if libgpg-error-dev would just provide a pkg-config file. pkg-config is already set up to be friendly to cross-building, cross-building tools already know to set the appropriate environment variable to tell it what to do, and this way we only have to do the work once. Do you think you could discuss this with upstream? Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
