3:03 p.m.
So, the background is that I'd like to build zchunk for EPEL 6 (it's
already built for EPEL 7). Unfortunately, the gcc in EL6 is too old to
build zchunk, so I'd prefer to use a newer version from an SCL, rather
than rewrite zchunk to be compatible with an ancient version of gcc.
I noticed that SCLs are available for EPEL 7 (note the final repository
in the list at https://koji.fedoraproject.org/koji/taginfo?tagID=259),
but not for EPEL 6 (see
https://koji.fedoraproject.org/koji/taginfo?tagID=140).
So, is there any way we can use SCLs for building on EPEL 6, or should
I stop tilting at windmills and just say EL6 is too old for zchunk?
Jonathan
3:36 p.m.
On Sat, 2019-04-13 at 13:11 -0700, John Reiser wrote:
> Unfortunately, the gcc in EL6 is too old to build zchunk
In what specific way(s)? Can the complaints from gcc [which version?],
or other tools in the toolchain, be listed here?
Other developers may have faced the same or similar problems,
and may have tools to help.
Sorry, I should have shared that the first time around.
The version of gcc that comes with EL6 is 4.4.7.
When building zchunk, I get a number of messages that look like:
$ ninja-build
[1/178] Compiling C object 'src/lib/zck(a)sha/comp_zstd_zstd.c.o'.
FAILED: src/lib/zck(a)sha/comp_zstd_zstd.c.o
cc -Isrc/lib/zck@sha -Isrc/lib -I../src/lib -Iinclude -I../include -pipe
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu99 -O0 -g -DZCHUNK_ZSTD
-DZCHUNK_OPENSSL -fvisibility=hidden -fPIC -MMD -MQ
'src/lib/zck(a)sha/comp_zstd_zstd.c.o' -MF
'src/lib/zck(a)sha/comp_zstd_zstd.c.o.d' -o
'src/lib/zck(a)sha/comp_zstd_zstd.c.o' -c ../src/lib/comp/zstd/zstd.c
In file included from ../src/lib/comp/zstd/zstd.c:34:
../src/lib/zck_private.h:92: error: redefinition of typedef 'zckCtx'
include/zck.h:49: note: previous declaration of 'zckCtx' was here
../src/lib/zck_private.h:106: error: redefinition of typedef 'zck_log_type'
include/zck.h:47: note: previous declaration of 'zck_log_type' was here
../src/lib/zck_private.h:117: error: redefinition of typedef 'zckHash'
include/zck.h:50: note: previous declaration of 'zckHash' was here
../src/lib/zck_private.h:150: error: redefinition of typedef 'zckDL'
include/zck.h:54: note: previous declaration of 'zckDL' was here
../src/lib/zck_private.h:165: error: redefinition of typedef 'zckChunk'
include/zck.h:51: note: previous declaration of 'zckChunk' was here
../src/lib/zck_private.h:177: error: redefinition of typedef 'zckIndex'
include/zck.h:52: note: previous declaration of 'zckIndex' was here
../src/lib/zck_private.h:193: error: redefinition of typedef 'zckRange'
include/zck.h:53: note: previous declaration of 'zckRange' was here
../src/lib/zck_private.h:224: error: redefinition of typedef 'zckComp'
../src/lib/zck_private.h:91: note: previous declaration of 'zckComp' was here
../src/lib/zck_private.h:298: error: redefinition of typedef 'zckCtx'
../src/lib/zck_private.h:92: note: previous declaration of 'zckCtx' was here
For reference, you can find zck.h.in (which gets processed into zck.h
with the version added) at:
https://github.com/zchunk/zchunk/blob/master/include/zck.h.in
and zck_private.h at:
https://github.com/zchunk/zchunk/blob/master/src/lib/zck_private.h
As far as I can see, gcc-4.7 doesn't like that I'm typedefing the same
struct to the same type twice. Later versions don't see it as a
problem at all.
(Just to be clear, this still happens if I change zck_private.h to say:
typedef struct zckCtx zckCtx;)
Jonathan
4:06 p.m.
In file included from ../src/lib/comp/zstd/zstd.c:34:
../src/lib/zck_private.h:92: error: redefinition of typedef 'zckCtx'
include/zck.h:49: note: previous declaration of 'zckCtx' was here
As far as I can see, gcc-4.7 doesn't like that I'm typedefing
the same
struct to the same type twice. Later versions don't see it as a
problem at all.
How about this:
#ifndef zckCtx_DEFINED /*{ workaround for gcc-4.4.7 */
#define zckCtx_DEFINED 1 /* gcc-4.4.7 demands only one declaration of a typedef */
typedef struct zckCtx zckCtx;
#endif /*}*/
and similarly for the other 8 "multiply-defined" typedefs? After
pre-processing,
then the compiler will see exactly one definition of the typedef.
4:47 p.m.
On Sat, Apr 13, 2019 at 4:37 PM Jonathan Dieter <jdieter(a)gmail.com> wrote:
On Sat, 2019-04-13 at 13:11 -0700, John Reiser wrote:
> > Unfortunately, the gcc in EL6 is too old to build zchunk
>
> In what specific way(s)? Can the complaints from gcc [which version?],
> or other tools in the toolchain, be listed here?
> Other developers may have faced the same or similar problems,
> and may have tools to help.
Sorry, I should have shared that the first time around.
The version of gcc that comes with EL6 is 4.4.7.
When building zchunk, I get a number of messages that look like:
$ ninja-build
[1/178] Compiling C object 'src/lib/zck(a)sha/comp_zstd_zstd.c.o'.
FAILED: src/lib/zck(a)sha/comp_zstd_zstd.c.o
cc -Isrc/lib/zck@sha -Isrc/lib -I../src/lib -Iinclude -I../include -pipe
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu99 -O0 -g -DZCHUNK_ZSTD
-DZCHUNK_OPENSSL -fvisibility=hidden -fPIC -MMD -MQ
'src/lib/zck(a)sha/comp_zstd_zstd.c.o' -MF
'src/lib/zck(a)sha/comp_zstd_zstd.c.o.d' -o
'src/lib/zck(a)sha/comp_zstd_zstd.c.o' -c ../src/lib/comp/zstd/zstd.c
In file included from ../src/lib/comp/zstd/zstd.c:34:
../src/lib/zck_private.h:92: error: redefinition of typedef 'zckCtx'
include/zck.h:49: note: previous declaration of 'zckCtx' was here
../src/lib/zck_private.h:106: error: redefinition of typedef 'zck_log_type'
include/zck.h:47: note: previous declaration of 'zck_log_type' was here
../src/lib/zck_private.h:117: error: redefinition of typedef 'zckHash'
include/zck.h:50: note: previous declaration of 'zckHash' was here
../src/lib/zck_private.h:150: error: redefinition of typedef 'zckDL'
include/zck.h:54: note: previous declaration of 'zckDL' was here
../src/lib/zck_private.h:165: error: redefinition of typedef 'zckChunk'
include/zck.h:51: note: previous declaration of 'zckChunk' was here
../src/lib/zck_private.h:177: error: redefinition of typedef 'zckIndex'
include/zck.h:52: note: previous declaration of 'zckIndex' was here
../src/lib/zck_private.h:193: error: redefinition of typedef 'zckRange'
include/zck.h:53: note: previous declaration of 'zckRange' was here
../src/lib/zck_private.h:224: error: redefinition of typedef 'zckComp'
../src/lib/zck_private.h:91: note: previous declaration of 'zckComp' was here
../src/lib/zck_private.h:298: error: redefinition of typedef 'zckCtx'
../src/lib/zck_private.h:92: note: previous declaration of 'zckCtx' was here
For reference, you can find zck.h.in (which gets processed into zck.h
with the version added) at:
https://github.com/zchunk/zchunk/blob/master/include/zck.h.in
and zck_private.h at:
https://github.com/zchunk/zchunk/blob/master/src/lib/zck_private.h
As far as I can see, gcc-4.7 doesn't like that I'm typedefing the same
struct to the same type twice. Later versions don't see it as a
problem at all.
(Just to be clear, this still happens if I change zck_private.h to say:
typedef struct zckCtx zckCtx;)
If devtoolset is available for EPEL6 (which I think it is?), you can
simply use it by doing the following:
Insert into BRs:
BuildRequires: devtoolset-7-toolchain
Then add to top of %build:
source /opt/rh/devtoolset-7/enable
--
真実はいつも一つ！/ Always, there's only one truth!
8:04 p.m.
Neal Gompa wrote:
If devtoolset is available for EPEL6 (which I think it is?)
I don't believe devtoolset was enabled for el6 in koji.
When it was added to the mock configs for el6/el7, the
consensus on the epel list was that it would be added to el6
if there was sufficient demand. I've only seen it come up
once (or maybe twice) since then on the epel list.
I'm not familiar enough with the koji commands to confirm
it. I can see that rhel7-server-rhscl-7 is listed in the
external repos, but I don't see a similar rhel6 SCL.
Apologies if I simply missed an announcement on the epel
lists and am passing on outdated data.
--
Todd
3:01 p.m.
On Sat, 13 Apr 2019 at 21:06, Todd Zullinger <tmz(a)pobox.com> wrote:
Neal Gompa wrote:
> If devtoolset is available for EPEL6 (which I think it is?)
I don't believe devtoolset was enabled for el6 in koji.
When it was added to the mock configs for el6/el7, the
consensus on the epel list was that it would be added to el6
if there was sufficient demand. I've only seen it come up
once (or maybe twice) since then on the epel list.
I'm not familiar enough with the koji commands to confirm
it. I can see that rhel7-server-rhscl-7 is listed in the
external repos, but I don't see a similar rhel6 SCL.
Apologies if I simply missed an announcement on the epel
lists and am passing on outdated data.
I believe Todd is correct. At the time there was the package needing SCL's
was chromium and the owner had no interest for making the package in EL6.
If zchunk needs it, we can put it in.
--
Todd
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Stephen J Smoogen.
7:08 p.m.
Stephen John Smoogen wrote:
On Sat, 13 Apr 2019 at 21:06, Todd Zullinger <tmz(a)pobox.com
<mailto:tmz@pobox.com>> wrote:
Neal Gompa wrote:
> If devtoolset is available for EPEL6 (which I think it is?)
I don't believe devtoolset was enabled for el6 in koji.
When it was added to the mock configs for el6/el7, the
consensus on the epel list was that it would be added to el6
if there was sufficient demand. I've only seen it come up
once (or maybe twice) since then on the epel list.
I'm not familiar enough with the koji commands to confirm
it. I can see that rhel7-server-rhscl-7 is listed in the
external repos, but I don't see a similar rhel6 SCL.
Apologies if I simply missed an announcement on the epel
lists and am passing on outdated data.
I believe Todd is correct. At the time there was the package needing
SCL's was chromium and the owner had no interest for making the
package in EL6. If zchunk needs it, we can put it in.
SeaMonkey as well. +1
Many years Firefox and Seamonkey are compelled to do extra builds of
gcc-4.8 and python-2.7 at the beginning of the package compiling. And to
provide an extra sources (gcc and pythin tarballs) in the srpms for this.
It seems that Firefox (part of RHEL packages set) uses SCL now, but
Seamonkey (former Mozilla/Netscape) still cannot use it.
Dmitry Butskoy
https://fedoraproject.org/wiki/User:Buc
7:30 a.m.
On Sun, 2019-04-14 at 16:01 -0400, Stephen John Smoogen wrote:
On Sat, 13 Apr 2019 at 21:06, Todd Zullinger <tmz(a)pobox.com>
wrote:
> Neal Gompa wrote:
> > If devtoolset is available for EPEL6 (which I think it is?)
>
> I don't believe devtoolset was enabled for el6 in koji.
> When it was added to the mock configs for el6/el7, the
> consensus on the epel list was that it would be added to el6
> if there was sufficient demand. I've only seen it come up
> once (or maybe twice) since then on the epel list.
>
> I'm not familiar enough with the koji commands to confirm
> it. I can see that rhel7-server-rhscl-7 is listed in the
> external repos, but I don't see a similar rhel6 SCL.
>
> Apologies if I simply missed an announcement on the epel
> lists and am passing on outdated data.
>
I believe Todd is correct. At the time there was the package needing
SCL's was chromium and the owner had no interest for making the
package in EL6. If zchunk needs it, we can put it in.
That's ok. I've gone with Kevin Kofler's suggestion and just fixed the
build to work with the old version of GCC.
Thanks, all, for the help!
Jonathan
5:48 p.m.
Jonathan Dieter wrote:
For reference, you can find zck.h.in (which gets processed into
zck.h
with the version added) at:
https://github.com/zchunk/zchunk/blob/master/include/zck.h.in
and zck_private.h at:
https://github.com/zchunk/zchunk/blob/master/src/lib/zck_private.h
As far as I can see, gcc-4.7 doesn't like that I'm typedefing the same
struct to the same type twice. Later versions don't see it as a
problem at all.
(Just to be clear, this still happens if I change zck_private.h to say:
typedef struct zckCtx zckCtx;)
IMHO, zck_private.h should #include "zck.h" and only define itself whatever
is not defined in the public header.
Kevin Kofler
6:11 p.m.
On Sat, Apr 13, 2019 at 4:04 PM Jonathan Dieter <jdieter(a)gmail.com> wrote:
So, the background is that I'd like to build zchunk for EPEL 6 (it's
already built for EPEL 7). Unfortunately, the gcc in EL6 is too old to
build zchunk, so I'd prefer to use a newer version from an SCL, rather
than rewrite zchunk to be compatible with an ancient version of gcc.
I noticed that SCLs are available for EPEL 7 (note the final repository
in the list at https://koji.fedoraproject.org/koji/taginfo?tagID=259),
but not for EPEL 6 (see
https://koji.fedoraproject.org/koji/taginfo?tagID=140).
The SCL's have their uses, but for EPEL? I think they'd add
unnecessary complexity on an an unreliable developer codebase and be a
really bad idea to rely on for EPEL componenents. RHEL 6 is at release
6.10, and should be treated as end-of-life. If the component were
being embedded into the SCL, then it might make some sense to support.
But as best I can tell zchunk has nothing to do with the SCL except
for the gcc requirement.
12:10 p.m.
On 4/14/19 4:11 PM, Nico Kadel-Garcia wrote:
On Sat, Apr 13, 2019 at 4:04 PM Jonathan Dieter
<jdieter(a)gmail.com> wrote:
>
> So, the background is that I'd like to build zchunk for EPEL 6 (it's
> already built for EPEL 7). Unfortunately, the gcc in EL6 is too old to
> build zchunk, so I'd prefer to use a newer version from an SCL, rather
> than rewrite zchunk to be compatible with an ancient version of gcc.
>
> I noticed that SCLs are available for EPEL 7 (note the final repository
> in the list at https://koji.fedoraproject.org/koji/taginfo?tagID=259),
> but not for EPEL 6 (see
> https://koji.fedoraproject.org/koji/taginfo?tagID=140).
The SCL's have their uses, but for EPEL? I think they'd add
unnecessary complexity on an an unreliable developer codebase and be a
really bad idea to rely on for EPEL componenents. RHEL 6 is at release
6.10, and should be treated as end-of-life. If the component were
being embedded into the SCL, then it might make some sense to support.
But as best I can tell zchunk has nothing to do with the SCL except
for the gcc requirement.
Just to clarify: When we added devtoolset scl to epel7, the rule was
that it was only to be used for build time, never runtime.
I don't see a big problem doing the same for rhel6, but there hasn't
been any demand for it yet.
If it's strictly build time, I don't see that users would see any
complications from it.
kevin
1831
days inactive
1833
days old
11 comments
9 participants
participants (9)
-
Dmitry Butskoy -
John Reiser -
Jonathan Dieter -
Kevin Fenzi -
Kevin Kofler -
Neal Gompa -
Nico Kadel-Garcia -
Stephen John Smoogen -
Todd Zullinger