Bug#889925: valac is unusable for cross-compilation
On Tue, Dec 10, 2019 at 10:36:23PM +0100, Helmut Grohne wrote: > I've slightly updated the previous .debdiff and uploaded it to > delayed/10. It'll target experimental first to clear NEW. I'll upload to > unstable afterwards. Please tell if I should delay it any longer. I'm > attaching the updated .debdiff. The experimental upload hit the archive today. I've now uploaded the same package to unstable as a source-only upload with 10 day delay. Helmut
Bug#889925: valac is unusable for cross-compilation
Control: tags -1 + pending
On Tue, Oct 01, 2019 at 08:47:07PM +0200, Helmut Grohne wrote:
> On Thu, Jul 04, 2019 at 12:44:59AM +0200, Helmut Grohne wrote:
> > Let me try to summarize consensus:
> >
> > * There should be an implementation-detail package called valac-bin.
> > * valac-bin should be Multi-Arch: foreign.
> > * valac-bin should contain the (versioned) valac executable
> > * valac should depend on valac-bin.
> > * valac should ship a /usr/bin/${DEB_HOST_GNU_TYPE}-valac wrapper
> >script.
>
> Lacking further input, I've now implemented the consensus in a minimal
> way.
>
> I am introducing another package libvalacodegen-0.46. It contains
> libvalacodegen.so, because both /usr/bin/valac and /usr/bin/vapigen link
> it. For the latter, we're not yet sure whether it should be M-A:foreign
> and the question does not currently seem relevant. Still that means that
> libvalacodegen.so can reside in neither valac nor valac-bin. I'm adding
> another M-A:same package for it.
>
> Apart from that I am closely sticking to the consensus. In particular,
> everything that used to work with the old valac package continues to
> work, because it depends on all packages that received files from it.
>
> Do you see any issus with this approach?
I've slightly updated the previous .debdiff and uploaded it to
delayed/10. It'll target experimental first to clear NEW. I'll upload to
unstable afterwards. Please tell if I should delay it any longer. I'm
attaching the updated .debdiff.
Helmut
diff --minimal -Nru vala-0.46.5/debian/changelog vala-0.46.5/debian/changelog
--- vala-0.46.5/debian/changelog2019-11-19 10:42:51.0 +0100
+++ vala-0.46.5/debian/changelog2019-12-10 16:34:29.0 +0100
@@ -1,3 +1,11 @@
+vala (0.46.5-1.1) experimental; urgency=medium
+
+ * Non-maintainer upload.
+ * Move valac to a M-A:foreign package and add cross wrappers. (Closes:
+#889925)
+
+ -- Helmut Grohne Tue, 10 Dec 2019 16:34:29 +0100
+
vala (0.46.5-1) unstable; urgency=medium
* New upstream release
diff --minimal -Nru vala-0.46.5/debian/control vala-0.46.5/debian/control
--- vala-0.46.5/debian/control 2019-11-19 10:42:51.0 +0100
+++ vala-0.46.5/debian/control 2019-12-10 16:34:29.0 +0100
@@ -24,12 +24,53 @@
Vcs-Browser: https://salsa.debian.org/gnome-team/vala
Homepage: https://wiki.gnome.org/Projects/Vala/
+Package: libvalacodegen-0.46-0
+Architecture: any
+Multi-Arch: same
+Depends: ${shlibs:Depends},
+ ${misc:Depends},
+Conflicts: valac-0.12, valac-0.14, valac-0.16, valac-0.18, valac-0.20,
+ valac-0.22, valac-0.24, valac-0.26, valac-0.28, valac-0.30
+Breaks: valac (<< 0.46.5-1.1~)
+Replaces: valac (<< 0.46.5-1.1~)
+Description: internal package for C# like language for the GObject system
+ Vala is a new programming language that aims to bring modern programming
+ language features to GNOME developers without imposing any additional
+ runtime requirements and without using a different ABI compared to
+ applications and libraries written in C.
+ .
+ This package contains the libvalacodegen shared library. It should not
normally
+ be used directly.
+
+Package: valac-bin
+Architecture: any
+Multi-Arch: foreign
+Depends: ${shlibs:Depends},
+ libvala-0.46-0 (= ${binary:Version}),
+ libvalacodegen-0.46-0 (= ${binary:Version}),
+ ${misc:Depends},
+Conflicts: valac-0.12, valac-0.14, valac-0.16, valac-0.18, valac-0.20,
+ valac-0.22, valac-0.24, valac-0.26, valac-0.28, valac-0.30
+Breaks: valac (<< 0.46.5-1.1~)
+Replaces: valac (<< 0.46.5-1.1~)
+Description: internal package for C# like language for the GObject system
+ Vala is a new programming language that aims to bring modern programming
+ language features to GNOME developers without imposing any additional
+ runtime requirements and without using a different ABI compared to
+ applications and libraries written in C.
+ .
+ This particular package is an implementation detail of the vala packaging.
+ It should not be installed directly and there should be no dependencies
+ on it. Refer to the valac package instead.
+
Package: valac
Architecture: any
Depends: ${shlibs:Depends},
libvala-0.46-0 (= ${binary:Version}),
+ libvalacodegen-0.46-0 (= ${binary:Version}),
libglib2.0-dev (>= 2.48),
valac-0.46-vapi,
+ valac-bin (= ${binary:Version}),
${misc:Depends}
Recommends: gcc
Conflicts: valac-0.12, valac-0.14, valac-0.16, valac-0.18, valac-0.20,
@@ -118,6 +159,7 @@
Architecture: any
Depends: ${shlibs:Depends},
libvaladoc-0.46-0 (= ${binary:Version}),
+ libvalacodegen-0.46-0 (= ${binary:Version}),
valac (= ${binary:Version}),
${misc:Depends}
Multi-Arch: foreign
@@ -132,6 +174,7 @@
Multi-Arch: same
Depends: ${shlibs:Depends},
libvala-0.46-0 (= ${binary:Version}),
+ libvalacodegen-0.46-0 (= ${binary:Version}),
${misc:Depends},
Bug#889925: valac is unusable for cross-compilation
Control: tags -1 + patch
Hi,
On Thu, Jul 04, 2019 at 12:44:59AM +0200, Helmut Grohne wrote:
> Let me try to summarize consensus:
>
> * There should be an implementation-detail package called valac-bin.
> * valac-bin should be Multi-Arch: foreign.
> * valac-bin should contain the (versioned) valac executable
> * valac should depend on valac-bin.
> * valac should ship a /usr/bin/${DEB_HOST_GNU_TYPE}-valac wrapper
>script.
Lacking further input, I've now implemented the consensus in a minimal
way.
I am introducing another package libvalacodegen-0.46. It contains
libvalacodegen.so, because both /usr/bin/valac and /usr/bin/vapigen link
it. For the latter, we're not yet sure whether it should be M-A:foreign
and the question does not currently seem relevant. Still that means that
libvalacodegen.so can reside in neither valac nor valac-bin. I'm adding
another M-A:same package for it.
Apart from that I am closely sticking to the consensus. In particular,
everything that used to work with the old valac package continues to
work, because it depends on all packages that received files from it.
Do you see any issus with this approach?
Helmut
diff --minimal -Nru vala-0.46.1/debian/changelog vala-0.46.1/debian/changelog
--- vala-0.46.1/debian/changelog2019-09-16 09:17:15.0 +0200
+++ vala-0.46.1/debian/changelog2019-09-30 21:01:59.0 +0200
@@ -1,3 +1,11 @@
+vala (0.46.1-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Move valac to a M-A:foreign package and add cross wrappers. (Closes:
+#889925)
+
+ -- Helmut Grohne Mon, 30 Sep 2019 21:01:59 +0200
+
vala (0.46.1-1) unstable; urgency=medium
* New upstream release
diff --minimal -Nru vala-0.46.1/debian/control vala-0.46.1/debian/control
--- vala-0.46.1/debian/control 2019-09-16 09:17:15.0 +0200
+++ vala-0.46.1/debian/control 2019-09-30 21:01:59.0 +0200
@@ -24,12 +24,53 @@
Vcs-Browser: https://salsa.debian.org/gnome-team/vala
Homepage: https://wiki.gnome.org/Projects/Vala/
+Package: libvalacodegen-0.46
+Architecture: any
+Multi-Arch: same
+Depends: ${shlibs:Depends},
+ ${misc:Depends},
+Conflicts: valac-0.12, valac-0.14, valac-0.16, valac-0.18, valac-0.20,
+ valac-0.22, valac-0.24, valac-0.26, valac-0.28, valac-0.30
+Breaks: valac (<< 0.46.1-1.1~)
+Replaces: valac (<< 0.46.1-1.1~)
+Description: internal package for C# like language for the GObject system
+ Vala is a new programming language that aims to bring modern programming
+ language features to GNOME developers without imposing any additional
+ runtime requirements and without using a different ABI compared to
+ applications and libraries written in C.
+ .
+ This package contains the libvalacodegen shared libary. It should not normally
+ be used directly.
+
+Package: valac-bin
+Architecture: any
+Multi-Arch: foreign
+Depends: ${shlibs:Depends},
+ libvala-0.46-0 (= ${binary:Version}),
+ libvalacodegen-0.46 (= ${binary:Version}),
+ ${misc:Depends},
+Conflicts: valac-0.12, valac-0.14, valac-0.16, valac-0.18, valac-0.20,
+ valac-0.22, valac-0.24, valac-0.26, valac-0.28, valac-0.30
+Breaks: valac (<< 0.46.1-1.1~)
+Replaces: valac (<< 0.46.1-1.1~)
+Description: internal package for C# like language for the GObject system
+ Vala is a new programming language that aims to bring modern programming
+ language features to GNOME developers without imposing any additional
+ runtime requirements and without using a different ABI compared to
+ applications and libraries written in C.
+ .
+ This particular package is an implementation detail of the vala packaging.
+ It should not be installed directly and there should be no dependencies
+ on it. Refer to the valac package instead.
+
Package: valac
Architecture: any
Depends: ${shlibs:Depends},
libvala-0.46-0 (= ${binary:Version}),
+ libvalacodegen-0.46 (= ${binary:Version}),
libglib2.0-dev (>= 2.48),
valac-0.46-vapi,
+ valac-bin (= ${binary:Version}),
${misc:Depends}
Recommends: gcc
Conflicts: valac-0.12, valac-0.14, valac-0.16, valac-0.18, valac-0.20,
diff --minimal -Nru vala-0.46.1/debian/control.in vala-0.46.1/debian/control.in
--- vala-0.46.1/debian/control.in 2019-09-16 09:17:15.0 +0200
+++ vala-0.46.1/debian/control.in 2019-09-30 21:01:59.0 +0200
@@ -20,12 +20,53 @@
Vcs-Browser: https://salsa.debian.org/gnome-team/vala
Homepage: https://wiki.gnome.org/Projects/Vala/
+Package: libvalacodegen-0.46
+Architecture: any
+Multi-Arch: same
+Depends: ${shlibs:Depends},
+ ${misc:Depends},
+Conflicts: valac-0.12, valac-0.14, valac-0.16, valac-0.18, valac-0.20,
+ valac-0.22, valac-0.24, valac-0.26, valac-0.28, valac-0.30
+Breaks: valac (<< 0.46.1-1.1~)
+Replaces: valac (<< 0.46.1-1.1~)
+Description: internal package for C# like language for the GObject system
+ Vala is a new programming language that aims to bring modern programming
Bug#889925: valac is unusable for cross-compilation
Hi Simon,
On Wed, Jul 03, 2019 at 08:50:05AM +0100, Simon McVittie wrote:
> On Thu, 08 Feb 2018 at 21:26:14 +0100, Helmut Grohne wrote:
> > So we'd also need a
> > new binary package (probably called "valac-bin"), move /usr/bin/valac to
> > that new package, add a dependency from valac to the new package and
> > mark the new package Multi-Arch: foreign. That's not fully correct as
> > valac is still architecture-dependent, but anyone wanting a particular
> > architecture's behaviour can and should simply run
> > ${DEB_HOST_GNU_TYPE}-valac. We do the same for pkg-config and that
> > appears to work fairly well. Consumers need to add this prefix of course
> > and I sent a patch for AM_PROG_VALAC (#889920) already.
>
> Would it work to move /usr/bin/valac to /usr/libexec/valac in the new,
> Multi-Arch: foreign valac-bin package, and have these scripts in valac?
Moving valac to a Multi-Arch: foreign valac-bin package is what I
proposed, no? Whether it resides in /usr/bin/valac or /usr/libexec/valac
is an interesting question though.
>
> /usr/bin/valac:
> #!/bin/sh
> exec /usr/libexec/valac --cc="${CC:-cc}"
> --pkg-config="${PKG_CONFIG:-pkg-config}" "$@"
I'm not sure about the utility of this wrapper in particular for three
reasons:
1. As far as I understand it, a significant chunk of valac users don't
make it call cc or pkg-config. This is backed by the number of
recent bugs where Nguyen Hoang Tung proposed annotating valac with
:native.
2. For those packages that do make valac call cc, I think it would be
better to replace valac with your second wrapper.
3. pkg-config also ships /usr/bin/pkg-config as a "native" variant
where you don't know which arch it refers to, but you can assume
that the "native" variant produces runnable code.
> /usr/bin/@DEB_HOST_GNU_TYPE@-valac:
> #!/bin/sh
> exec /usr/libexec/valac --cc="${CC:-@DEB_HOST_GNU_TYPE@-gcc}"
> --pkg-config="${PKG_CONFIG:-@DEB_HOST_GNU_TYPE@-pkg-config}" "$@"
I think this is roughly the wrapper I had in mind. I'm not sure about
whether interpolating CC and PKG_CONFIG is a good idea:
* You can use ${DEB_BUILD_GNU_TYPE}-valac and
${DEB_HOST_GNU_TYPE}-valac in a single build. If export CC in any
way, either of these valac wrappers will misbehave.
* If you do need to use valac with a specific cc, you can still pass it
explicitly. Multiple --cc are allowed afaiui.
* You can (and should) use valac in a way that doesn't call cc.
> And then #889920 would still be helpful, but not a blocker, because
> in practice most packages that compile Vala code (and in particular
> those that use Autotools) will already export an appropriate $CC and
> $PKG_CONFIG?
I don't think autotools export CC or PKG_CONFIG. It's only a AC_SUBST
variable and a Makefile variable, but not usually an environment
variable. But then switching from AC_PATH_PROG to AC_PATH_TOOL is a
quite simple change.
> (In fact valac is just a symlink to valac-0.42, so we'd probably want to
> move this indirection down to valac-0.42, vapigen-0.42 etc., which would
> help to make it clearer that valac-bin is an implementation detail,
> because it wouldn't contain any command-line APIs that were stable
> between versions at all.)
I agree that valac-bin should be an implementation detail. I've added a
number of such detail packages now and wonder whether there should be
some section for them. Doing so could allow lintian to flag dependencies
on detail packages as errors maybe.
> However, this is not the only Multi-Arch issue with valac:
>
> vapigen would also need checking for Multi-Arch suitability. It is used
> directly in many packages.
I somewhat agree, but I like to fix one issue at a time. So I'm in
favour of leaving vapigen broken for now and start with moving valac.
Once that works, we can look into vapigen.
> /usr/lib/*/vala-*/gen-introspect-* would also need checking for Multi-Arch
> suitability, and /usr/bin/vala-gen-introspect is a shell script wrapper
> around /usr/lib/*/vala-*/gen-introspect-* which hard-codes pkg-config. It
> should at least use ${PKG_CONFIG}. This is used directly in the geary and
> libdmapsharing packages.
If *-introsepct-* has anything to do with gobject, then we can give up,
because gobject introspection is not going to work at all in any way for
cross building. I've only seen one way to make it "work" thus far: qemu.
Let me try to summarize consensus:
* There should be an implementation-detail package called valac-bin.
* valac-bin should be Multi-Arch: foreign.
* valac-bin should contain the (versioned) valac executable
* valac should depend on valac-bin.
* valac should ship a /usr/bin/${DEB_HOST_GNU_TYPE}-valac wrapper
script.
Let me try to summarize non-consensus:
* It is not clear where the valac executable should live. Options are
/usr/bin/valac (like pkg-config) and /usr/libexec/valac. Possibly
with a version suffix.
* It is not clear whether the valac wrapper scripts
Bug#889925: valac is unusable for cross-compilation
On Thu, 08 Feb 2018 at 21:26:14 +0100, Helmut Grohne wrote:
> So we'd also need a
> new binary package (probably called "valac-bin"), move /usr/bin/valac to
> that new package, add a dependency from valac to the new package and
> mark the new package Multi-Arch: foreign. That's not fully correct as
> valac is still architecture-dependent, but anyone wanting a particular
> architecture's behaviour can and should simply run
> ${DEB_HOST_GNU_TYPE}-valac. We do the same for pkg-config and that
> appears to work fairly well. Consumers need to add this prefix of course
> and I sent a patch for AM_PROG_VALAC (#889920) already.
Would it work to move /usr/bin/valac to /usr/libexec/valac in the new,
Multi-Arch: foreign valac-bin package, and have these scripts in valac?
/usr/bin/valac:
#!/bin/sh
exec /usr/libexec/valac --cc="${CC:-cc}"
--pkg-config="${PKG_CONFIG:-pkg-config}" "$@"
/usr/bin/@DEB_HOST_GNU_TYPE@-valac:
#!/bin/sh
exec /usr/libexec/valac --cc="${CC:-@DEB_HOST_GNU_TYPE@-gcc}"
--pkg-config="${PKG_CONFIG:-@DEB_HOST_GNU_TYPE@-pkg-config}" "$@"
And then #889920 would still be helpful, but not a blocker, because
in practice most packages that compile Vala code (and in particular
those that use Autotools) will already export an appropriate $CC and
$PKG_CONFIG?
(In fact valac is just a symlink to valac-0.42, so we'd probably want to
move this indirection down to valac-0.42, vapigen-0.42 etc., which would
help to make it clearer that valac-bin is an implementation detail,
because it wouldn't contain any command-line APIs that were stable
between versions at all.)
However, this is not the only Multi-Arch issue with valac:
vapigen would also need checking for Multi-Arch suitability. It is used
directly in many packages.
/usr/lib/*/vala-*/gen-introspect-* would also need checking for Multi-Arch
suitability, and /usr/bin/vala-gen-introspect is a shell script wrapper
around /usr/lib/*/vala-*/gen-introspect-* which hard-codes pkg-config. It
should at least use ${PKG_CONFIG}. This is used directly in the geary and
libdmapsharing packages.
smcv
Bug#889925: valac is unusable for cross-compilation
Source: vala
Version: 0.38.7-1
User: helm...@debian.org
Usertags: rebootstrap
valac is presently unusable for cross-compilation. There are a number of
issues and unfortunately, this isn't going to be fixable easily.
The first issue you bump into is that executing valac gives an "Exec
format error". This is typical for build tools being installed from the
host architecture. As it happens, valac is implicitly marked Multi-Arch:
no, so it is installed for the build architecture. The simple fix for
this is to mark it Multi-Arch: foreign. Unfortunately, that is not
correct.
valac runs gcc and pkg-config. Both of these tools have
architecture-dependent behaviour and valac inherits that
architecture-dependence. Thus marking it Multi-Arch: foreign is wrong.
The typical solution to this problem is to encode the architecture into
the program name. On amd64, you can call gcc as x86_64-linux-gnu-gcc and
you can call x86_64-linux-gnu-pkg-config. However, these later
invocations also work for cross compilation. So what we need here is
adding the architecture to the valac command name.
In the simplest case, we could do:
ln -s valac .../usr/bin/${DEB_HOST_GNU_TYPE}-valac
Unfortunately, that won't fix any cross compilation issues. What we'd
want here is to have a valac executable for the build architecture
running the tools for another architecture. Thus I propose adding the
following shell script to the valac binary package:
#!/bin/sh
exec valac "--cc=${CC:-@DEB_HOST_GNU_TYPE@-gcc}"
"--pkg-config=${PKG_CONFIG:-@DEB_HOST_GNU_TYPE@-pkg-config}" "$@"
You'd interpolate @DEB_HOST_GNU_TYPE@ at package build time and install
it as /usr/bin/${DEB_HOST_GNU_TYPE}-valac. It'd run valac with the
appropriate compiler and pkg-config for the prefix it was installed as.
Now that still doesn't fix the "Exec format error". So we'd also need a
new binary package (probably called "valac-bin"), move /usr/bin/valac to
that new package, add a dependency from valac to the new package and
mark the new package Multi-Arch: foreign. That's not fully correct as
valac is still architecture-dependent, but anyone wanting a particular
architecture's behaviour can and should simply run
${DEB_HOST_GNU_TYPE}-valac. We do the same for pkg-config and that
appears to work fairly well. Consumers need to add this prefix of course
and I sent a patch for AM_PROG_VALAC (#889920) already.
Implementation plan:
* Create a new binary package valac-bin.
* Move /usr/bin/valac to valac-bin (add Breaks/Replaces).
* Add a valac-bin (= ${binary:Version}) to valac's Depends.
* The description of valac-bin should say something like "don't install
this package directly use valac instead". It should make clear that
valac-bin is an implementation detail.
* Mark valac-bin Multi-Arch: foreign.
* Add the above script as /usr/bin/${DEB_HOST_GNU_TYPE}-valac to the
valac binary package.
Do you agree with that approach? Can you help implement it?
Helmut
