On Thu, 2020-05-14 at 14:33 +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-05-13 23:46 -0500, Bruce Dubbs via lfs-dev wrote:
> > On 5/13/20 11:33 PM, Ken Moffat via lfs-dev wrote:
> > > I notice that in some places people have overridden any existing
> > > CFLAGS when adding -fcommon. In most places, for those of us who
> > > care the fix is obvious (CFLAGS="$CFLAGS -fcommon"). One or two
> > > packages will turn out to be more painful.
> > >
> > > The first I've found is freeglut, where the book uses
> > > -DCMAKE_C_FLAGS=-fcommon
> > >
> > > For people without any existing CFLAGS, that does the right thing
> > > and respects the -O3 etc from specifying a Release build (seen by
> > > using 'make VERBOSE=1') but for people who have extra flags such
> > > as
> > > "-march=native -D_FORTIFY_SOURCE=2" those just get thrown away.
> > >
> > > I'd assumed I could add
> > > -DCMAKE_CFLAGS="$CFLAGS -fcommon"
> > >
> > > but if I do that, cmake tells me that CFLAGS was not referenced.
> > >
> > > In this case, I am getting the right results (testing on a gcc-9
> > > system) with:
> > >
> > > CFLAGS="${CFLAGS} -fcommon" \
> > > cmake -DCMAKE_INSTALL_PREFIX=/usr \
> > > -DCMAKE_BUILD_TYPE=Release \
> > > -DFREEGLUT_BUILD_DEMOS=OFF \
> > > -DFREEGLUT_BUILD_STATIC_LIBS=OFF \
> > > -Wno-dev ..
> > >
> > > Can I ask people to at least *consider* not trashing a user's
> > > specified CFLAGS ?
> >
> > Yes, we can do that, but right now we are trying to just get
> > everything
> > to build with gcc10. When that is done, we can probably review and
> > do
> > 'grep -r CFLAGS; in the book's xml top and do the right thing where
> > we
> > have had to make changes.
> >
> > Also as new package releases address gcc10, we can probably remove
> > a lot
> > of the CFLAGS entries that we've been making.
>
> I don't like -fcommon. It's actually changing C semantics. The
> correct thing
> to do is to fix the code (like what we do for gdbm in LFS).
>
> Though we can simply add this workaround for now...
Bruce: rather "grep -- -fcommon ..."
Xi Ruoyao: you are right that C semantics is to have "extern" in header
files, which may be included in several .c files, and that variables
should be defined once and only once in some .c file. But...
-fcommon was the default until gcc 9 included. So the packages which do
not compile with -fno-common have been tested against -fcommon
(silently, with former versions of gcc), while the patches have been
less tested.
Furthermore, adding patches for all the packages which fail to compile
is much more work than just a CFLAGS addition. Since this work will be
obsoleted as soon as next release or so, it is tempting not to spend
too much time on it...
I agree, I'm lazy!
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
