Ludovic Courtès writes: > Jan Nieuwenhuizen <jann...@gnu.org> skribis: > >> Except for packages that need a native gcc to build tools during build >> time (CC_FOR_BUILD). For such packages (like Bash or Guile), >> standard-packages must include gcc again. Then, the build recipe's >> phases must be changed so that when cross compiling, the >> C_INCLUDE_PATH is moved into CPATH and C_INCLUDE_PATH is unset. >> That makes this solution even more unattractive, many changes >> to package recipe's could be needed. > > Right! That is really a bug, and I wonder why we didn’t catch it before > (maybe because the libc’s are pretty much the same in the systems we > were targeting?). > > I had actually worked around it in > e8e2e18b84eb8842a59be9bf7d49bb672260ae3a in one particular case.
Ah, I see. > So the fix, as you suggest, is (1) to change > gcc-cross-environment-variables.patch to CROSS_ify the other environment > variables as well, and (2) to remove the unsetenv that was added in > e8e2e18b84eb8842a59be9bf7d49bb672260ae3a. Yes, that's the idea. And then also use CROSS_C_INCLUDE_PATH and C_INCLUDE_PATH in cross-base.scm, i.e., for the new libc and gcc cross builds. > Could you give it a try? :-) I'm looking into this and have some success, quite some things need to be rebuilt ;-) > Thanks for taking the time to explain! That's good to hear! Thanks for looking into this and providing information! Greetings, Jan -- Jan Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
