DevHeads.net

Can we use SCLs for building for EPEL 6?

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 <a href="https://koji.fedoraproject.org/koji/taginfo?tagID=259" title="https://koji.fedoraproject.org/koji/taginfo?tagID=259">https://koji.fedoraproject.org/koji/taginfo?tagID=259</a>),
but not for EPEL 6 (see
<a href="https://koji.fedoraproject.org/koji/taginfo?tagID=140" title="https://koji.fedoraproject.org/koji/taginfo?tagID=140">https://koji.fedoraproject.org/koji/taginfo?tagID=140</a>).

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

Comments

Re: Can we use SCLs for building for EPEL 6?

By Nico Kadel-Garcia at 04/14/2019 - 19:11

On Sat, Apr 13, 2019 at 4:04 PM Jonathan Dieter < ... at gmail dot com> wrote:
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.

Re: Can we use SCLs for building for EPEL 6?

By Kevin Fenzi at 04/15/2019 - 13:10

On 4/14/19 4:11 PM, Nico Kadel-Garcia wrote:
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

Re: Can we use SCLs for building for EPEL 6?

By John Reiser at 04/13/2019 - 16:11

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.

Re: Can we use SCLs for building for EPEL 6?

By Jonathan Dieter at 04/13/2019 - 16:36

On Sat, 2019-04-13 at 13:11 -0700, John Reiser wrote:
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@sha/comp_zstd_zstd.c.o'.
FAILED: src/lib/zck@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@sha/comp_zstd_zstd.c.o' -MF 'src/lib/zck@sha/comp_zstd_zstd.c.o.d' -o 'src/lib/zck@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:
<a href="https://github.com/zchunk/zchunk/blob/master/include/zck.h.in" title="https://github.com/zchunk/zchunk/blob/master/include/zck.h.in">https://github.com/zchunk/zchunk/blob/master/include/zck.h.in</a>

and zck_private.h at:
<a href="https://github.com/zchunk/zchunk/blob/master/src/lib/zck_private.h" title="https://github.com/zchunk/zchunk/blob/master/src/lib/zck_private.h">https://github.com/zchunk/zchunk/blob/master/src/lib/zck_private.h</a>

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

Re: Can we use SCLs for building for EPEL 6?

By Kevin Kofler at 04/14/2019 - 18:48

Jonathan Dieter wrote:
IMHO, zck_private.h should #include "zck.h" and only define itself whatever
is not defined in the public header.

Kevin Kofler

Re: Can we use SCLs for building for EPEL 6?

By King InuYasha at 04/13/2019 - 17:47

On Sat, Apr 13, 2019 at 4:37 PM Jonathan Dieter < ... at gmail dot com> wrote:
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

Re: Can we use SCLs for building for EPEL 6?

By Todd Zullinger at 04/13/2019 - 21:04

Neal Gompa wrote:
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.

Re: Can we use SCLs for building for EPEL 6?

By Jonathan Dieter at 04/15/2019 - 08:30

On Sun, 2019-04-14 at 16:01 -0400, Stephen John Smoogen wrote:
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

Re: Can we use SCLs for building for EPEL 6?

By Dmitry Butskoy at 04/14/2019 - 20:08

Stephen John Smoogen wrote:
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
<a href="https://fedoraproject.org/wiki/User:Buc" title="https://fedoraproject.org/wiki/User:Buc">https://fedoraproject.org/wiki/User:Buc</a>

Re: Can we use SCLs for building for EPEL 6?

By John Reiser at 04/13/2019 - 17:06

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.