[adtools] Re: questions about the GCC port
- From: Gunther Nikl <gni@xxxxxxxx>
- To: adtools@xxxxxxxxxxxxx
- Date: Mon, 1 Aug 2005 15:35:24 +0200
On Fri, Jul 29, 2005 at 07:24:12PM +0200, Andrija Antonijevic wrote:
> > Probably nobody wanted to override the generic [TARGET_CPU_CPP_BUILTINS]
> > defintion. IMHO using a custom defintion isn't a difficult issue.
>
> OK.
Now I am leaning more towards keeping the current implementation at least
for now :-)
> > TARGET_OS_CPP_BUILTINS.
>
> Ah, of course, I ignored the fact that this is a code snippet and not a
> bunch of #define's.
>
> >I can update these parts.
>
> OK, thanks.
Will do.
> BTW, besides HEAD which is currently for gcc 4.0.1, there is also
> AMIGA_GCC_3 branch for gcc 3.x.x since 4.0.1 currently expiriences
> internal compiler errors when compiling some C++ code.
Maybe this is a generic error? You should check against FSF version.
I am still using older GCC versions only.
> I suppose the files in AMIGA_GCC_3 branch needn't be updated right
> away until we settle for the changes in the HEAD.
Backporting to 3.4.x shouldn't be a big issue. AFAICT 3.4.x and 4.0.x
are compatible in this area.
> > One could pass "-mcrt=clib2" to the compiler if no -mcrt= was given.
>
> Is this possible through the specs file? I mean, I know it's possible to
> do it f. ex. like below with amigaos_crt_string, but I think it wouldn't
> propagate to the specs file.
Thats correct. You would have to specify the default for every program
(compiler, linker) and you can't test for such injected arguments.
> Also, I believe I have tested something like %{!mcrt=*: -mcrt=newlib},
> but it didn't work. Is there a way to do it?
Your example does what one would expect, it passes -mcrt=newlib if no
other mcrt= options was given.
> If there is, then multilib building would be a bit easier, it would be
> possible to tell it that default option is -mcrt=xxx (or -mcrt=default
> and that -mcrt=default is equivalent to -mcrt=xxx).
Let me state, that I don't have any experience with multilib. The m68k
port never used that. The 68k port used the the multilib infrastructure
to build several flavours of libgcc.a. The selection which to use was
done by the linker. I don't know how exactly multilib works.
> What I would like to do with multilib is to say: default is f. ex.
> -mcrt=clib2, other options are -mcrt=clib2-ts, -mcrt=newlib, -msoft-float,
> -mbaserel. Build [combinations that make sense] and put them to
> lib/(clib2|clib2-ts|newlib)/(|soft-float|baserel).
>
> The only problem with this is that default goes to lib and I didn't see a
> way to specify where the default should go with MULTILIB_* specifiers. So,
> it would build lib/*.a, lib/soft-float/*.a, lib/baserel/*.a for f. ex.
> clib2 and lib/newlib/*.a, lib/newlib/soft-float/*.a and
> lib/newlib/baserel/*.a.
>
> That would be fine, I guess (we would still continue to use full hierarchy
> inside SDK: where the C libraries are installed, only things inside GCC:
> would be placed like this) but it would make it impossible to change the
> default C lib through the specs file.
You mean by editing the specs file later? Thats indeed impossible.
AFAICT such a change needs a recompile. I am afraid I can't help
with these issues.
> > #define CRT_SPEC
>
> I think all of them should be able to be unified using this, only clib2
> will require special handling. It will probably boil down to %{for clib2:
> clib2_specific; all others in one line using %(crt)}
Thats right :-) I had to keep all the clib2 defines because of its -ts
version.
> > --- 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"},
I haven't seen any port doing it that way, eg. SUBTARGET_OPTIONS in
rs6000/sysv4.h uses "0" there and sets eg. rs6000_abi_name in
SUBTARGET_OVERRIDE_OPTIONS (4.1 initializes at the declaration).
> > Using a define to initialize the default case should probably be done.
>
> The default C lib wouldn't be settable by changing the specs file, then.
I would recommend against changing the meaning of "default".
> Whether this is a problem depends on the multilib situation and also if
> it's possible to specify default -mcrt=xxx line to the compiler like (I
> hope) you hinted it's possible above.
I don't know if multilib supports your needs.
> Actually, switching them [C lib] on the fly works very well after the
> build is completed and the files put to their places. The "only" problems
> while are while building:
>
> 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)
>
> I have compared the builds done with -mcrt=clib2 and -mcrt=newlib and,
> except the binaries and linker libraries, the only differences were
> files from 2) and 3).
>
> 1) is currently done by hand, but hopefully can be done with multilib
>
> 2) is also done by hand, #ifdef __CLIB2__ [contents for clib2] #elif
> defined(__NEWLIB__) ... #endif, but I suppose Makefile.am can be changed to
> fix this.
Well, I don't think multilib was/is intended for the purpose the OS4
port tries to use it. Switching the runtime environment isn't supported
by GCC. It simply doesn't expect this. AFAIK, multilib was invented to
support different calling conventions or cpu versions.
> 3) these need not be built at all
You could use "--disable-libstdcxx-pch" to disable PCH.
Gunther
--
Linux is only free if your time has no value
- Jamie Zawinski
______________________________________________________________________________
Amiga Development tools ML - //www.freelists.org/list/adtools
Homepage...................: http://www.sourceforge.net/projects/adtools
Listserver help............: mailto:adtools-request@xxxxxxxxxxxxx?Subject=HELP
Other related posts:
