Re: [OpenBIOS] Allow building on Mac OS X

[BALATON Zoltan]

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