On 29-Jul-2005, Gunther Nikl wrote:
On Thu, Jul 28, 2005 at 07:55:32PM +0200, Andrija Antonijevic wrote:On 28-Jul-2005, Gunther Nikl wrote:
Its probably also a good idea to move some stuff into TARGET_CPU_CPP_BUILTINS.
I think that builtin_define_std ("PPC") and two builtin_assert's should probably stay since they are also in the same place in sysv4.h
As for powerpc and __powerpc__ builtin_define's (well, they would merge into one builtin_define_std), your suggestion does make sense. On the other hand, every config file from rs6000 that defines __powerpc__, does it in TARGET_OS_CPP_BUILTINS. In short, I have no idea :)
Probably nobody wanted to override the generic defintion. IMHO using a custom defintion isn't a difficult issue.
OK.
- CPP_<clib>_SPEC: All symbol definitions should be moved into the compiler since builtin_define_std() knows better how to deal with -ansi and -std=. Since the used crt is recorded in amigaos_crt_string thats not all that hard.
That seems like a good idea. Do you know what is the right place to put this code to?
TARGET_OS_CPP_BUILTINS.
I can update these parts.
If -mcrt is not specified, whatever parses amigaos_crt_string would have to use the default value for clib and that value shouldn't be hardcoded but read f. ex. from %(crt) specs string. However, I suppose it is possible for the code to have a specs string evaluated?
One could pass "-mcrt=clib2" to the compiler if no -mcrt= was given.
Currently I hardcoded clib2 as default in all places where it was needed (I already folded newlib/ixemul/libnix to see if that would work):
--- rs6000/amigaos.h --- #define CRT_SPEC "\ %{mcrt=clib2|mcrt=clib2-ts:clib2; \ mcrt=ixemul:ixemul; \ mcrt=libnix:libnix; \ mcrt=newlib|newlib:newlib; \ mcrt=default|!mcrt=*:clib2; \ : %eInvalid C runtime library}" --- rs6000/amigaos.h --
If the C lib definitions stay separated, CRT_SPEC isn't necessary.
--- rs6000/amigaos.c --- const char *amigaos_crt_string="clib2"; --- rs6000/amigaos.c ---
I *think* this can be done by replacing
{ "crt=", &amigaos_crt_string, N_("Select C runtime library"), 0}, with { "crt=", &amigaos_crt_string, N_("Select C runtime library"), "clib2"},
Using a define to initialize the default case should probably be done.
[C lib handling]
I agree, it is very complicated :I I did it like this since at the time the specs file was changing wildly and this approach made sure that the specs for each clib can be modified without changing the structure of the specs file (there were problems with C++ backend if the structure was changed since it then used some parts from the builtin specs file and some from the external specs file).
I can see the benefit from having separate clib definitions.
Anyway, things have stabilized a bit now, so I suppose this can be cleaned up a bit. I'll see to this as soon as I find some time.
I was merely exploring an idea here, although I already tried this idea in my workspace.
Sure, thinking about possible improvements is always a good thing :)
If you build the ppc-amigaos compiler, you will find that build process is a bit of a mess: f. ex. libstdc++.a is built only for the default C library and needs to be moved around etc.
Since every C lib has its own headers I can see that every flavour needs its own libraries.
The goal is to be able to change the default clib, but I'm affraid this complicates things a lot when using multilib :I
Another thing that needs fixing is c++config.h for different clib's, but that's another story...
That probably suggests that switching the crt on the fly isn't going to work reliable. In that case one needs different compiler installation but thats another set of problems.
1) location of the linker libraries which needs to be changed after building 2) c++config.h which doesn't take care of used C lib 3) precompiled C++ header files, same reason as 2)
1) is currently done by hand, but hopefully can be done with multilib
3) these need not be built at all
Andrija ______________________________________________________________________________ Amiga Development tools ML - //www.freelists.org/list/adtools Homepage...................: http://www.sourceforge.net/projects/adtools Listserver help............: mailto:adtools-request@xxxxxxxxxxxxx?Subject=HELP