[Bug 2071468] Re: ELF package metadata failure: environment variable ‘DEB_HOST_ARCH’ not defined
Matthias Klose
2071468 at bugs.launchpad.net
Sat Jun 29 06:43:10 UTC 2024
just curious: are there any pointers to these discussions? It seems odd
to design a format that has quoting issues from the beginning.
I don't like having a 99% solution, and skip stuff otherwise. Plus it's
not just problematic for regular package builds, but also for debugging
a package build. You have to set all these environment variables on
your own, when you restart some part of a package build.
I see two ways to get around that:
- a package build creates a build specific spec without relying on any
environment variables. That would be a change in dpkg, plus passing the
--package-metadata in the build flags.
- the gcc and clang drivers insert the --package-metadata option on
it's own, if it is not present, and if all the env vars are present.
This would not need *any* changes in dpkg, just a simple local patch to
the compiler drivers. In case of not having the env vars, it just would
not be recorded, but not failing the build as it's currently the case.
Both options seem to be better than the current status.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dpkg in Ubuntu.
https://bugs.launchpad.net/bugs/2071468
Title:
ELF package metadata failure: environment variable ‘DEB_HOST_ARCH’ not
defined
Status in dpkg package in Ubuntu:
New
Bug description:
The ELF package note metadata introduced in dpkg 1.22.6ubuntu11
(refined in 1.22.6ubuntu14) can cause this failure:
```
gcc fatal error: environment variable ‘DEB_HOST_ARCH’ not defined
```
This happens when the `-specs=/usr/share/dpkg/elf-package-
metadata.specs` parameter is set but the needed environment variables
are not set. Cases:
1. Only the LDFLAGS is queried from dpkg-buildflags. Affected source
packages builds: python3.12, openjdk-21, cdbs (causing dvbstreamer and
rp-pppoe fail to build)
2. autopkgtests
This approach is too fragile. An alternative approach would be to specify the `--package-metadata` linker flag directly. The problem with that approach is that the curly brackets and quotation marks need to be escaped. Example failure: Building dpkg would add this parameter to the LDFLAGS:
```
-Wl,--package-metadata,{"type":"deb","os":"ubuntu","name":"dpkg","version":"1.22.6ubuntu15","architecture":"amd64"}
```
The following configure script call (non-relevant parameters deleted):
```
$ gcc -Wl,--package-metadata,{type:deb,os:ubuntu,name:dpkg,version:1.22.6ubuntu15,architecture:amd64}
/usr/bin/ld: cannot find {type:deb: No such file or directory
/usr/bin/ld: cannot find os:ubuntu: No such file or directory
/usr/bin/ld: cannot find name:dpkg: No such file or directory
/usr/bin/ld: cannot find version:1.22.6ubuntu15: No such file or directory
/usr/bin/ld: cannot find architecture:amd64}: No such file or directory
```
Proposed solution: Add support for an `--escaped-package-metadata` parameter to the linkers that takes an URL encoded (RFC 3986) parameter. Example:
```
-Wl,--encoded-package-metadata,%7B%22type%22:%22deb%22%2C%22os%22:%22ubuntu%22%2C%22name%22:%22dpkg%22%2C%22version%22:%221.22.6ubuntu15%22%2C%22architecture%22:%22amd64%22%7D
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/2071468/+subscriptions
More information about the foundations-bugs
mailing list