Re: [lfs-dev] CFLAGS in fixing up for gcc-10.
On Thu, May 14, 2020 at 09:21:00AM +0200, Pierre Labastie via lfs-dev wrote:
> On Thu, 2020-05-14 at 05:33 +0100, 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 ?
>
> Sorry about that Ken. As you noted in another post, cmake semantics is
> not always easy to understand. I thought that doing like that was
> preserving user's CFLAGS... And for some reason I thought CFLAGS where
> not passed when doing the above (CFLAGS in the environment).
>
> Will fix the book, and add "$CFLAGS" before -fcommon at other places I
> have put them.
>
> Pierre
>
Thanks!
I hope to get started on exploring your cross-chap5 soon.
ĸen
--
See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] CFLAGS in fixing up for gcc-10.
On Thu, May 14, 2020 at 08:53:18AM -0500, Douglas R. Reno via lfs-dev wrote: > > On 5/14/20 1:33 AM, 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. > > > > > > > > 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. > > > No problem with prioritising getting the packages to build, but one or two (a couple of the video drivers) already pick up the CFLAGS before adding -fcommon. > > > 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... > > Agreed here, I don't like it either. Most of these would be very simple > fixes and may even be accomodated via sed instead of patch. > > That's OK though, I'll go with what everyone else is doing for now... > I've seen a comment from a fedora developer that he had to spend a lot of time getting everything to build with gcc-10. I'm sure some of what they build is development versions, and they ignore some other things we build, but fedora might be a place worth looking. ĸen -- See You Later, Holy Poppadom! -- Red Dwarf, The Promised Land -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] CFLAGS in fixing up for gcc-10.
On 5/14/20 1:33 AM, 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...
Agreed here, I don't like it either. Most of these would be very simple
fixes and may even be accomodated via sed instead of patch.
That's OK though, I'll go with what everyone else is doing for now...
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] CFLAGS in fixing up for gcc-10.
On Thu, 2020-05-14 at 10:57 +0300, Firas Khalil Khana via lfs-dev wrote: > > 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`. Hmm, answered here because the thread was here. Should have been on blfs-dev mailing list. There are many more packages affected by this in blfs... The lfs book is already fixed in trunk. We have used patches or sed everywhere, except in systemd, where upstream has not published enough patches yet. Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] CFLAGS in fixing up for gcc-10.
On Thu, May 14, 2020 at 10:39 AM Pierre Labastie via lfs-dev
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
Re: [lfs-dev] CFLAGS in fixing up for gcc-10.
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
Re: [lfs-dev] CFLAGS in fixing up for gcc-10.
On Thu, 2020-05-14 at 05:33 +0100, 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 ?
Sorry about that Ken. As you noted in another post, cmake semantics is
not always easy to understand. I thought that doing like that was
preserving user's CFLAGS... And for some reason I thought CFLAGS where
not passed when doing the above (CFLAGS in the environment).
Will fix the book, and add "$CFLAGS" before -fcommon at other places I
have put them.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] CFLAGS in fixing up for gcc-10.
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...
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] CFLAGS in fixing up for gcc-10.
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.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
[lfs-dev] CFLAGS in fixing up for gcc-10.
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 ?
ĸen
--
See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
