This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Supporting multiple runtime environments: How?


|    I'm looking for a way of allowing compile time selection of runtime
| environment (libc.a etc.) on the m68k-amigaos and ppc-amigaos targets.
| Currently, one can select between ixemul and libnix (m68k-amigaos only at
| this time), but it is not very cleanly implemented and relies on both
| environments to use the same include files. A recent addition is librilc
| (m68k-amigaos and ppc-amigaos), which uses completely different header files,
| and this is likely also the case with glibc, a possible fourth alternative in
| the future. Ideally the user should be able to select a runtime environment
| with a -runtime=<runtime> switch to gcc.
|
|    The problem is getting the preprocessor and linker to find the right
| header files, libraries and startup code. The specs file seems to be the
| right place to do this, but I'm having some problems. With the help of the %s
| operator, the linker finds startup code and libraries in
| <prefix>/lib/<runtime> (<prefix> as specified by --prefix and friends to
| configure) with constructs like
|
| *link_path:
| %{runtime=ixemul:-L ixemul%s}
|
| *startfile:
| %{runtime=ixemul:ixemul/crt0.o%s}
|
| but how do I make the preprocessor find header files in
| <prefix>/include/<runtime>? Despite many experiments with %s and -isystem,
| -iwithprefix and -iwithprefixbefore, I've not been able to come up with the
| right combination. Any ideas?

For the libraries and startup code, you probably want to look into using the
multilib support that is already in the compiler.  A multilib approach builds n
versions of the libraries with different switches and puts them in different
directories.  When you link, the compiler chooses the correct library/startup
file, based on the switches passed (it does require the flags used during
compilation to be used during linking if the ABI changes).  For example, the
PowerPC eabi compiler builds the following multilibs:

Subdirectory	Switches
============	========
.		-mrelocatable-lib -mno-eabi -mstrict-align
nof		-msoft-float -mrelocatable-lib -mno-eabi -mstrict-align
le		-mlittle -mrelocatable-lib -mno-eabi -mstrict-align
ca		-mcall-aix -mrelocatable-lib -mno-eabi -mstrict-align
sol		-mcall-solaris -mrelocatable-lib -mno-eabi -mstrict-align
lin		-mcall-linux -mrelocatable-lib -mno-eabi -mstrict-align
le/ca		-mlittle -mcall-aix -mrelocatable-lib -mno-eabi -mstrict-align
nof/le		-msoft-float -mlittle -mrelocatable-lib -mno-eabi -mstrict-align
nof/ca		-msoft-float -mcall-aix -mrelocatable-lib -mno-eabi -mstrict-align
nof/le/ca	-msoft-float -mlittle -mcall-aix -mrelocatable-lib -mno-eabi -mstrict-align

Thus if the user uses -msoft-float and -mlittle-endian, the compiler will
automatically look in the nof/le directory for libraries and startfiles.  Look
up MULTILIB_DEFAULTS in the target macros controlling the compilation driver
section of the manual and MULTILIB_{OPTIONS,DIRNAMES,MATCHES} in the target
Makefile fragment section.

One thing you might consider for the headers, is have the toplevel headers be
stubs that includes the real header from an appropriate subdirectory, based on
macros defined when compiling, ie stdio.h might look like:

	#ifdef __SYSTEM1__
	#include "system1/stdio.h"
	#define __GOT_STDIO_H__
	#endif

	#ifdef __SYSTEM2__
	#include "system2/stdio.h"
	#define __GOT_STDIO_H__
	#endif

	#ifndef __GOT_STDIO_H__
	#error "Unknown system"
	#endif

--
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]