Helmut Grohne
10 years ago
Package: libpq-dev
Severity: wishlist
User: ***@debian.org
Usertags: rebootstrap
This bug report is based on a productive IRC discussion involving at
least Adam Conrad, Andres Freund, Christoph Berg, Michael Banck, Simon
McVittie and myself. I am trying summarize and organize the ideas
expressed.
The root of the issue is that packages that Build-Depend on libpq-dev,
tend to run pg_config. pg_config is an ELF binary shipped in libpq-dev,
which means that it corresponds to the host architecture. During a cross
build host architecture binaries cannot be executed. Doing so anyway
tends to result in the shell trying to execute pg_config as a shell
script or the error message "cannot execute binary file: Exec format
error". In both cases, the build sooner or later fails. To show that
this issue is not artificial, I am attaching a build log for postfix
(which has problems beyond libpq-dev).
During the discussion, the following solutions were proposed (in no
particular order):
* Do not use pg_config at all. Use pkg-config instead.
+ pkg-config nicely supports cross compilation (for autotools based
projects) out of the box (assuming that #759556 gets fixed).
- pkg-config does not work for Windows and thus does not work for
PostgreSQL upstream. In particular, the documentation will keep
referring to pg_config. So reverse Build-Depends would need to
support both pkg-config (for Debian) and pg_config (for Windows).
- (Consequence:) Many packages need patches.
- libpq.pc does not contain all the information that pg_config
contains. This certainly is fixable, but needs work.
- There are also pg_config's in PostgreSQL-specific paths to build
against particular versions of PostgreSQL (extensions do "make
PG_CONFIG=/usr/lib/postgresql/$version/bin/pg_config"). For
pkg-config, this would amount to adding e.g. postgresql-X.Y.pc
files which are not supported in any reverse Build-Depends yet.
- pkg-config is less convenient, because things such as --cc or
--pkglibdir (from pg_config) need to be accessed via
--variable=something (for pkg-config).
* Turn pg_config into a script (e.g. shell, perl, etc.).
+ Many reverse Build-Depends will just work without modification.
- The pg_config binary cannot be dropped upstream, because Windows
cannot run scripts. This amounts to a double maintenance either
upstream or in Debian.
- libpq-dev cannot become Multi-Arch:same. (At the moment, there is
no apparent need for libpq-dev to become M-A:same.)
For the second variant there is the question of how to generate the
values for a pg_config script. Two ways have been proposed:
* Running the pg_config binary during build and saving the output in
the new pg_config script.
- This implies that PostgreSQL cannot be cross built itself. (It
cannot currently be cross built due to other problems. In
particular PostgreSQL's Build-Depends are not satisfiable. See
http://bootstrap.debian.net/cross.html)
* Extracting the values from the PostgreSQL build by other means.
- More fragile, probably more work.
Let me add another "wicked" solution beyond the discussion. The values
that pg_config exposes could be written to a plain text file with a
fixed location relative to the pg_config binary (e.g
"../lib/pg_config.values"). Then a new binary package (e.g. "pg-config",
M-A:foreign) could implement the pg_config interface by looking up its
own path and adding the relative path to access the values. All packages
that formerly shipped pg_config somewhere could add pg-config to Depends
and symlink it to the desired place to retain the previous API. It is
not clear to me whether this works for windows (in particular the lookup
of the executed location) and whether this is acceptable upstream. In
some aspects, this idea reimplements pkg-config.
The discussion appeared to conclude that turning pg_config into a script
would be the preferred solution for Debian.
I hope that this summary accurately covers all relevant aspects.
Helmut
Severity: wishlist
User: ***@debian.org
Usertags: rebootstrap
This bug report is based on a productive IRC discussion involving at
least Adam Conrad, Andres Freund, Christoph Berg, Michael Banck, Simon
McVittie and myself. I am trying summarize and organize the ideas
expressed.
The root of the issue is that packages that Build-Depend on libpq-dev,
tend to run pg_config. pg_config is an ELF binary shipped in libpq-dev,
which means that it corresponds to the host architecture. During a cross
build host architecture binaries cannot be executed. Doing so anyway
tends to result in the shell trying to execute pg_config as a shell
script or the error message "cannot execute binary file: Exec format
error". In both cases, the build sooner or later fails. To show that
this issue is not artificial, I am attaching a build log for postfix
(which has problems beyond libpq-dev).
During the discussion, the following solutions were proposed (in no
particular order):
* Do not use pg_config at all. Use pkg-config instead.
+ pkg-config nicely supports cross compilation (for autotools based
projects) out of the box (assuming that #759556 gets fixed).
- pkg-config does not work for Windows and thus does not work for
PostgreSQL upstream. In particular, the documentation will keep
referring to pg_config. So reverse Build-Depends would need to
support both pkg-config (for Debian) and pg_config (for Windows).
- (Consequence:) Many packages need patches.
- libpq.pc does not contain all the information that pg_config
contains. This certainly is fixable, but needs work.
- There are also pg_config's in PostgreSQL-specific paths to build
against particular versions of PostgreSQL (extensions do "make
PG_CONFIG=/usr/lib/postgresql/$version/bin/pg_config"). For
pkg-config, this would amount to adding e.g. postgresql-X.Y.pc
files which are not supported in any reverse Build-Depends yet.
- pkg-config is less convenient, because things such as --cc or
--pkglibdir (from pg_config) need to be accessed via
--variable=something (for pkg-config).
* Turn pg_config into a script (e.g. shell, perl, etc.).
+ Many reverse Build-Depends will just work without modification.
- The pg_config binary cannot be dropped upstream, because Windows
cannot run scripts. This amounts to a double maintenance either
upstream or in Debian.
- libpq-dev cannot become Multi-Arch:same. (At the moment, there is
no apparent need for libpq-dev to become M-A:same.)
For the second variant there is the question of how to generate the
values for a pg_config script. Two ways have been proposed:
* Running the pg_config binary during build and saving the output in
the new pg_config script.
- This implies that PostgreSQL cannot be cross built itself. (It
cannot currently be cross built due to other problems. In
particular PostgreSQL's Build-Depends are not satisfiable. See
http://bootstrap.debian.net/cross.html)
* Extracting the values from the PostgreSQL build by other means.
- More fragile, probably more work.
Let me add another "wicked" solution beyond the discussion. The values
that pg_config exposes could be written to a plain text file with a
fixed location relative to the pg_config binary (e.g
"../lib/pg_config.values"). Then a new binary package (e.g. "pg-config",
M-A:foreign) could implement the pg_config interface by looking up its
own path and adding the relative path to access the values. All packages
that formerly shipped pg_config somewhere could add pg-config to Depends
and symlink it to the desired place to retain the previous API. It is
not clear to me whether this works for windows (in particular the lookup
of the executed location) and whether this is acceptable upstream. In
some aspects, this idea reimplements pkg-config.
The discussion appeared to conclude that turning pg_config into a script
would be the preferred solution for Debian.
I hope that this summary accurately covers all relevant aspects.
Helmut