On Apr 13, 2015, at 6:03 PM, BALATON Zoltan wrote:
On Mon, 13 Apr 2015, Programmingkid wrote:
- instead on disabling -Werror completely you may want to try -fno-strict-aliasing (and if possible only set it for the file which exhibits this problem but I'm not sure how to do that with the used build system). The usb driver came from coreboot and probably had this problem there already but I did not see these warnings. It may be a peculiarity of your compiler or build environment.
There are differences between Apple's supplied gcc and what Linux users usually use. That could be the reason for the errors on Mac OS X. If it is possible to set that option for the problem file, I will try to do so. Disabling Werror doesn't seem like such a big deal. Without it I can see the warning messages and still continue compiling ... a win-win situation.
Warnings can sometimes hint at bugs so it's not something you can safely ignore. Werror makes sure we avoid what we can so if there's a way to disable just the one warning that causes problems and we know that can be ignored safely is better than allowing all warnings by disabling Werror in bulk. Are you trying to use the Apple supplied ppc cross compiler or did you install your own?
- At least on OS X 10.9 /bin/sh is the same as /bin/bash and /usr/bin/uname -m returns x86_64 (the same as I get on Linux) so these changes should not be needed. (I did not check on older versions though.)
The change from sh to bash was not to accommodate Mac OS X, it was to fix a problem on Linux. This code "filtered_list=${filtered_list:0:$end}" would fail on Debian Linux when the sh shell was set. I read on stackoverflow.com that Linux usually has sh set to Dash instead of bash. The switch in shells didn't cause anymore problems, so it seems good.
This depends on the linux distro, but it's true that if a script says #!/bin/sh it should avoid bash constructs and stick to plain sh or should name the shell it depends on. While bash is quite widespread I think it would be better to replace the above line with an awk construct that works with plain sh instead as described here:
https://wiki.ubuntu.com/DashAsBinSh
(Unless others here think it's OK to depend on bash instead.)
Are you running a 32 bit OS and compile for 64-bit target on that?
Not doing that. Here is the output of uname -a:
Linux debian 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012 x86_64 GNU/Linux
Now I'm confused. The patch title said it was for building on OS X.
On Mon, 13 Apr 2015, Programmingkid wrote:
I forgot to tell you that on Mac OS 10.6, uname -a only returns i386 on an amd64 (64bit x86) system. This causes OpenBIOS to fail while building. It looks like this issue has been corrected in Mac OS 10.9.
OS X can run as either 32bit or 64bit (but still can run 64bit apps with the 32bit kernel) and 10.6 defaults to 32bit according to this:
http://superuser.com/questions/161195/running-mac-os-x-10-6-but-uname-m-show...
so you probably have 32bit kernel and uname returns that. I think you can force booting 64bit if your machine supports it by holding 6 and 4 keys during boot or passing arch=x86_64 boot-arg to kernel. Does it make a difference it you boot with 64bit kernel?
I thought it might be a problem building on a 32bit machine so I've tried compiling as 32bit on Linux (with linux32 that also switches uname to return i686) but it compiled without problems for me that way too (after removing obj-ppc directory and running switch-arch again).
Regards, BALATON Zoltan
What version of GCC did you use to add the usb support to OpenBIOS? My gcc that causes the error message to show up is version 4.2.3.