New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix toolchain build #29

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
8 participants
@oblique
Contributor

oblique commented May 8, 2013

No description provided.

oblique added some commits May 8, 2013

Update GCC to 4.8.0
GCC 4.7.2 fails to compile
Add a patch for binutils 2.23.1
Without this patch, binutils fails to compile.
This patch will not be needed for binutils 2.24.
@erikarn

This comment has been minimized.

Show comment
Hide comment
@erikarn

erikarn May 9, 2013

Member

Hi!

I think this needs a bit more testing before we update the toolchain.

The last toolchain update caused all kinds of strange behaviour.

Would you please email the ath9k firmware list and ask for some more
wider testing?

Does this produce smaller code? Why should we update to the latest gcc
right now?

Adrian

On 8 May 2013 09:30, oblique notifications@github.com wrote:


You can merge this Pull Request by running

git pull https://github.com/oblique/open-ath9k-htc-firmware
fix-toolchain-build

Or view, comment on, or merge it at:

#29

Commit Summary

Update GCC to 4.8.0
Add a patch for binutils 2.23.1

File Changes

M Makefile (4)
A local/patches/binutils-elf32-xtensa-sec_cache.patch (20)

Patch Links:

https://github.com/qca/open-ath9k-htc-firmware/pull/29.patch
https://github.com/qca/open-ath9k-htc-firmware/pull/29.diff

Member

erikarn commented May 9, 2013

Hi!

I think this needs a bit more testing before we update the toolchain.

The last toolchain update caused all kinds of strange behaviour.

Would you please email the ath9k firmware list and ask for some more
wider testing?

Does this produce smaller code? Why should we update to the latest gcc
right now?

Adrian

On 8 May 2013 09:30, oblique notifications@github.com wrote:


You can merge this Pull Request by running

git pull https://github.com/oblique/open-ath9k-htc-firmware
fix-toolchain-build

Or view, comment on, or merge it at:

#29

Commit Summary

Update GCC to 4.8.0
Add a patch for binutils 2.23.1

File Changes

M Makefile (4)
A local/patches/binutils-elf32-xtensa-sec_cache.patch (20)

Patch Links:

https://github.com/qca/open-ath9k-htc-firmware/pull/29.patch
https://github.com/qca/open-ath9k-htc-firmware/pull/29.diff

@oblique

This comment has been minimized.

Show comment
Hide comment
@oblique

oblique May 10, 2013

Contributor

The reason I updated GCC is because 4.7.2 fails to compile. What toolchain versions you had before?

Contributor

oblique commented May 10, 2013

The reason I updated GCC is because 4.7.2 fails to compile. What toolchain versions you had before?

@niklas88

This comment has been minimized.

Show comment
Hide comment
@niklas88

niklas88 Jun 27, 2013

I can no longer compile the toolchain with current GCC 4.8.1 as shipped on Arch Linux, it fails with the following error
http://pastebin.com/MbHzyuBF

niklas88 commented Jun 27, 2013

I can no longer compile the toolchain with current GCC 4.8.1 as shipped on Arch Linux, it fails with the following error
http://pastebin.com/MbHzyuBF

@hemlockII

This comment has been minimized.

Show comment
Hide comment
@hemlockII

hemlockII Aug 25, 2013

I can also confirm the failure to build with GCC 4.7.2. Also, (probably due to lack of enough linux experience) have never seen a build process involving "make toolchain" before; why ship gcc binutils etc when you can use the local one I already have?

hemlockII commented Aug 25, 2013

I can also confirm the failure to build with GCC 4.7.2. Also, (probably due to lack of enough linux experience) have never seen a build process involving "make toolchain" before; why ship gcc binutils etc when you can use the local one I already have?

@erikarn

This comment has been minimized.

Show comment
Hide comment
@erikarn

erikarn Aug 25, 2013

Member

Hi!

Do you have a locally installed tensilica toolchain?

The whole point here is to create binaries that exactly match what we have.
The firmware build process could use a locally installed tensilica
toolchain but then the generated binaries may be different and the bugs and
behaviour may differ in subtle ways.

Doing it this way ensures everyone is on the same page and has the same
code generated.

-adrian

On 24 August 2013 20:04, hemlockII notifications@github.com wrote:

I can also confirm the failure to build with GCC 4.7.2. Also, (probably
due to lack of enough linux experience) have never seen a build process
involving "make toolchain" before; why ship gcc binutils etc when you can
use the local one I already have?


Reply to this email directly or view it on GitHubhttps://github.com//pull/29#issuecomment-23220982
.

Member

erikarn commented Aug 25, 2013

Hi!

Do you have a locally installed tensilica toolchain?

The whole point here is to create binaries that exactly match what we have.
The firmware build process could use a locally installed tensilica
toolchain but then the generated binaries may be different and the bugs and
behaviour may differ in subtle ways.

Doing it this way ensures everyone is on the same page and has the same
code generated.

-adrian

On 24 August 2013 20:04, hemlockII notifications@github.com wrote:

I can also confirm the failure to build with GCC 4.7.2. Also, (probably
due to lack of enough linux experience) have never seen a build process
involving "make toolchain" before; why ship gcc binutils etc when you can
use the local one I already have?


Reply to this email directly or view it on GitHubhttps://github.com//pull/29#issuecomment-23220982
.

@alexander-naumov

This comment has been minimized.

Show comment
Hide comment
@alexander-naumov

alexander-naumov Sep 1, 2013

Hi guys,
I have the same error (as niklas88 has) during compiling the toolchain.
I got it with gcc-4.8-1.3.i586 (openSUSE 13.1-m4).

2oblique:
does your brange fix this problem?

alexander-naumov commented Sep 1, 2013

Hi guys,
I have the same error (as niklas88 has) during compiling the toolchain.
I got it with gcc-4.8-1.3.i586 (openSUSE 13.1-m4).

2oblique:
does your brange fix this problem?

@oblique

This comment has been minimized.

Show comment
Hide comment
@oblique

oblique Sep 1, 2013

Contributor

Well, it compiles. But I don't know if there are any strange behaviours. Give it a try

Contributor

oblique commented Sep 1, 2013

Well, it compiles. But I don't know if there are any strange behaviours. Give it a try

@alexander-naumov

This comment has been minimized.

Show comment
Hide comment
@alexander-naumov

alexander-naumov commented Sep 1, 2013

Using this repo: https://github.com/oblique/open-ath9k-htc-firmware
I got the same error...

@oblique

This comment has been minimized.

Show comment
Hide comment
@oblique

oblique Sep 1, 2013

Contributor

I don't get any errors, make sure that you're in the fix-toolchain-build branch.
If you're not in, just do: git checkout fix-toolchain-build

Contributor

oblique commented Sep 1, 2013

I don't get any errors, make sure that you're in the fix-toolchain-build branch.
If you're not in, just do: git checkout fix-toolchain-build

@niklas88

This comment has been minimized.

Show comment
Hide comment
@niklas88

niklas88 Sep 7, 2013

That branch's build instructions are outdated though, it doesn't actually have a ./build script anymore.
Also I'm getting the following build error http://pastebin.com/df9Z4ehK which I guess is a case of the new GCC behaviour to use language constraints for upper bounds of loop iterations and will likely break code, see http://gcc.gnu.org/gcc-4.8/changes.html .
It would be best to fix the loops but in the meantime -fno-aggressive-loop-optimizations should give the old behaviour.

niklas88 commented Sep 7, 2013

That branch's build instructions are outdated though, it doesn't actually have a ./build script anymore.
Also I'm getting the following build error http://pastebin.com/df9Z4ehK which I guess is a case of the new GCC behaviour to use language constraints for upper bounds of loop iterations and will likely break code, see http://gcc.gnu.org/gcc-4.8/changes.html .
It would be best to fix the loops but in the meantime -fno-aggressive-loop-optimizations should give the old behaviour.

@jaysonlarose

This comment has been minimized.

