On Wed, Jan 29, 2020 at 10:57:48AM -0600, Eric Sandeen wrote: > On 1/29/20 10:01 AM, Darrick J. Wong wrote: > > On Wed, Jan 29, 2020 at 09:16:58AM -0600, Eric Sandeen wrote: > >> In each of these cases, db, logprint, and mdrestore are redeclaring > >> as a global variable something which was already provided by a > >> library they link with. > >> > >> gcc now defaults to -fno-common and trips over these global variables > >> which are declared in utilities as well as in libxfs and libxlog, and > >> it causes the build to fail. > >> > >> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> > >> --- > > ... > > >> + print_exit = 1; /* -e is now default. specify -c to override */ > > > > With the trailing whitespace after the comment fixed, > > oh burn. ;) > > > Reviewed-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > > > Though given your earlier comment on IRC, maybe we should investigate > > why -fno-common would be useful (since Fedora turned it on??) or if it > > should be in the regular build to catch multiply defined global vars? > > That's a good idea. FWIW my understanding is that it's a new default in > gcc10. > > Docs say w.r.t. -fcommon: "This behavior is inconsistent with C++, and on many targets implies a speed and code size penalty on global variable references. It is mainly useful to enable legacy code to link without errors." > > Want me to send a V3 w/ -fno-common explicitly set? Yes, that sounds like a better place to start a conversation about ... whatever that option is. :) --D > -Eric