This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] make check-abi
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Phil Edwards <phil at jaj dot com>
- Cc: rittle at latour dot rsch dot comm dot mot dot com, gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Fri, 23 Aug 2002 09:41:30 -0700
- Subject: Re: [v3] make check-abi
- Organization: Red Hat / San Francisco
- References: <200208222001.g7MK1Od03578@fillmore.constant.com><200208230336.g7N3aqvJ097906@latour.rsch.comm.mot.com><20020823020204.A6397@disaster.jaj.com>
> > Shall we tweak the configure fragments as required so that if
> > config/abi/CPU-VENDOR-OSX.Y/baseline_symbols.txt is not found then
> > (at least) config/abi/CPU-VENDOR-OSX/baseline_symbols.txt and then (maybe)
> > config/abi/CPU-VENDOR-OS/baseline_symbols.txt are candidates for use.
> >
> > gcc 3.2 on CPU-unknown-freebsd4 has one C++ ABI and gcc 3.2 on
> > CPU-unknown-freebsd5 may have another (although it may coincidentally
> > be identical). By default, the target triples constructed by
> > config.guess on FreeBSD, Solaris and elsewhere add the OS version
> > number.
>
> I would advocate having the baseline_symbols file be stored in a variable.
> The variable is guessed as a default, and then configure.target can override
> it, e.g., in the very bottom clause testing for both cpu and os.
>
> Then we export the variable to the Makefiles.
>
>
> What do you think?
I'm open to the idea of coalescing the cpu/os info, and have no strong
feelings on the best way to do it.
-benjamin