[ovs-dev] [PATCH RFC] automake: fix rte_memcopy for gcc versions <=4.8.2

Ben Pfaff blp at nicira.com
Thu Apr 2 16:45:26 UTC 2015


On Thu, Apr 02, 2015 at 04:38:13PM +0000, Kavanagh, Mark B wrote:
> 
> >On 04/01/15 at 07:45am, Kavanagh, Mark B wrote:
> >>
> >> >What's wrong with setting CFLAGS on the "configure" or "make" command
> >> >line?  This is the standard way to do this with Automake and Autoconf.
> >> >
> >>
> >> Sure. However, setting CFLAGS on the command line overwrites any values CFLAGS has
> >attained via the 'configure' step. The most obvious symptom of this is significantly
> >degraded performance, due to the fact that the optimization flags passed to CFLAGS during
> >'configure' are overwritten by the command line value of CFLAGS.
> >
> >That should not be the case at all. 9562639 fixed this and stores
> >the flags collected by configure in OVS_CFLAGS while the user can
> >specify his own CFLAGS.
> >
> >If there is a bug, let's fix the bug.
> 
> Hi Thomas,
> 
> I have little experience of automake, so apologies for any shortcomings in my understanding in this response.
> 
> I've done quite a bit of testing on this, and have observed that
> whenever CFLAGS are passed to 'make' on the command line (building
> against DPDK), the performance degrades by ~3x; this leads me to
> believe that the existing value of CFLAGS (namely -O2 -g) has been
> overwritten by its command line counterpart.

Yes, if you supply your own CFLAGS then you have to supply -O2 -g, if
you want them.  You can leave them out, if you do not want them.  Those
are the only CFLAGS that are ever supplied automatically.

> With respect to 9562639, I don't see where OVS_CFLAGS obtains its
> initial value (i.e. existing CFLAGS). I've made a slight modification,
> and found that it resolves the issue - maybe you could comment as to
> the validity of the changes?

OVS_CFLAGS is used in addition to CFLAGS, not as a substitute for it, so
it should not include $CFLAGS.

All of this is the standard way to use Autoconf and Automake.  I might
do things differently, if I were to invent my own way of doing things,
since these conventions are somewhat weird in my opinion, but as long as
we continue to use them I think it is best to honor their conventions.



More information about the dev mailing list