Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #1265398 > unrolled thread
| Started by | Fabian Greffrath <fabian@debian.org> |
|---|---|
| First post | 2025-10-09 18:10 +0200 |
| Last post | 2025-11-11 13:30 +0100 |
| Articles | 4 — 3 participants |
Back to article view | Back to linux.debian.bugs.dist
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
| From | Fabian Greffrath <fabian@debian.org> |
|---|---|
| Date | 2025-10-09 18:10 +0200 |
| Subject | Bug#1117682: debtoolchainfilegen: include *_FOR_BUILD flags in toolchain file |
| Message-ID | <LE1nj-3VZo-5@gated-at.bofh.it> |
Package: cmake
Version: 4.1.1+really3.31.6-2
Severity: wishlist
Hi there,
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'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}")
Thanks for considering!
Cheers,
- Fabian
-- System Information:
Debian Release: forky/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.16.8+deb14-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cmake depends on:
ii cmake-data 4.1.1+really3.31.6-2
ii libarchive13t64 3.7.4-4+b1
ii libc6 2.41-12
ii libcurl4t64 8.16.0-2
ii libexpat1 2.7.3-1
ii libgcc-s1 15.2.0-4
ii libjsoncpp26 1.9.6-4
ii librhash1 1.4.6-1
ii libstdc++6 15.2.0-4
ii libuv1t64 1.51.0-2
ii procps 2:4.0.4-9
ii zlib1g 1:1.3.dfsg+really1.3.1-1+b1
Versions of packages cmake recommends:
ii gcc 4:15.2.0-4
ii make 4.4.1-2
Versions of packages cmake suggests:
pn cmake-doc <none>
pn cmake-format <none>
pn elpa-cmake-mode <none>
ii ninja-build 1.12.1-1
-- no debconf information
[toc] | [next] | [standalone]
| From | Timo Röhling <roehling@debian.org> |
|---|---|
| Date | 2025-10-09 23:50 +0200 |
| Message-ID | <LE6Gl-3Zm2-5@gated-at.bofh.it> |
| In reply to | #1265398 |
[Multipart message — attachments visible in raw view] — view raw
Control: tags -1 + moreinfo
Hi Fabian,
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'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}")
>
> Thanks for considering!
[Cc'ing Helmut because he wrote the debtoolchainfilegen tool and can
probably fill in the blanks in my understanding]
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.
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2025-10-13 12:50 +0200 |
| Message-ID | <LFohP-4RK7-3@gated-at.bofh.it> |
| In reply to | #1265438 |
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
[toc] | [prev] | [next] | [standalone]
| From | Timo Röhling <roehling@debian.org> |
|---|---|
| Date | 2025-11-11 13:30 +0100 |
| Message-ID | <LPVFv-c9L0-9@gated-at.bofh.it> |
| In reply to | #1265897 |
[Multipart message — attachments visible in raw view] — view raw
Control: tags -1 + wontfix Control: notfound -1 4.1.1+really3.31.6-2 Control: close -1 Hi, On Fri, 10 Oct 2025 10:27:44 +0200 Helmut Grohne <helmut@subdivi.de> wrote: > On Thu, Oct 09, 2025 at 11:44:10PM +0200, Timo Röhling wrote: > > 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. Closing this bug as not actionable. -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.bugs.dist
csiph-web