Show comment
Hide comment
@jaysonlarose

jaysonlarose Apr 22, 2014

8 months later, and I'm still seeing the same error that niklas88 was, on both an Ubuntu 14.04 LTS virtual machine and a Debian Jessie/Sid ARM box.

Fix it? Post a workaround? Better still, post firmware binaries, since I really have no interest in the magic of the build process?

jaysonlarose commented Apr 22, 2014

8 months later, and I'm still seeing the same error that niklas88 was, on both an Ubuntu 14.04 LTS virtual machine and a Debian Jessie/Sid ARM box.

Fix it? Post a workaround? Better still, post firmware binaries, since I really have no interest in the magic of the build process?

@erikarn

This comment has been minimized.

Show comment
Hide comment
@erikarn

erikarn Apr 22, 2014

Member

hi,

gcc-4.7.2 fails to compile beacuse the ubuntu compiler suite defaults to
-Werror and it spits out problems.

Updating to gcc-4.8.0 means that there may be a whole new round of code
generation bugs and/or bad source code (ie, not C-anything compliant) that
lead to code generation that changes the behaviour of the firmware.

So in order to update to gcc-4.8.0 and the later binutils, the firmware
itself has to be throughly tested. I just don't have the time to do that
right now. If others can run it with these patches and validate that they
don't see any issues, then I'll merge the pull request.

I hope that makes sense.

-a

On 22 April 2014 13:13, jaysonlarose notifications@github.com wrote:

8 months later, and I'm still seeing the same error that niklas88 was, on
both an Ubuntu 14.04 LTS virtual machine and a Debian Jessie/Sid ARM box.

Fix it? Post a workaround? Better still, post firmware binaries, since I
really have no interest in the magic of the build process?


Reply to this email directly or view it on GitHubhttps://github.com//pull/29#issuecomment-41089710
.

Member

erikarn commented Apr 22, 2014

hi,

gcc-4.7.2 fails to compile beacuse the ubuntu compiler suite defaults to
-Werror and it spits out problems.

Updating to gcc-4.8.0 means that there may be a whole new round of code
generation bugs and/or bad source code (ie, not C-anything compliant) that
lead to code generation that changes the behaviour of the firmware.

So in order to update to gcc-4.8.0 and the later binutils, the firmware
itself has to be throughly tested. I just don't have the time to do that
right now. If others can run it with these patches and validate that they
don't see any issues, then I'll merge the pull request.

I hope that makes sense.

-a

On 22 April 2014 13:13, jaysonlarose notifications@github.com wrote:

8 months later, and I'm still seeing the same error that niklas88 was, on
both an Ubuntu 14.04 LTS virtual machine and a Debian Jessie/Sid ARM box.

Fix it? Post a workaround? Better still, post firmware binaries, since I
really have no interest in the magic of the build process?


Reply to this email directly or view it on GitHubhttps://github.com//pull/29#issuecomment-41089710
.

@jaysonlarose

This comment has been minimized.

Show comment
Hide comment
@jaysonlarose

jaysonlarose Apr 22, 2014

Makes perfect sense... but all I need is the end product; a built-and-good copy of htc_9271.fw. :)

jaysonlarose commented Apr 22, 2014

Makes perfect sense... but all I need is the end product; a built-and-good copy of htc_9271.fw. :)

@erikarn

This comment has been minimized.

Show comment
Hide comment
@erikarn

erikarn Apr 22, 2014

Member

Hi!

Well, ask around to see how to convince the ubuntu tool(s) to not enable
Werror by default.

-a

On 22 April 2014 13:49, jaysonlarose notifications@github.com wrote:

Makes perfect sense... but all I need is the end product; a built-and-good
copy of htc_9271.fw. :)


Reply to this email directly or view it on GitHubhttps://github.com//pull/29#issuecomment-41093741
.

Member

erikarn commented Apr 22, 2014

Hi!

Well, ask around to see how to convince the ubuntu tool(s) to not enable
Werror by default.

-a

On 22 April 2014 13:49, jaysonlarose notifications@github.com wrote:

