Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1265897

Bug#1117682: debtoolchainfilegen: include *_FOR_BUILD flags in toolchain file

Show all headers | View raw

Hi Fabian and Timo,

On Thu, Oct 09, 2025 at 11:44:10PM +0200, Timo Röhling wrote:
> On Thu, 09 Oct 2025 17:58:55 +0200 Fabian Greffrath <fabian@debian.org>
> wrote:
> > the /usr/share/cmake/debtoolchainfilegen tool comes handy to create a
> > toolchain file for cross-building. However, when cross-building is
> > involved, it is often a good idea to reset the build flags for the
> > compilers and linkers - or at least reduce them to a subset that is
> > known to work on the build architecture.
> > 
> > That's what the *_FOR_BUILD flags are for.

I'm not sure what you are trying to achieve here. CMake is a bit unique
in build systems, because it has no clue about the build architecture as
a concept. When people need it, they tend to either run CMake several
times and import executables or they use an ExternalProject. In neither
case does a single CMake invocation have an idea of there being a build
architecture that would be distinct from a host architecture. Therefore,
none of *_FOR_BUILD ever makes sense to me in a toolchain file.

> > I'd suggest to include these flags in the toolchain file generated by
> > debtoolchainfilegen, in the same form that they are emitted by
> > dpkg-buildflags. Either always, or only if a parameter (say '-f') is
> > additionally given to debtoolchainfilegen.
> > 
> > Example:
> > set(CMAKE_C_FLAGS "$ENV{CFLAGS_FOR_BUILD} $ENV{CPPFLAGS_FOR_BUILD}")
> > set(CMAKE_EXE_LINKER_FLAGS "$ENV{LDFLAGS_FOR_BUILD}")

This feels very wrong. We frequently encounter situations where the host
compiler is unable to understand build compiler flags. Doing it this way
would very likely result in fatal errors on any compilation attempt.

Now, I'm into guessing what you might actually want here. Possibly,
there is a build vs host confusion going on (which would be very
plausible as CMake has no clue about this distinction itself). Maybe
your request is about adding CMAKE_C_FLAGS to the toolchain file. That
feels sensible in principle, but I'm not sure you'd want it in all
situations. The proposition of an optional flag feels sensible.

Fundamentally, what is being requested here is making
debtoolchainfilegen more flexible to become applicable in more
situations than originally envisioned. That's great.

Being able to influence debtoolchainfilegen's behavior using environment
variables is a good idea. Being able to override CMAKE_C_COMPILER via a
CC environment variable would be a logical consequence. Optionally
setting CMAKE_C_FLAGS to the CFLAGS environment variable falling back to
what dpkg-buildflags produces also makes sense to me (but it must be
CFLAGS rather than CFLAGS_FOR_BUILD).

> AFAICT, the generated config is supposed to be used for the host compiler,
> so I'm not entirely sure I understand how the *_FOR_BUILD flags fit into the
> picture here. I am open to improvements for the cross-build use-case,
> though.

Same conclusion here as above.

Helmut

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#1117682: debtoolchainfilegen: include *_FOR_BUILD flags in toolchain file Fabian Greffrath <fabian@debian.org> - 2025-10-09 18:10 +0200
  Bug#1117682: debtoolchainfilegen: include *_FOR_BUILD flags in toolchain file Timo Röhling <roehling@debian.org> - 2025-10-09 23:50 +0200
    Bug#1117682: debtoolchainfilegen: include *_FOR_BUILD flags in toolchain file Helmut Grohne <helmut@subdivi.de> - 2025-10-13 12:50 +0200
      Bug#1117682: debtoolchainfilegen: include *_FOR_BUILD flags in toolchain file Timo Röhling <roehling@debian.org> - 2025-11-11 13:30 +0100

csiph-web