On Thu, May 14, 2020 at 10:39 AM Pierre Labastie via lfs-dev <[email protected]> wrote: > > 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
It's true that starting from GCC 10, it now defaults to `-fno-common`: https://gcc.gnu.org/gcc-10/porting_to.html That being said, and based on my testings, I believe `gdbm` is the only package that won't build with that flag and needs `-fcommon` explicitly specified in CFLAGS. A couple of packages that might not work with the default `-fno-common` include `pkg-config`, `coreutils`, `man-db` and `zlib`. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