Makes perfect sense... but all I need is the end product; a built-and-good
copy of htc_9271.fw. :)


Reply to this email directly or view it on GitHubhttps://github.com//pull/29#issuecomment-41093741
.

@jaysonlarose

This comment has been minimized.

Show comment
Hide comment
@jaysonlarose

jaysonlarose Apr 22, 2014

That still means I have to compile the thing, and to compile the toolchain I need to compile the thing.

I guess there's something I'm not quite understanding here.... Is there any particular reason why you aren't make binary open-ath9k firmware images available? It is "open", after all...

jaysonlarose commented Apr 22, 2014

That still means I have to compile the thing, and to compile the toolchain I need to compile the thing.

I guess there's something I'm not quite understanding here.... Is there any particular reason why you aren't make binary open-ath9k firmware images available? It is "open", after all...

@erikarn

This comment has been minimized.

Show comment
Hide comment
@erikarn

erikarn Apr 23, 2014

Member

There's a binary firmware image in the Linux firmware git repository.
(linux-firmware.git.)

-a

On 22 April 2014 16:51, jaysonlarose notifications@github.com wrote:

That still means I have to compile the thing, and to compile the toolchain
I need to compile the thing.

I guess there's something I'm not quite understanding here.... Is there
any particular reason why you aren't make binary open-ath9k firmware images
available? It is "open", after all...


Reply to this email directly or view it on GitHubhttps://github.com//pull/29#issuecomment-41110132
.

Member

erikarn commented Apr 23, 2014

There's a binary firmware image in the Linux firmware git repository.
(linux-firmware.git.)

-a

On 22 April 2014 16:51, jaysonlarose notifications@github.com wrote:

That still means I have to compile the thing, and to compile the toolchain
I need to compile the thing.

I guess there's something I'm not quite understanding here.... Is there
any particular reason why you aren't make binary open-ath9k firmware images
available? It is "open", after all...


Reply to this email directly or view it on GitHubhttps://github.com//pull/29#issuecomment-41110132
.

@olerem

This comment has been minimized.

Show comment
Hide comment
@olerem

olerem Apr 28, 2014

Contributor

hmm... this image seems to be from 2011.

Contributor

olerem commented Apr 28, 2014

hmm... this image seems to be from 2011.

@erikarn

This comment has been minimized.

Show comment
Hide comment
@erikarn

erikarn Apr 28, 2014

Member

The images are still binary API comaptible right? We should build a new one.

-a

On 28 April 2014 15:05, Oleksij Rempel notifications@github.com wrote:

hmm... this image seems to be from 2011.


Reply to this email directly or view it on GitHubhttps://github.com//pull/29#issuecomment-41619731
.

Member

erikarn commented Apr 28, 2014

The images are still binary API comaptible right? We should build a new one.

-a

On 28 April 2014 15:05, Oleksij Rempel notifications@github.com wrote:

hmm... this image seems to be from 2011.


Reply to this email directly or view it on GitHubhttps://github.com//pull/29#issuecomment-41619731
.

@olerem

This comment has been minimized.

Show comment
Hide comment
@olerem

olerem Apr 28, 2014

Contributor

Yes, then lets build it at the end of this week. I'll try to finish my patchset

Contributor

olerem commented Apr 28, 2014

Yes, then lets build it at the end of this week. I'll try to finish my patchset

@look-a-squirrel

This comment has been minimized.

Show comment
Hide comment
@look-a-squirrel

look-a-squirrel Apr 29, 2014

For anyone in need of an up-to-date build patch, they can use look-a-squirrel@ebc6cb1 which will

  • Update GCC to version 4.8.2
  • Pass -fno-aggressive-loop-optimizations
  • Apply the trivial binutils patch

look-a-squirrel commented Apr 29, 2014

For anyone in need of an up-to-date build patch, they can use look-a-squirrel@ebc6cb1 which will

  • Update GCC to version 4.8.2
  • Pass -fno-aggressive-loop-optimizations
  • Apply the trivial binutils patch
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment