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
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?
I downloaded a cross compiler that was made to make ppc elf binaries. I don't think there is an Apple supplied ppc elf cross compiler.
- 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.)
Come on people, switch to bash. It's better. What would we miss if we did switch to bash?
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.
Sorry for the confusion, I sent you my Linux distro's info that I tested on.
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?
Yes it does! I didn't even know about this feature. Thanks! When in 64-bit mode, I am able to build OpenBIOS with just a small change to the compiler prefix code. I would like to keep my patch as is because some people might need a 32-bit 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).
This line here in the switch-arch script would change i686 to x86: HOSTARCH=`uname -m | sed -e s/i.86/x86/
Thanks.
I downloaded a cross compiler that was made to make ppc elf binaries. I don't think there is an Apple supplied ppc elf cross compiler.
I'd suggest building your own binutils and gcc, it doesn't take too long and usually works a bit better.
(Unless others here think it's OK to depend on bash instead.)
Come on people, switch to bash. It's better. What would we miss if we did switch to bash?
I think there are probably quite a few people on tcsh or zsh. sh is virtually guaranteed, bash is not.
On Tue, Apr 14, 2015 at 12:39:09AM -0400, Programmingkid wrote:
Come on people, switch to bash. It's better. What would we miss if we did switch to bash?
bash is a better interactive shell. It is also _much_ slower at starting than dash, so as a shell for scripts, performance is noticeably better with dash as long as your scripts don't require bash features (most don't, but some legitimately do use some of bash's advanced features).
Switching from bash to dash as /bin/sh knocked 15 seconds off the boot time of an embedded system I work on.
But yes nothing wrong with using bash features as long as you explicitly state your script wants /bin/bash, not /bin/sh.
On 14/04/15 14:05, Lennart Sorensen wrote:
On Tue, Apr 14, 2015 at 12:39:09AM -0400, Programmingkid wrote:
Come on people, switch to bash. It's better. What would we miss if we did switch to bash?
bash is a better interactive shell. It is also _much_ slower at starting than dash, so as a shell for scripts, performance is noticeably better with dash as long as your scripts don't require bash features (most don't, but some legitimately do use some of bash's advanced features).
Switching from bash to dash as /bin/sh knocked 15 seconds off the boot time of an embedded system I work on.
But yes nothing wrong with using bash features as long as you explicitly state your script wants /bin/bash, not /bin/sh.
I would like to preserve the use of !/bin/sh where possible - I can't get too excited about forcing a user to have a specific shell installed.
ATB,
Mark.
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.
On Fri, 17 Apr 2015, Programmingkid wrote:
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.
4.8.2
Regards, BALATON Zoltan
-
BALATON Zoltan -
Cormac O'Brien -
Lennart Sorensen -
Mark Cave-Ayland -
Programmingkid