Created attachment 1565073 [details]
reproducer

I gave this a try this weekend but stopped before submitting updates. Unfortunately even such a small patch changes symbol mangling and as a result breaks the ABI for the shared library.

I'm not sure how to best handle this case, I think that nobody uses the shared library and everyone will piggyback on the CLI, but the moment I push a breaking update someone will prove me wrong.

See here, it looks like all the removed symbols are still present in the new build, buf off by one:

https://taskotron.fedoraproject.org/artifacts/all/4715634e-7965-11e9-9632-52540077ca13/tests.yml/ShellCheck-0.6.0-4.fc30.log

-ShellCheckzm0zi6zi0zm3DaLvr1aI0a5T8ePxnZZXaX_ShellCheckziChecker_runTests101_info, aliases ShellCheckzm0zi6zi0zm3DaLvr1aI0a5T8ePxnZZXaX_ShellCheckziChecker_runTests101_info$def
+ShellCheckzm0zi6zi0zm3DaLvr1aI0a5T8ePxnZZXaX_ShellCheckziChecker_runTests100_info, aliases ShellCheckzm0zi6zi0zm3DaLvr1aI0a5T8ePxnZZXaX_ShellCheckziChecker_runTests100_info$def

And a few more symbols landed as a result of this patch.

Those are variables, and no function symbol appears to be broken. I would assume this is fine, but I'm not familiar with ABI intricacies of the Haskell/GHC ecosystem.

And as far as RPM tooling is concerned, there doesn't seem to be any ABI information captured at build time:

    $ rpm -qP ghc-ShellCheck
    ghc-ShellCheck = 0.6.0-3.fc30
    ghc-ShellCheck(x86-64) = 0.6.0-3.fc30
    libHSShellCheck-0.6.0-3DaLvr1aI0a5T8ePxnZXaX-ghc8.4.4.so()(64bit)

And that last mangled library soname is still stable after applying the patch.

Is it really caused by the mentioned patch?

If yes, you can try to exclude the self-test from the upstream patch.

Good point, it could have been introduced by a change in the toolchain, although I find it unlikely that the same ABI changes happened on both f28, f29 and f30.

I didn't find the signing key for f31 and didn't try it but `dnf upgrade ShellCheck --releasever 31` could do the trick as a workaround now that the ShellCheck program is statically linked.

The change log now seems to be out of sync in all the latest builds for f28, f29, f30, and f31.  It does not contain any change log entry for the actual NVR (Name-Version-Release) and it does contain any reference to this bug.

(In reply to Dridi Boukelmoune from comment #7)
> I didn't find the signing key for f31 and didn't try it but `dnf upgrade
> ShellCheck --releasever 31` could do the trick as a workaround now that the
> ShellCheck program is statically linked.

I must be missing some context -- workaround for what?

(In reply to Kamil Dudka from comment #8)
> The change log now seems to be out of sync in all the latest builds for f28,
> f29, f30, and f31.  It does not contain any change log entry for the actual
> NVR (Name-Version-Release) and it does contain any reference to this bug.

Sorry for the typo.  I meant to say that it does _not_ contain any reference to this bug.

Right, I forgot the changelog... I will push new builds to fix that.

What I meant as for the workaround, is that if you are using /usr/bin/shellcheck today, you can probably grab it from f31. Right now I don't know whether the ABI report is an actual problem for libHSShellCheck*.so consumers that should not be pushed to stable branches.

I know it is easy to fix the bug locally.  My main concern was that csmock-plugin-shellcheck would not work with unmodified mock profiles.

I have done a number of tests - though I don't understand those symbol change warning - I don't believe there is any user impact.

- I tested loading and using the library in ghci
- I did a dynamic executable local test build of ShellCheck (ie dynamically linked to libhsShellCheck-*.so)
  and it works fine both with the old and new ghc-ShellCheck libraries.

So I do believe it is fine to push it to F30 updates-testing and updates.


(In reply to Dridi Boukelmoune from comment #4)
> And as far as RPM tooling is concerned, there doesn't seem to be any ABI
> information captured at build time:
> 
>     $ rpm -qP ghc-ShellCheck
>     ghc-ShellCheck = 0.6.0-3.fc30
>     ghc-ShellCheck(x86-64) = 0.6.0-3.fc30
>     libHSShellCheck-0.6.0-3DaLvr1aI0a5T8ePxnZXaX-ghc8.4.4.so()(64bit)
> 
> And that last mangled library soname is still stable after applying the
> patch.

That is the ghc ABI hash for the library.

FEDORA-2019-a575d66e53 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-a575d66e53

ShellCheck-0.6.0-5.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e529cff64d

ShellCheck-0.6.0-3.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-a575d66e53

ShellCheck-0.6.0-5.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

ShellCheck-0.6.0-3.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.