home bbs files messages ]

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