- Sun Oct 30, 2016 11:16 pm
#57416
BTW, here ArchontPL posted pull request with the change from this thread. I took a look at how it was fixed in the gcc mainline and found a series of patches that added target, build and host cygwin support for x86_64. They do more than just changing gcc/config.host. I've added a comment with details there. davydnorris, can you check if other changes from the mainline patch are relevant?
- Mon Oct 31, 2016 12:17 am
#57418
Yes he told me he was dropping that - he had exactly the same problems as I had documented here so I replied to the issue he raised on the git repo and pointed him back here. He dropped my patch into a pull request. This is the same patch I have already sent to the main crosstool-ng folks. gcc5.2.0 has already fixed this issue with cygwin64 and more so it's just a gcc 4.8.5 issue and it only affects the LTO .dll.
Oh and speaking of which, the generated cyglto_plugin-0.dll needs to be installed in $(TOOLCHAIN)/lib/bfd-plugins and not $(TOOLCHAIN)/libexec/gcc/xtensa-lx106-elf/<version>. I think this is a crosstool-ng build issue and not an esp-open-sdk problem. I think it's also generic and not just limited to being a cywin issue either.
BTW, I agree with you on the --disable-tui fix, and I implemented it in the same way. Because I'm building inside esp-open-sdk I just add the extra line to crosstool-config-overrides. One thing that annoys me a bit is that you can't do the same with the desired gcc version - the esp-open-sdk Makefile simply concatenated the overrides to the end of the sample config.in file, and in the case of gcc the existing version line (4.8.5) takes precedence. This means you have no choice but to fiddle with the sample config.in
jcmvbkbc wrote:BTW, here ArchontPL posted pull request with the change from this thread. I took a look at how it was fixed in the gcc mainline and found a series of patches that added target, build and host cygwin support for x86_64. They do more than just changing gcc/config.host. I've added a comment with details there. davydnorris, can you check if other changes from the mainline patch are relevant?
Yes he told me he was dropping that - he had exactly the same problems as I had documented here so I replied to the issue he raised on the git repo and pointed him back here. He dropped my patch into a pull request. This is the same patch I have already sent to the main crosstool-ng folks. gcc5.2.0 has already fixed this issue with cygwin64 and more so it's just a gcc 4.8.5 issue and it only affects the LTO .dll.
Oh and speaking of which, the generated cyglto_plugin-0.dll needs to be installed in $(TOOLCHAIN)/lib/bfd-plugins and not $(TOOLCHAIN)/libexec/gcc/xtensa-lx106-elf/<version>. I think this is a crosstool-ng build issue and not an esp-open-sdk problem. I think it's also generic and not just limited to being a cywin issue either.
BTW, I agree with you on the --disable-tui fix, and I implemented it in the same way. Because I'm building inside esp-open-sdk I just add the extra line to crosstool-config-overrides. One thing that annoys me a bit is that you can't do the same with the desired gcc version - the esp-open-sdk Makefile simply concatenated the overrides to the end of the sample config.in file, and in the case of gcc the existing version line (4.8.5) takes precedence. This means you have no choice but to fiddle with the sample config.in
- Mon Oct 31, 2016 12:37 am
#57419
In terms of the actual patches - I found that the changes I documented here were the only ones I needed to get a working toolchain for cygwin64 as a crosstool host, but by all means pull the whole lot. From what I can see, the only parts that are relevant to our work here are the config.host - we don't need cygwin64 as a gcc target in order to compile for esp8266.
What I did manually merge into your HEAD revision were the diffs from crosstool-ng/crosstool-ng that related to gcc 5.4.0 and gcc 6. If I can figure out why the sample isn't working then those would be useful updates.
I probably should have looked at where you were pulling your mainline from but I went straight to the top!
jcmvbkbc wrote:BTW, here ArchontPL posted pull request with the change from this thread. I took a look at how it was fixed in the gcc mainline and found a series of patches that added target, build and host cygwin support for x86_64. They do more than just changing gcc/config.host. I've added a comment with details there. davydnorris, can you check if other changes from the mainline patch are relevant?
In terms of the actual patches - I found that the changes I documented here were the only ones I needed to get a working toolchain for cygwin64 as a crosstool host, but by all means pull the whole lot. From what I can see, the only parts that are relevant to our work here are the config.host - we don't need cygwin64 as a gcc target in order to compile for esp8266.
What I did manually merge into your HEAD revision were the diffs from crosstool-ng/crosstool-ng that related to gcc 5.4.0 and gcc 6. If I can figure out why the sample isn't working then those would be useful updates.
I probably should have looked at where you were pulling your mainline from but I went straight to the top!
Last edited by davydnorris on Mon Oct 31, 2016 9:07 pm, edited 1 time in total.
- Mon Oct 31, 2016 1:43 am
#57420
OK and we are up and running again! Got my chip working with the IoT_Sample project 
gcc5.4.0 toolchain build from HEAD revision of jcmvbkbc/crosstool-NG with manually merged additions for 5.4.0 from crosstool-ng/crosstool-ng. Code was linked with crosstool-ng built libgcc.a after using my ar script to remove the built in functions.
Turns out it was LTO - I turned it off and everything's working OK. So now I need to work out why LTO would break the output, and whether it's even making a difference to begin with.
gcc5.4.0 toolchain build from HEAD revision of jcmvbkbc/crosstool-NG with manually merged additions for 5.4.0 from crosstool-ng/crosstool-ng. Code was linked with crosstool-ng built libgcc.a after using my ar script to remove the built in functions.
Turns out it was LTO - I turned it off and everything's working OK. So now I need to work out why LTO would break the output, and whether it's even making a difference to begin with.
