Forums before death by AOL, social media and spammers... "We can't have nice things"
|    linux.debian.bugs.dist    |    Ohh some weird Debian bug report thing    |    28,835 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 28,052 of 28,835    |
|    Helmut Grohne to Matthijs Kooijman    |
|    Bug#1121782: openttd FTCBFS for arm64: p    |
|    18 Feb 26 11:20:01    |
      From: helmut@subdivi.de              Hi Matthijs,              I observe that you did not cc the bug. Is that intentional? Feel free to       quote this mail freely and/or bounce it to the bug report to publish it.       There is nothing private here from my pov.              On Sat, Feb 14, 2026 at 03:56:06PM +0100, Matthijs Kooijman wrote:       > Thanks for the report and the patch. I had a look today to include it,       > but I am a little confused about it:       >       > > ifneq ($(TOOLS_DIR),)       > > - dpkg-architecture -a"$(DEB_BUILD_ARCH)" -f -c dh_auto_configure       -B"$(TOOLS_DIR)" -- -DOPTION_TOOLS_ONLY=ON       > > + dpkg-architecture -a"$(DEB_BUILD_ARCH)" -f -c dh_auto_configure       --reload-all-buildenv-variables -B"$(TOOLS_DIR)" -- -DOPTION_TOOLS_ONLY=ON       > > endif       > > dh_auto_configure -- $(CMAKE_CONFIG_ARGUMENTS)       >       > Your patch adds --reload-all-buildenv-variables, but it adds it to the       > *first* call to dh_auto_configure, not the second one. I would expect to       > add this to the second one (assuming the first one fills the cache and       > the second one uses the incorrectly cached value). Or does the option       > also prevent *writing* to the cache?              It actually works somewhat the other way round. It is the dh layer that       initializes the environment variables. When dh_auto_configure comes       around, it sees that they're already set and does not change them.       However, build flags depend on the host architecture and we're wrapping       dh_auto_configure in a dpkg-architecture call that changes the host       architecture to the build architecture. Therefore, we need to tell       dh_auto_configure to recompute the variables.              Nothing is written as this is all about environment variables. They're       inherited only.              > Also, do you have a suggestion on how to reproduce this easily? I tried       > instructions at https://wiki.debian.org/CrossCompiling#Build_i       _a_build_environment_.28recommended.29       > to cross-build with git-buildpackage / git-pbuilder, but I think this       > just uses a full arm64 chroot with qemu instead of doing a proper split       > host/build arch build, and some other attempts also failed. Maybe you       > have some suggestion off the top of your head?              In Brest, I was working with someone else with that setup and found that       it makes cross building incredibly difficult, because git-buildpackage       makes it next to impossible to pass the --host-arch flag down to       pbuilder. When you set --git-arch, that gets translated to       --architecture, which changes the build architecture as you observed.       That's not cross building. I suspect, git-buildpackage needs a new       option to support cross building.              I vaguely remember that we managed to poke this through git-buildpackage       by exporting an environment variable. Could you try to perform the       builld without git-buildpackage as a diagnostic measure? Then I suspect       a bug report against git-buildpackage would be useful. Would you write       one? If you do, please X-Debbugs-Cc debian-cross@lists.debian.org.              Helmut              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca