This is the mail archive of the
mailing list for the GCC project.
Re: Getting rid of -g
- To: Roman Lechtchinsky <rl at cs dot tu-berlin dot de>
- Subject: Re: Getting rid of -g
- From: Manfred Hollstein <manfred dot h at gmx dot net>
- Date: Thu, 13 Sep 2001 11:17:14 +0200
- CC: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>, gcc at gcc dot gnu dot org, schwab at suse dot de
- References: <Pine.SOL.4.10.10109130959001.15733-100000@sossusvlei>
- Reply-To: manfred dot h at gmx dot net
Roman Lechtchinsky wrote:
> On Wed, 12 Sep 2001, Manfred Hollstein wrote:
> > The only package which is compiled using plain cc is libiberty,
> > all other packages will be built using gcc, so there should be no
> > need to avoid using '-g' for those packages. Regarding libiberty,
> > you should create a similar config file in the libiberty/config
> > directory and put suitable code into libiberty/config.table.
> Nope, this doesn't work because both CFLAGS and LIBCFLAGS (it's the latter
> which is actually used for compiling libiberty) are overridden by the
> top-level makefile. I've added a Unicos-specific config file to the
> top-level config directory and set host_makefile_frag in configure.in
> appropriately. This seems to work but is this really the right way to do
> it? Should I additionally do what you suggest to ensure that the correct
> flags are passed if libiberty is built separately?
Fixing this in the top-level configury is definitely the wrong way,
simply because one has to remember to put the same fix into the
local files as well, as you described.
Hmm... I'd suggest you add code to libiberty's aclocal.m4, which
initializes a new autoconf variable ac_libiberty_debuginfo_cflags
depending on whether the compiler is capable of generating proper
code and debugging info or not; this doesn't necessarily mean that
you have to actually compile code at configure time, but you can
define its value based on some host specific libiberty/config/*
file with a default of '-g' instead. This code should be added to the
definition of the LIB_AC_PROG_CC function in a similar fashion as
we are already doing for ac_libiberty_warn_cflags. libiberty's
Makefile.in can then use this in the definition of COMPILE.c
How about that?