Hi all,
While setting up a PPC cross-compiler environment for OpenBIOS, I noticed that the default cross-compiler prefix is set to 'powerpc-linux-gnu-' as opposed to 'powerpc-elf-'.
Is there any particular reason that we need the linux platform version, instead of the elf version which is used by SPARC? The reason I ask is that the Linux platform version is much much harder to compile as you need an extra set of glibc headers and have to bootstrap the gcc build by hand in order to produce the working final compiler.
The only reason is because I use "powerpc-linux-gnu-gcc", but I agree it is much harder to produce. But I produce my cross-compile environment from debian packages, which seems simpler.
Do you know if there is a "powerpc-elf-gdb" ?
On my tests here everything seems to work fine with just the 'powerpc-elf-' prefix as far as I can tell.
If you provide a patch, I agree to apply it.
Regards, Laurent
On 11/25/09 1:03 PM, Laurent Vivier wrote:
Hi all,
While setting up a PPC cross-compiler environment for OpenBIOS, I noticed that the default cross-compiler prefix is set to 'powerpc-linux-gnu-' as opposed to 'powerpc-elf-'.
Is there any particular reason that we need the linux platform version, instead of the elf version which is used by SPARC? The reason I ask is that the Linux platform version is much much harder to compile as you need an extra set of glibc headers and have to bootstrap the gcc build by hand in order to produce the working final compiler.
The only reason is because I use "powerpc-linux-gnu-gcc", but I agree it is much harder to produce. But I produce my cross-compile environment from debian packages, which seems simpler.
Do you know if there is a "powerpc-elf-gdb" ?
I've been building powerpc-elf tool chains with our small multi platform cross compiler script:
http://tracker.coreboot.org/trac/coreboot/browser/trunk/util/crossgcc
and it produces powerpc-elf-gdb ....
Stefan
Laurent Vivier wrote:
Is there any particular reason that we need the linux platform version, instead of the elf version which is used by SPARC? The reason I ask is that the Linux platform version is much much harder to compile as you need an extra set of glibc headers and have to bootstrap the gcc build by hand in order to produce the working final compiler.
The only reason is because I use "powerpc-linux-gnu-gcc", but I agree it is much harder to produce. But I produce my cross-compile environment from debian packages, which seems simpler.
Do you know if there is a "powerpc-elf-gdb" ?
Not sure, although I ended up building gdb by hand for my SPARC setup here and it seemed to work ok. Interestingly enough, I had to use 'sparc64-linux' as a platform just for gdb in order to get the 64-bit register support built in, but it seems to work.
On my tests here everything seems to work fine with just the 'powerpc-elf-' prefix as far as I can tell.
If you provide a patch, I agree to apply it.
I think the best overall solution would be to simply search for both the -elf and -linux versions in switch-arch and pick the first one found - does that work for everyone?
ATB,
Mark.
On 11/25/09 1:21 PM, Mark Cave-Ayland wrote:
I think the best overall solution would be to simply search for both the -elf and -linux versions in switch-arch and pick the first one found - does that work for everyone?
While we're at it... We have a similar script in coreboot, ... "xcompile" searches for a suitable compiler and is run by the top level Makefile:
http://tracker.coreboot.org/trac/coreboot/browser/trunk/util/xcompile/xcompi...
What are the general feelings towards the configuration system? The XML make stuff never really was an improvement over Kconfig + Kbuild, so we might move over to that... Lot's of people know it, it's easy to integrate, and it's not another layer on top of make.
Stefan
On Wed, Nov 25, 2009 at 2:38 PM, Stefan Reinauer stepan@coresystems.de wrote:
On 11/25/09 1:21 PM, Mark Cave-Ayland wrote:
I think the best overall solution would be to simply search for both the -elf and -linux versions in switch-arch and pick the first one found - does that work for everyone?
While we're at it... We have a similar script in coreboot, ... "xcompile" searches for a suitable compiler and is run by the top level Makefile:
http://tracker.coreboot.org/trac/coreboot/browser/trunk/util/xcompile/xcompi...
I think it would be best to specify the cross-prefix at config time. Guessing may get wrong results.
What are the general feelings towards the configuration system? The XML make stuff never really was an improvement over Kconfig + Kbuild, so we might move over to that... Lot's of people know it, it's easy to integrate, and it's not another layer on top of make.
QEMU has nowadays a very clean configure vs. Makefile split (thanks to Juan Quintela). Most if not all decisions are made at configure time, Makefiles just use the CONFIG_xxx variables as told by configure. I'd like to use a similar setup. Though QEMU does not have a deep subdirectory layout which OpenBIOS has, that makes things easier for them.
Am 25.11.2009 um 13:38 schrieb Stefan Reinauer:
What are the general feelings towards the configuration system? The XML make stuff never really was an improvement over Kconfig + Kbuild, so we might move over to that... Lot's of people know it, it's easy to integrate, and it's not another layer on top of make.
Kconfig + Kbuild would be Just Another Dependency(tm), I fear.
On Mac OS X, after building GMP, MPFR, binutils and GCC, cross- compilation for sparc64 still fails due to header/type errors. Adding more dependencies for the build system is unlikely to increase the portability of OpenBIOS.
Andreas
On 11/26/09 8:24 PM, Andreas Färber wrote:
Am 25.11.2009 um 13:38 schrieb Stefan Reinauer:
What are the general feelings towards the configuration system? The XML make stuff never really was an improvement over Kconfig + Kbuild, so we might move over to that... Lot's of people know it, it's easy to integrate, and it's not another layer on top of make.
Kconfig + Kbuild would be Just Another Dependency(tm), I fear.
To which components in particular?
Stefan
Am 26.11.2009 um 21:26 schrieb Stefan Reinauer:
On 11/26/09 8:24 PM, Andreas Färber wrote:
Am 25.11.2009 um 13:38 schrieb Stefan Reinauer:
What are the general feelings towards the configuration system? The XML make stuff never really was an improvement over Kconfig + Kbuild, so we might move over to that... Lot's of people know it, it's easy to integrate, and it's not another layer on top of make.
Kconfig + Kbuild would be Just Another Dependency(tm), I fear.
To which components in particular?
To OpenBIOS, if you replace GNU make with Your Favorite Non-standard Build System? :)
Andreas
On 11/26/09 9:36 PM, Andreas Färber wrote:
Am 26.11.2009 um 21:26 schrieb Stefan Reinauer:
On 11/26/09 8:24 PM, Andreas Färber wrote:
Am 25.11.2009 um 13:38 schrieb Stefan Reinauer:
What are the general feelings towards the configuration system? The XML make stuff never really was an improvement over Kconfig + Kbuild, so we might move over to that... Lot's of people know it, it's easy to integrate, and it's not another layer on top of make.
Kconfig + Kbuild would be Just Another Dependency(tm), I fear.
To which components in particular?
To OpenBIOS, if you replace GNU make with Your Favorite Non-standard Build System? :)
Now you have me confused... Kconfig / Kbuild would be integrated into the OpenBIOS tree, just as my xmlmake build system is now. So dependencies to libxstl / xsltproc would go away, and a dependency to (n)curses would instead come in... I don't see that as a big risk. But I'm quite open to suggestions. At least libxslt on Debian seems to be fixed now, it's been a while since people complained about that breaking...
Stefan
Am 26.11.2009 um 22:29 schrieb Stefan Reinauer:
On 11/26/09 9:36 PM, Andreas Färber wrote:
Am 26.11.2009 um 21:26 schrieb Stefan Reinauer:
On 11/26/09 8:24 PM, Andreas Färber wrote:
Am 25.11.2009 um 13:38 schrieb Stefan Reinauer:
What are the general feelings towards the configuration system? The XML make stuff never really was an improvement over Kconfig + Kbuild, so we might move over to that... Lot's of people know it, it's easy to integrate, and it's not another layer on top of make.
Kconfig + Kbuild would be Just Another Dependency(tm), I fear.
To which components in particular?
To OpenBIOS, if you replace GNU make with Your Favorite Non-standard Build System? :)
Now you have me confused... Kconfig / Kbuild would be integrated into the OpenBIOS tree, just as my xmlmake build system is now. So dependencies to libxstl / xsltproc would go away, and a dependency to (n)curses would instead come in...
No objection from my side then.
Andreas
-
Andreas Färber -
Blue Swirl -
Laurent Vivier -
Mark Cave-Ayland -
Stefan Reinauer