mingw-w64 host: Failure on installing kernel headers on 3.x #11
Comments
|
Installing Linux headers on Windows doesn't work out of the box (nor does If you look in the crosstool-ng of ctng-firefox-builds you'll see On Tue, Jan 14, 2014 at 3:55 PM, Arnaud.Dovi [email protected]:
|
|
will try that but if I rmemeber I have tried with 3.10.19 patched too and it failed |
|
Well, I only focussed on raspberry pi, and that should work: from ctng-firefox-builds: btw, Win 64bit Darwin compilers have another bug in them, but I am getting On Tue, Jan 14, 2014 at 4:49 PM, Arnaud.Dovi [email protected]:
|
|
Just retested with a reworked patch for 3.12 (not sure did it well) but it failed with same include error 110-scripts-Makefile.headersinst-install-headers-from-sc-3.12.patch http://pastebin.com/GxdpPLTN Else thank you for darwin I'm going to head on it soon, yet I reworked my builds hosted Windows with all your precious helps I better understand how it is built, yet successfully built under ct-ng-dw + mingw-w64 through build.sh Target: Windows 64-Bit Seh (gcc-4.8.2-x86_64-unknown-mingw32-seh) Target: Windows 32-Bit Dwarf2 (gcc-4.8.2-i686-unknown-mingw32-dw2) |
|
I just notice I forgot to update the line + |
You aren't applying patches by hand are you? I hope you are only forward GDB without expat is generally pretty useless I think, or at least it is On Tue, Jan 14, 2014 at 5:47 PM, Arnaud.Dovi [email protected]:
|
|
if it is in the svn i do them with tortoisesvn else with diff of mingw, ok havent really tested yet the dbg on windows, just the compilers they are ok |
|
I think I have found the root cause of this elf.h issue Its a circular dependency problem In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h |
|
Which version of linux are you trying to build headers for here? Can you On Fri, Jan 17, 2014 at 3:29 AM, Arnaud.Dovi [email protected]:
|
|
I have tested with 3.0.19 because with the 3 patches, 3.12 same fails, and the 2.6 longterm as another issue if I remember, been able to get ride of build.sh so I can build straight with your fork with patch applied I have even tested cygwin + mingw64 that is integrated inside with a few MS Junction to solve the pathing problems, but same fails config: http://pastebin.com/VrdYPwXW ALSO: I notice anytime I manually delete the BUILD Source folders of linux 3.x on Windows, it fails on a file name aux.c Couldn't this special name aux.c produce an internal error ? If I remember this special file is not part of older kernels so the error did not occur with 2.x kernels Going to test right now on a older kernel same setup. OFFTOPIC: been able to compile gdb with expat for Windows, this time I copied expat headers and libs in the sysroot and all went fine except python not detected so I disabled it. OFFTOPIC: Btw I notice Y Morin released patches for its sources few hours ago, do you also apply them on your fork ? |
|
been able to successfully generate windows 32/64-bit toolchains dw2/seh with updated components, Mingw-w64 3.1.0 (nopatch) -I have used msys2, installed mingw-w64 with pacman for easier package management also my patch add cflags and ldflags to the gdb configuration because once you link fix the link to python you need to define __USE_MINGW_ANSI_STDIO=1 which is ommitted in your fork and patches. Also I know ugly patch because I know it suppose you have /mingw64 /mingw32, just handy for the purpose of a workaround if anyone is looking for one. |
|
Great! Why not fork this project and make pull requests? I'd be more than happy to review them. For GMP, instead of my intrusive fixes about reldir it can be fixed by calling configure with a relative path, as I do for the GCC build now ( see call to CT_FindRelativePath in crosstool-ng/scripts/build/cc/100-gcc.sh ), you may want to investigate that as a nicer way. I consider *-use-srcdirrel-to-avoid-MSYS-path-namespace-mismatch.patch an interesting proof-of-concept of how it could be fixed in each project, but it isn't something I would expect any upstream to ever merge (I wouldn't) so it would be a patch that would never forward porting forever. I see that you are re-using the 'system' expat (i.e. MSYS2/MINGW-packages ones) libraries? I think adding expat as a companion library to crosstool-ng might be the preferred option (but I may be completely wrong in that too!) For -D__USE_MINGW_ANSI_STDIO=1, I already set that in crosstool-ng/scripts/crosstool-NG.sh.in : I will be moving (the good) patches from ctng-firefox-builds back into this project then adding this project into the MSYS2-packages repository which should make things easier in future. Some of the more hacky and Windows specific patches I may keep in MSYS2-packages instead, because I don't think Yann Morin would want to merge e.g. my linux-kernel-headers or {e}glibc patches into crosstool-ng as it'd increase the workload when updating verisons; I also don't think linux or {e}glibc would welcome those changes - though I may submit them to those projects just to get their reactions (I'm sure they will be funny at least). |
|
Yeah but I'm a little hesitant on using Git, as Windows user TortoiseGit does not have all the great features of TortoiseSVN and generally when you know svn and you come to git, it is like chinese huhu o_0 Interesting for GMP, honestly I did not even attempted without patch and guess what I just tried and it GMP 5.1.3 worked WITHOUT a single patch ! So it is even better no ? or the error come at the use ? Because here without patch, GMP Installing GMP for host, Configuring GMP, Building GMP, Installing GMP, Installing GMP for host: done in 207.16s (at 07:00) =) For expat I was tempted to do that yeah but then come Python to move, and python unlike expat as lots of dependencies so I have found easier to change a little configuration option rather than breaking the initial system installation because I try to keep the msys2 free of manual changes For D__USE_MINGW_ANSI_STDIO yeah I have seen you set it well in crosstool-NG.sh but did you look at the gdb.sh , it set correctly the cflags for a GDB NATIVE configuration, but the GDB CROSS configuration script configure is called without setting CFLAGS so my patch just set it back nothing much. For merging patches that's good yeah I'm looking for that too because we are not supposed to know the build project exists with currently interesting patches specially for 4.8.2 gcc it has fixed all the problems 👍 For linux yet I'm stuck testing with step at step |
|
Github made a special github program for Windows users: For -D__USE_MINGW_ANSI_STDIO=1, clearly that's a Windows specific hack in gdb.sh and CFLAGS_FOR_BUILD should be moved into CFLAGS instead as that's a general, correct fix for all systems. I don't really follow you "For linux", I assume you mean running the linux headers install on Windows? Did you port my 3.10.19 patches to the other versions you tried? If not, then there's no chance (at all) of it working :-) |
|
Just found linux 3.x solution I think is just ok to remove the archscript step Then headers gotr copied successfully without the need of the header copy patch but you still need 100-fixdep-fixes-for-Windows.patch and 120-Win32-FreeBSD-use-upstream-unifdef.patch as far I checked with 3.12 and 3.12.8 BTW I also notice the GetText compilation is EXTREMELY long, you should add --disable-nls because it is compiling so much things not needed. |
|
It would be good for us to get to the bottom of why I don't need to remove the archscripts step I think. |
|
Been able to successfully build Linux 64-bit seh toolchain kernel 3.12.8 , glibc 2.18, gcc 4.8.2 from Windows without building gettext and libiconv (slow steps as hell to do 4 more companions when they are already available in pacman) Index: scripts/build/cc/100-gcc.sh ; patched a copy (cp -a) procedure which made an include path like sysroot/usr/include/include instead of sysroot/usr/include (probably caused by a trailing / symbol) this was then causing errors like stdio.h to be missing. Index: config/libc/glibc.in: Index: scripts/build/libc/glibc-eglibc.sh-common: Index: scripts/build/libc/glibc-eglibc.sh-common: Index: patches/glibc/2.18/130-Fix-crossrpc-to-build-on-non-Linux.patch Index: patches/glibc/2.18/140-glibc-disable-install-symlink-script-rellns.patch Index: patches/linux/3.12.8/100-fixdep-fixes-for-Windows.patch Index: patches/linux/3.12.8/120-Win32-FreeBSD-use-upstream-unifdef.patch Index: patches/linux/3.12.8/140-kernel-disable-archscripts.patch Index: patches/linux/3.12.8/100-fixdep-fixes-for-Windows.patch To note also 2 or 3 mk files are generated with windows style path x:/LIBRARIES/.. , fixed by replacing x:/LIBRARIES to my /root fstab mount directly infile , then "exit 2" to continue, I did not attempted to fix this in code So below the patch I'm applying after the buildsh ones. Btw they are more personal patches but this may help you because they are all the patch in one file I used to successfully generate Linux and Windows toolchains |
|
I'm not sure what best to do about elf.h, I'm guessing an empty file somewhere in the header search path might be the cleanest approach as it appears to be another assumption that we're building on Linux? Then again, if it really does need something from that header then copying the real elf.h might work better than an empty file. Thanks for helping to test this. Shall we close this issue? |
|
Before we close this, I want to make sure everything is addressed. You said before: "Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h" .. what was the fix for this? I'm about to test your elf.h circluar dep fix, so I guess if this is still a problem I'll run into it? You asked: "OFFTOPIC: Btw I notice Y Morin released patches for its sources few hours ago, do you also apply them on your fork ?" Well, we do merge in Y Morin's changes every few months or after a major release. It's somewhat time consuming to do it too frequently though. Next time will probably be when 1.20 is released. |
|
Yet for me is ok but I did not really did extensive test of it so I will reopen later if it is causing nex problems Btw I have found a new problem this time on Windows should I create new ticket ? Well the problem is simple anyway: It is impossible to have CT_SHARED_LIBS under Windows and so on, whether you choose Static or not in the menuconfig for Windows, the shared libs are never done because of this in the final core compiler and one or two other locations, I don't understand because it seems the original crosstool-ng also does have this issue so nobody really builds shared libs in Windows ?? So instead of setting --enable-shared over the disable option in an extra config and guess if it is accepted or not I do Then I'm allowed to have CT_SHARED_LIBS=y on windows Without it is impossible to get the dll compiled, you can try, uncheck the static option in gcc, uncheck the static one in the toolchains options, the shared dll are never compiled |
|
I did run into problem with elf.h as you described even after applying the archscripts patch: "Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h" .. can you remember what you did to fix it? Sorry to repeat the question. If you can't remember then no problem I'll figure it out! |
|
Oops sorry, I did not run into the problem here after removing archscript even after deleting source and reapplying so I'm sure there is no other patch I may have missed. On which kernel did you tested ? me 3.12.8 and 3.13 The thing that comes to minds in your case is that archscript may be called from a different location than mine because archscript real location is arch\x86\Makefile and is define too in the Main Makefile in archprepare: archheaders archscripts prepare1 scripts_basic or no-dot-config-targets := clean mrproper distclean But I dont need to remove it from here ct-ng-dw.x86_64-unknown-linux.config http://pastebin.com/ReSzYrMF btw if u want to reach me fast im on steam or I have google hangout in the phone too, because Im french based and as I have no jobs yet have strange day cycles heheh |
|
I was incorrect, your archscripts change did get me past that problem, thanks. For libiconv and gettext on Windows, you are right building these does take quite some time, but I like crosstool-ng to be as stand-alone as possible (even yhough I'm on the MSYS2/Paman dev team). I think I will ask Yann Morin for advise on this topic. In my opinion, setting {GETTEXT|LIBCONV}_VERSION="system" would be the best way to allow the user to specify that they want to use the system versions of those libraries. Finally, you can also pass to build.sh --ctng-save-steps=yes so that you can later skip gettext and libiconv rebuilds. This is the approach I'm adopting. Thanks for the IM offer, you can get me on Google hangouts too. I'm in the UK. I'm also on IRC (OFTC servers: #msys2 or #mingw-w64 and Freenode servers: #crosstool-ng) I'm working on making sure that glibc 2.15 and multilib work ok with host/build=Windows, target=Linux. |
|
Cool thanks will add you I have seen you glibc patches, but why are you developing multilib ? Isn't it just for the purpose of not having two compilers ? I'd like to try multilib too but there is no way to get the seh + multilib ? Maybe is it coming in gcc 4.9 ? |
|
AFAIK, Linux always and only uses dwarf table based exception handling and SEH is a target=Windows-only thing. You are correct that for target=Windows you can't build compilers that are multilib with different exception models for each variant, but this is not a problem when you target=Linux (or target=Darwin for that matter!) Of course the toolchains themselves itself do not depend on exceptions either. .. or am I missing something? I don't expect gcc 4.9 to allow split exception handling but I could be wrong! |
|
Ho, thank you for that I do not find official SEH documentations and as I'm pretty new at c++ coding, What do you suggest on Windows ? I plan to build a small c++ code for win/linux/mac 32/64bit (a small proxy server based on boost.asio), do you think seh is a real perf improvment and debugging under Windows or dw2 is enough for all |
|
You can find descriptions of the three exception types supported by GCC here: .. and here is a good description of the pros and cons of the three available choices for MinGW-w64 I think you need to be explicit when discussing machines/OSes in cross compilation scenarios. The host/build machine is irrelevant in these matters the only thing that matters is the target machine, so: If you build cross-GCC to run on Windows or Darwin (or Linux), targeting Linux (or Darwin, AFAIK!) then the exception method will always be Dwarf-based. If you build cross-GCC to run on Linux or Darwin (or Windows), targeting Windows then it is more complicated: Personally I tend to avoid exceptions as I personally don't think it is a very good way to structure or reason about programs. IMHO they are essentially just a much more complicated version of "goto" statements and encourage people to not think about their error handling carefully. As for boost.asio, I cannot offer any useful comments there as I've never used it. |
|
Yeah indeed sorry not being precise, I mean, my host is always a Windows so my cross-gcc will always run on Windows and I will target Windows, Linux, MAC yeah indeed I try to not use the try catch, in c# often they can be a severe performance hit when a simple if condition check does the job without the perf. hit I think I'm going to dw2 so I can experience building multilib, easier to manage 3 compilers than 6, so if I understand for building a multilib crossgcc I must use a multilib gcc, exactly as you are doing in build.sh, so I understand a bit more why do you prefer to build everything from scratch, the libs are not always availables with the build gcc you are using Thank again for all your informations |
Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h "
config/linux: Update kernel versions
For versions 3.10.19, 3.10.38, 3.10.62, 3.12 and 4.3.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12 and 4.3.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12 and 4.3.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: #11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: diorcety/crosstool-ng#11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: diorcety/crosstool-ng#11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: diorcety/crosstool-ng#11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: diorcety/crosstool-ng#11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: diorcety/crosstool-ng#11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
For versions 3.10.19, 3.10.38, 3.10.62, 3.10.98, 3.12, 4.3.3 and 4.4.3 Fix from Arnaud Dovi: diorcety/crosstool-ng#11 " I think I have found the root cause of this elf.h issue Its a circular dependency problem __headers: $(version_h) scripts_basic asm-generic archheaders archscripts FORCE $(Q)$(MAKE) $(build)=scripts build_unifdef PHONY += headers_install headers_install: __headers $(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \ $(error Headers not exportable for the $(SRCARCH) architecture)) $(Q)$(MAKE) $(hdr-inst)=include/uapi $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) In short headers_install depends on archscripts but archscripts compiles a code with a header elf.h installed by headers_install Next once you fix this you will realize the headers are copied under linux\elf.h of the sysroot when the code looks for elf.h " Signed-off-by: Ray Donnelly <[email protected]>
I have attempted to install all recent linux kernels 3.x and they failed with the same error, also attempted the latest LT support 2.x kernel but it also failled but havent a log for this one will resubmit ticket later
fatal error: elf.h: No such file or directory
The text was updated successfully, but these errors were encountered: