qt4 rebuild

[Richard Shaw]

I'm troubleshooting why apiextractor tests segfault during package
building. I have not been able to attribute it to any change in build flags
so I started looking at qt4 which appears to still be FTBFS for F30 rebuild.

There's a check in the spec file which fails:

+ grep '^#define QT_BUILD_KEY ' src/corelib/global/qconfig.h
#define QT_BUILD_KEY "x86_64 linux g++-9 full-config"
BUILDSTDERR: ++ grep '^#define QT_BUILD_KEY ' src/corelib/global/qconfig.h
BUILDSTDERR: ++ cut '-d ' -f5
QT_BUILD_KEY_COMPILER failure
+ QT_BUILD_KEY_COMPILER=g++-9
+ '[' g++-9 '!=' g++-4 ']'
+ echo 'QT_BUILD_KEY_COMPILER failure'
+ exit 1

It looks like after configuration that the "KEY" changed from g++4 to g++9.

Is this check appropriate?

Thanks,
Richard

[Rex Dieter]

Richard Shaw wrote:

>  I'm troubleshooting why apiextractor tests segfault during
> package
>  building. I have not been able to attribute it to any change in build
>  flags so I started looking at qt4 which appears to still be FTBFS for F30
>  rebuild.
>  
>  There's a check in the spec file which fails:
>  
>  + grep '^#define QT_BUILD_KEY ' src/corelib/global/qconfig.h
>  #define QT_BUILD_KEY "x86_64 linux g++-9 full-config"
>  BUILDSTDERR: ++ grep '^#define QT_BUILD_KEY ' src/corelib/global/qconfig.h
>  BUILDSTDERR: ++ cut '-d ' -f5
>  QT_BUILD_KEY_COMPILER failure
>  + QT_BUILD_KEY_COMPILER=g++-9
>  + '[' g++-9 '!=' g++-4 ']'
>  + echo 'QT_BUILD_KEY_COMPILER failure'
>  + exit 1
>  
>  It looks like after configuration that the "KEY" changed from g++4 to
>  g++9.
>  
>  Is this check appropriate? 
The check is legit'ish.  In particular, afaik, the key should not have 
changed, so that should be fixed in qt4

-- Rex

[Richard Shaw]

On Tue, Feb 26, 2019 at 10:27 AM Rex Dieter <rdieter(a)gmail.com&gt; wrote:

>  Richard Shaw wrote:
>
>  > I'm troubleshooting why apiextractor tests segfault during package
>  > building. I have not been able to attribute it to any change in build
>  > flags so I started looking at qt4 which appears to still be FTBFS for F30
>  > rebuild.
>  >
>  > There's a check in the spec file which fails:
>  >
>  > + grep '^#define QT_BUILD_KEY ' src/corelib/global/qconfig.h
>  > #define QT_BUILD_KEY "x86_64 linux g++-9 full-config"
>  > BUILDSTDERR: ++ grep '^#define QT_BUILD_KEY '
>  src/corelib/global/qconfig.h
>  > BUILDSTDERR: ++ cut '-d ' -f5
>  > QT_BUILD_KEY_COMPILER failure
>  > + QT_BUILD_KEY_COMPILER=g++-9
>  > + '[' g++-9 '!=' g++-4 ']'
>  > + echo 'QT_BUILD_KEY_COMPILER failure'
>  > + exit 1
>  >
>  > It looks like after configuration that the "KEY" changed from g++4 to
>  > g++9.
>  >
>  > Is this check appropriate?
>
>  The check is legit'ish.  In particular, afaik, the key should not have
>  changed, so that should be fixed in qt4
>  
Found it... configure has been heavily patched to deal with newer gcc
versions but has not been updated to deal with gcc 9...


#-------------------------------------------------------------------------------
# generate QT_BUILD_KEY
#-------------------------------------------------------------------------------

# some compilers generate binary incompatible code between different
versions,
# so we need to generate a build key that is different between these
compilers
COMPAT_COMPILER=
case "$COMPILER" in
g++*)
    # GNU C++
    COMPILER_VERSION=`${QMAKE_CONF_COMPILER} -dumpversion 2>/dev/null`

    case "$COMPILER_VERSION" in
    *.*.*)
        QT_GCC_MAJOR_VERSION=`echo $COMPILER_VERSION | sed
's,^\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*,\1,'`
        QT_GCC_MINOR_VERSION=`echo $COMPILER_VERSION | sed
's,^\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*,\2,'`
        QT_GCC_PATCH_VERSION=`echo $COMPILER_VERSION | sed
's,^\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*,\3,'`
        ;;
    *.*)
        QT_GCC_MAJOR_VERSION=`echo $COMPILER_VERSION | sed
's,^\([0-9]*\)\.\([0-9]*\).*,\1,'`
        QT_GCC_MINOR_VERSION=`echo $COMPILER_VERSION | sed
's,^\([0-9]*\)\.\([0-9]*\).*,\2,'`
        QT_GCC_PATCH_VERSION=0
        ;;
    *)
        QT_GCC_MAJOR_VERSION=$COMPILER_VERSION
        QT_GCC_MINOR_VERSION=0
        QT_GCC_PATCH_VERSION=0
        ;;
    esac

    case "$COMPILER_VERSION" in
    2.95.*)
        COMPILER_VERSION="2.95.*"
        ;;
    3.*)
        COMPILER_VERSION="3.*"
        ;;
    5*|4.*) <<<--- HERE ---|||
        COMPILER_VERSION="4"
        ;;
    *)
        ;;
    esac
    [ '!' -z "$COMPILER_VERSION" ] &&
COMPILER="g++-${COMPILER_VERSION}"
    ;;
icc*)

I just updated the patch and performing a local mock build to see if that
was the only issue.

Thanks,
Richard

[Richard Shaw]

Ok, I updated the patch the COMPILER_VERSION issue (committed) and have a
local patch for the Q_FOREACH problem based on a qt 5 commit:

https://github.com/qt/qtbase/commit/c35a3f519007af44c3b364b9af86f6a336f6411b

With both of those problems fixed the build still fails probably due to gcc
9 being more pedantic than previous versions.

With my scratch build[1] I'm getting this strange error that I don't get on
a local mock build:

collect2: fatal error: cannot find 'ld'

So I'm pretty much out of my league at this point. I can commit the
Q_FOREACH patch if needed.

Thanks,
Richard

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=33069763

>

[Rob Crittenden]

Richard Shaw wrote:
>  Ok, I updated the patch the COMPILER_VERSION issue (committed) and
> have
>  a local patch for the Q_FOREACH problem based on a qt 5 commit:
>  
>  https://github.com/qt/qtbase/commit/c35a3f519007af44c3b364b9af86f6a336f6411b
>  
>  With both of those problems fixed the build still fails probably due to
>  gcc 9 being more pedantic than previous versions.
>  
>  With my scratch build[1] I'm getting this strange error that I don't get
>  on a local mock build:
>  
>  collect2: fatal error: cannot find 'ld'
>  
>  So I'm pretty much out of my league at this point. I can commit the
>  Q_FOREACH patch if needed.
>  
>  Thanks,
>  Richard
>  
>  [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=33069763 
See https://bugzilla.redhat.com/show_bug.cgi?id=1683408

rob

[Rex Dieter]

Richard Shaw wrote:

>  So I'm pretty much out of my league at this point. I can commit
> the
>  Q_FOREACH patch if needed. 
please do commit (or at least submit pull request).

-- Rex

[Richard Shaw]

On Wed, Feb 27, 2019 at 10:18 AM Rex Dieter <rdieter(a)gmail.com&gt; wrote:

>  Richard Shaw wrote:
>
>  > So I'm pretty much out of my league at this point. I can commit the
>  > Q_FOREACH patch if needed.
>
>  please do commit (or at least submit pull request).
>  
Pull request submitted, but it looks like pagure is having issues:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable
to complete your request.

Please contact the server administrator at webmaster(a)fedoraproject.org to
inform them of the time this error occurred, and the actions you performed
just before this error.

More information about this error may be available in the server error log.

Thanks,
Richard

[Stephen John Smoogen]

On Wed, 27 Feb 2019 at 16:27, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>  On Wed, Feb 27, 2019 at 10:18 AM Rex Dieter <rdieter(a)gmail.com&gt; wrote:
> >
> > Richard Shaw wrote:
> >
> > > So I'm pretty much out of my league at this point. I can commit the
> > > Q_FOREACH patch if needed.
> >
> > please do commit (or at least submit pull request).
>
>
>  Pull request submitted, but it looks like pagure is having issues:
>
>  Internal Server Error
>  The server encountered an internal error or misconfiguration and was unable to complete
> your request.
>
>  Please contact the server administrator at webmaster(a)fedoraproject.org to inform them of
> the time this error occurred, and the actions you performed just before this error.
>
>  More information about this error may be available in the server error log.
>  
I think you did this during a planned outage in Fedora Infrastructure.
Sorry for the inconvenience and please try again.


>  Thanks,
>  Richard
>  _______________________________________________
>  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/[e-mail] 


-- 
Stephen J Smoogen.