This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bug with -finline-functions and va_start on FreeBSD
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: gcc at gcc dot gnu dot org
- Cc: wendling at ncsa dot uiuc dot edu
- Date: Wed, 29 Jan 2003 21:52:46 -0600 (CST)
- Subject: Re: Bug with -finline-functions and va_start on FreeBSD
- Organization: Networks and Infrastructure Lab (IL02/2240), Motorola Labs
In article <20030129183055.GA29947@ncsa.uiuc.edu> you write:
> I'm having a problem with gcc 3.2.1 on FreeBSD 4.7-STABLE for this piece
> of code:
>
> #include <stdio.h>
> #include <stdarg.h>
[...]
> When compiling with the following options:
>
> % gcc32 -o t t.c -finline-functions -fomit-frame-pointer -O2
>
> I get this error:
Your example works fine with gcc 3.2.1 and gcc 3.2.2 (prerelease)
built from FSF sources on i386-unknown-freebsd4.7. Based solely upon
the name you used to invoke the compiler, I suspect that you are
reporting a bug with a "FreeBSD ports" version of gcc. If I'm
correct, then please file it with freebsd.org not gcc.gnu.org.
To help yourself, please run this command on your machine:
% gcc32 -E t.c | grep /usr/local | nawk '{print $3}' | sort | uniq
If you don't see:
"/usr/local/lib/gcc-lib/i386-unknown-freebsd4.7/3.2.1/include/machine/ansi.h"
"/usr/local/lib/gcc-lib/i386-unknown-freebsd4.7/3.2.1/include/stdarg.h"
Then the bug to report to FreeBSD is this (or figure out yourself how
to fix the port ;-): "stdarg.h not installed when gcc built from
ports" & "fixincludes not run when gcc built from ports".
If you see the 2 lines, then, sorry, I have no idea what your problem
is.
> Is this a known problem? Is there a fix for this in the next release of
> gcc? :-)
The current FSF release does not have this problem. There has been a
bit of a "discussion" over this issue over the years (i.e. it is known
in my mind). The various BSD distros prefer to fix their system
headers as they break. The FSF side prefers to assume that all system
headers, from time to time, actually contain minor nits to be
addressed. Both positions have merit, but you just happened to be hit
by a case when the system header could not predict a change in gcc.
Regards,
Loren