Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?

[Anton Gladky]

Libreoffice migrated to testing. I am closing the bug.
Next time the symbols of the new version will be checked
precisely. Thanks all for discussion.

Regards

Anton


2017-09-08 23:17 GMT+02:00 Rene Engelhard :
> On Fri, Sep 08, 2017 at 07:37:03PM +0200, Francesco Poli wrote:
>> Will libreoffice/1:5.4.1-1 (currently in unstable and testing) break,
>> if I upgrade coinor-libcoinutils3v5 from version 2.9.15-4 to version
>> 2.10.14+repack1-1 ?
>
> The fix for LO is: rebuild coinmp. It works without rebuilding LO.
>
> That said, you probably didn't even check libreoffice/1:5.4.1-1s dependencies
> sincce to go very very sure for partial upgrades it depends on the new,
> rebuilt coinmp (and because coinutils didn't bump soname or so) on the 
> matching
> coinutils.
>
> So LO will work.
>
> Regards,
>
> Rene

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?

[Rene Engelhard]

On Fri, Sep 08, 2017 at 07:37:03PM +0200, Francesco Poli wrote:
> Will libreoffice/1:5.4.1-1 (currently in unstable and testing) break,
> if I upgrade coinor-libcoinutils3v5 from version 2.9.15-4 to version
> 2.10.14+repack1-1 ?

The fix for LO is: rebuild coinmp. It works without rebuilding LO.

That said, you probably didn't even check libreoffice/1:5.4.1-1s dependencies
sincce to go very very sure for partial upgrades it depends on the new,
rebuilt coinmp (and because coinutils didn't bump soname or so) on the matching
coinutils.

So LO will work.

Regards,

Rene

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?

[Francesco Poli]

On Mon, 28 Aug 2017 20:39:29 +0100 James Cowgill wrote:

> Hi,
> 
> On 28/08/17 19:57, Anton Gladky wrote:
> > Thanks all for discussion, explanations and investigations!
> > 
> > @Rene, I propose to close this bug or to wait till upload of libreoffice.
> > 
> > Next time, when the new coinutils version comes, I will let you know
> > and coinmp should be tested against the new coinutils. Then it should
> > probably be uploaded into the sid restricting in BD the minimal coinutils
> > to guarantee the ABI compatibility like it done for all other dependent
> > packages [1]. What do you think?
> > 
> > [1] 
> > https://anonscm.debian.org/cgit/debian-science/packages/coinor-cbc.git/tree/debian/control#n8
> 
> If there is an ABI break, you must rename the package. Trying to
> restrict the build-dependencies will have no effect on the dependencies
> at runtime which is where the ABI actually matters.
> 

Hello,
I am a user who pinned this package to version 2.9.15-4, because of
this bug.
I took a look at the bug log, but I am afraid I did not understand the
conclusion: is there an actual ABI break or is it just some weak
symbols appearing/disappearing depending on different inlining
decisions taken by different compiler versions?

Will libreoffice/1:5.4.1-1 (currently in unstable and testing) break,
if I upgrade coinor-libcoinutils3v5 from version 2.9.15-4 to version
2.10.14+repack1-1 ?

Should this bug report be closed or kept open?

Could you please clarify?
Thanks for your time and patience!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpVrEqqKUff2.pgp
Description: PGP signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?

[James Cowgill]

Hi,

On 28/08/17 19:57, Anton Gladky wrote:
> Thanks all for discussion, explanations and investigations!
> 
> @Rene, I propose to close this bug or to wait till upload of libreoffice.
> 
> Next time, when the new coinutils version comes, I will let you know
> and coinmp should be tested against the new coinutils. Then it should
> probably be uploaded into the sid restricting in BD the minimal coinutils
> to guarantee the ABI compatibility like it done for all other dependent
> packages [1]. What do you think?
> 
> [1] 
> https://anonscm.debian.org/cgit/debian-science/packages/coinor-cbc.git/tree/debian/control#n8

If there is an ABI break, you must rename the package. Trying to
restrict the build-dependencies will have no effect on the dependencies
at runtime which is where the ABI actually matters.

Thanks,
James



signature.asc
Description: OpenPGP digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?

[Anton Gladky]

Thanks all for discussion, explanations and investigations!

@Rene, I propose to close this bug or to wait till upload of libreoffice.

Next time, when the new coinutils version comes, I will let you know
and coinmp should be tested against the new coinutils. Then it should
probably be uploaded into the sid restricting in BD the minimal coinutils
to guarantee the ABI compatibility like it done for all other dependent
packages [1]. What do you think?

[1] 
https://anonscm.debian.org/cgit/debian-science/packages/coinor-cbc.git/tree/debian/control#n8

Best regards

Anton


2017-08-28 17:56 GMT+02:00 James Cowgill :
> These appear to be the 4 symbols which have disappeared after compiling
> with GCC-7:
>
>  469: 000cce10   430 FUNCWEAK   DEFAULT   12 
> _ZNK16CoinPackedMatrix14getVectorFirstEi
>  614: 000ccfc0   437 FUNCWEAK   DEFAULT   12 
> _ZNK16CoinPackedMatrix13getVectorLastEi
> 1119: 000fc710   120 FUNCWEAK   DEFAULT   12 
> _Z26presolve_delete_from_majoriiPKiPiS1_Pd
> 1198: 00043f80   566 FUNCWEAK   DEFAULT   12 
> _Z9CoinFillNItEvPT_iS0_
>
> As you can see all of these symbols are declared as weak. GCC will often
> do this for inline functions which it has decided not to inline for some
> reason. To satisfy the ODR, GCC will export all these symbols as weak
> from any object (including executables) which use them so that the same
> function is used throughout the entire application. Because consumers
> are supposed to generate their own versions of these functions, they do
> not form a part of the ABI and can safely be removed. In this case,
> GCC-7 simply decided that these functions should be inlined and
> therefore didn't generate symbols for them.
>
> I think it's more likely these ABI issues are caused by changes in the
> class layout (but I have not investigated this much). You can see a few
> cases of new fields being added if you diff the headers from the old and
> new packages. Generally, any issues with symbols would be found by the
> dynamic linker before an application has a chance to segfault.
>
> Thanks,
> James
>

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?

[James Cowgill]

Hi,

On 28/08/17 13:58, Mattia Rizzolo wrote:
> On Sun, 27 Aug 2017, 8:37 p.m. Anton Gladky  wrote:
> 
>> Hi Mattia,
>>
>> thanks for the tip! I have recompiled both libs with the same
>> current gcc-7.2. And it looks like there are no dropped symbols
>> (see file old-gcc7_new-gcc7.diff in attachment).
>>
>> But if I compare new so-file with the one shipped with Stretch
>> (compiled with gcc6)
>> the diff contains some missing symbols (see file  old-gcc6_new-gcc7.diff).
>>
> 
> Oh!  That's interesting...
> 
> What is the best practice for such kind of libs? Provide symbol-files?
> 
> Not sure.  I'd suggest to try to ask to -mentors@ or -devel@, or perhaps to
> James Cowgirl (CCed now) who helped with gcc-7 related stuff :)

These appear to be the 4 symbols which have disappeared after compiling
with GCC-7:

 469: 000cce10   430 FUNCWEAK   DEFAULT   12 
_ZNK16CoinPackedMatrix14getVectorFirstEi
 614: 000ccfc0   437 FUNCWEAK   DEFAULT   12 
_ZNK16CoinPackedMatrix13getVectorLastEi
1119: 000fc710   120 FUNCWEAK   DEFAULT   12 
_Z26presolve_delete_from_majoriiPKiPiS1_Pd
1198: 00043f80   566 FUNCWEAK   DEFAULT   12 _Z9CoinFillNItEvPT_iS0_

As you can see all of these symbols are declared as weak. GCC will often
do this for inline functions which it has decided not to inline for some
reason. To satisfy the ODR, GCC will export all these symbols as weak
from any object (including executables) which use them so that the same
function is used throughout the entire application. Because consumers
are supposed to generate their own versions of these functions, they do
not form a part of the ABI and can safely be removed. In this case,
GCC-7 simply decided that these functions should be inlined and
therefore didn't generate symbols for them.

I think it's more likely these ABI issues are caused by changes in the
class layout (but I have not investigated this much). You can see a few
cases of new fields being added if you diff the headers from the old and
new packages. Generally, any issues with symbols would be found by the
dynamic linker before an application has a chance to segfault.

Thanks,
James



signature.asc
Description: OpenPGP digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?

[Mattia Rizzolo]

On Sun, 27 Aug 2017, 8:37 p.m. Anton Gladky  wrote:

> Hi Mattia,
>
> thanks for the tip! I have recompiled both libs with the same
> current gcc-7.2. And it looks like there are no dropped symbols
> (see file old-gcc7_new-gcc7.diff in attachment).
>
> But if I compare new so-file with the one shipped with Stretch
> (compiled with gcc6)
> the diff contains some missing symbols (see file  old-gcc6_new-gcc7.diff).
>

Oh!  That's interesting...

What is the best practice for such kind of libs? Provide symbol-files?
>

Not sure.  I'd suggest to try to ask to -mentors@ or -devel@, or perhaps to
James Cowgirl (CCed now) who helped with gcc-7 related stuff :)

Thank you
>
> PS I have generated the symbols with the command:
>   readelf -Ws libCoinUtils.so |  awk '{print $8}'
>

Tbh, in general I'd use dpkg-gensymbols, but well, I think it's the same.
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?

[Anton Gladky]

Hi Mattia,

thanks for the tip! I have recompiled both libs with the same
current gcc-7.2. And it looks like there are no dropped symbols
(see file old-gcc7_new-gcc7.diff in attachment).

But if I compare new so-file with the one shipped with Stretch
(compiled with gcc6)
the diff contains some missing symbols (see file  old-gcc6_new-gcc7.diff).

What is the best practice for such kind of libs? Provide symbol-files?

Thank you

PS I have generated the symbols with the command:
  readelf -Ws libCoinUtils.so |  awk '{print $8}'

Anton


2017-08-27 18:04 GMT+02:00 Mattia Rizzolo :
> On Sun, Aug 27, 2017 at 03:16:46PM +0200, Anton Gladky wrote:
>> > Still I believe that this should be "correctly" fixed.
>>
>> You mean to increase so-version even if upstream does not do it and
>> to start the normal transition process? I think it is possible.
>
> That's actually your only option.
> Could someone check the symbols of the library before and after the
> upload and check whether some have been dropped?  If there are, not
> bumping SONAME is a bug upstream should deal with by doing another
> release and doing so (and failing so, in Debian you should at the very
> least rename the binary package (doing somethng alike to the v5 thing
> done for libstdc++5)).
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
diff --git a/symb_old_gcc6 b/symb_new_gcc7
index b2c7fe0..81b10dc 100644
--- a/symb_old_gcc6
+++ b/symb_new_gcc7
@@ -9,7 +9,6 @@ BZ2_bzWrite
 BZ2_bzWriteClose
 BZ2_bzWriteOpen
 calloc@GLIBC_2.2.5
-ceil@GLIBC_2.2.5
 c_ekkbtrn
 c_ekkbtrn_ipivrw
 c_ekketsj
@@ -70,7 +69,6 @@ isalnum@GLIBC_2.2.5
 isalpha@GLIBC_2.2.5
 _ITM_deregisterTMCloneTable
 _ITM_registerTMCloneTable
-_Jv_RegisterClasses
 log10@GLIBC_2.2.5
 log@GLIBC_2.2.5
 malloc@GLIBC_2.2.5
@@ -79,6 +77,7 @@ __memcpy_chk@GLIBC_2.3.4
 memcpy@GLIBC_2.14
 memmove@GLIBC_2.2.5
 memset@GLIBC_2.2.5
+modf@GLIBC_2.2.5
 pow@GLIBC_2.2.5
 __printf_chk@GLIBC_2.3.4
 putchar@GLIBC_2.2.5
@@ -109,7 +108,6 @@ strstr@GLIBC_2.2.5
 strtod@GLIBC_2.2.5
 strtol@GLIBC_2.2.5
 tolower@GLIBC_2.2.5
-trunc@GLIBC_2.2.5
 _Unwind_Resume@GCC_3.0
 _Z10c_ekkputl2PK12_EKKfactinfoPdS2_i
 _Z10clp_doublei
@@ -135,11 +133,13 @@ 
_Z11fileAbsPathRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
 _Z11log_wrapperd
 _Z11sin_wrapperd
 _Z12atan_wrapperd
+_Z12ceil_wrapperd
 _Z12CoinFromFileIdEiRPT_iP8_IO_FILERi
 _Z12CoinFromFileIiEiRPT_iP8_IO_FILERi
 _Z12fabs_wrapperd
 _Z12remove_fixedP18CoinPresolveMatrixPK18CoinPresolveAction
 _Z12sqrt_wrapperd
+_Z13floor_wrapperd
 _Z13testRedundantP18CoinPresolveMatrixPK18CoinPresolveAction
 _Z13transferCostsP18CoinPresolveMatrix
 _Z16check_tripletonsPK18CoinPresolveAction
@@ -158,7 +158,6 @@ 
_Z22drop_zero_coefficientsP18CoinPresolveMatrixPK18CoinPresolveAction
 _Z22presolve_make_memlistsPiP13presolvehlinki
 _Z24WindowsErrorPopupBlockerv
 _Z26getFunctionValueFromStringPKcS0_d
-_Z26presolve_delete_from_majoriiPKiPiS1_Pd
 _Z27presolve_delete_from_major2iiPiS_S_S_S_
 _Z7clp_inti
 _Z8clp_freePv
@@ -179,10 +178,10 @@ 
_Z9c_ekkrwctPK12_EKKfactinfoPdPiS3_PKiPK8EKKHlinkS8_PKsS2_ii
 _Z9c_ekkshffP12_EKKfactinfoP8EKKHlinkS2_i
 _Z9c_ekkshfvP12_EKKfactinfoP8EKKHlinkS2_i
 _Z9c_ekktriaP12_EKKfactinfoP8EKKHlinkS2_PiS3_S3_S3_i
+_Z9check_rowPiPdS_S_ddii
 _Z9CoinCopyNIdEvPKT_iPS0_
 _Z9CoinCopyNIiEvPKT_iPS0_
 _Z9CoinFillNIiEvPT_iS0_
-_Z9CoinFillNItEvPT_iS0_
 _Z9CoinIsnand
 _Z9CoinZeroNIdEvPT_i
 _Z9CoinZeroNIiEvPT_i
@@ -223,6 +222,7 @@ _ZN12CoinMessagesC2Ei
 _ZN12CoinMessagesC2ERKS_
 _ZN12CoinMessagesD1Ev
 _ZN12CoinMessagesD2Ev
+_ZN12CoinRational16nearestRational_Eddl
 _ZN12CoinRelFltEqD0Ev
 _ZN12CoinRelFltEqD1Ev
 _ZN12CoinRelFltEqD2Ev
@@ -358,6 +358,10 @@ 
_ZN14CoinSearchTreeI26CoinSearchTreeCompareDepthE8realpushEP16CoinTreeSiblings
 _ZN14CoinSearchTreeI26CoinSearchTreeCompareDepthED0Ev
 _ZN14CoinSearchTreeI26CoinSearchTreeCompareDepthED1Ev
 _ZN14CoinSearchTreeI26CoinSearchTreeCompareDepthED2Ev
+_ZN14duprow3_action8presolveEP18CoinPresolveMatrixPK18CoinPresolveAction
+_ZN14duprow3_actionD0Ev
+_ZN14duprow3_actionD1Ev
+_ZN14duprow3_actionD2Ev
 _ZN14FactorPointersC1EiiPiS0_
 _ZN14FactorPointersC2EiiPiS0_
 _ZN14FactorPointersD1Ev
@@ -1142,6 +1146,8 @@ _ZN8CoinLpIO6readLpEP8_IO_FILEd
 _ZN8CoinLpIO6readLpEPKc
 _ZN8CoinLpIO6readLpEPKcd
 _ZN8CoinLpIO7freeAllEv
+_ZN8CoinLpIO7loadSOSEiPK7CoinSet
+_ZN8CoinLpIO7loadSOSEiPPK7CoinSet
 _ZN8CoinLpIO7writeLpEP8_IO_FILEb
 _ZN8CoinLpIO7writeLpEP8_IO_FILEdiib
 _ZN8CoinLpIO7writeLpEPKcb
@@ -1340,6 +1346,8 @@ _ZNK14CoinFileIOBase11getFileNameEv
 _ZNK14CoinModelHash24hashEiiPK15CoinModelTriple
 _ZNK14CoinModelHash29hashValueEii
 _ZNK14CoinSearchTreeI26CoinSearchTreeCompareDepthE8compNameEv
+_ZNK14duprow3_action4nameEv

Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?

[Mattia Rizzolo]

On Sun, Aug 27, 2017 at 03:16:46PM +0200, Anton Gladky wrote:
> > Still I believe that this should be "correctly" fixed.
> 
> You mean to increase so-version even if upstream does not do it and
> to start the normal transition process? I think it is possible.

That's actually your only option.
Could someone check the symbols of the library before and after the
upload and check whether some have been dropped?  If there are, not
bumping SONAME is a bug upstream should deal with by doing another
release and doing so (and failing so, in Debian you should at the very
least rename the binary package (doing somethng alike to the v5 thing
done for libstdc++5)).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?

[Anton Gladky]

> Still I believe that this should be "correctly" fixed.

You mean to increase so-version even if upstream does not do it and
to start the normal transition process? I think it is possible.

> P.S.: Is it intended that coinutils contains 
> /usr/lib/x86_64-linux-gnu/pkgconfig/coindatasample.pc or is there a export 
> COIN_SKIP_PROJECTS="Sample" missing?

I do not know, whether it is really needed. This line is in
the .install-package [1] for a long time and  I did not remove
it last year, when overtook the maintenance on this package.

[1] 
https://anonscm.debian.org/cgit/debian-science/packages/coinutils.git/tree/debian/coinor-libcoinutils-dev.install#n4

Cheers

Anton

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?

[Rene Engelhard]

On Sun, Aug 27, 2017 at 01:59:04PM +0200, Rene Engelhard wrote:
> for coinmp and libreoffice (5.4.1 release will be next week) if we uploaded
> coinmp 1.8.3 to unstable...

Now uploaded coinmp 1.8.3-2 to unstable.

Let's see.
Test succeeds at least.

Still I believe that this should be "correctly" fixed.
 
Regards,
 
Rene

P.S.: Is it intended that coinutils contains 
/usr/lib/x86_64-linux-gnu/pkgconfig/coindatasample.pc or is there a export 
COIN_SKIP_PROJECTS="Sample" missing?

See 
https://anonscm.debian.org/cgit/debian-science/packages/coinmp.git/commit/?id=fccad9caf4d1698f1c294b73cd64f78c7d4a5727,
 without that I get that file in
coinor-libcoinmp-dev

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?

[Rene Engelhard]

Hi,

On Sun, Aug 27, 2017 at 01:26:30PM +0200, Anton Gladky wrote:
> thanks for the bug report and sorry for inconvenience. Upstream did
> not change the SO-version, so I decided not to do it explicitly and
> request transition. Looks like the changes were minimal.
> 
> If the coinmp-recompilation really fixes your problem,

Did, yes, as said.

Though I admit I am a bit confused given coinmp only links
to cbc, not coinutils. (LO does use coinutils, too, though)

> I would ask for binnmus of all rdepends.

That would be better than nothing, though that would "hide" the problem and
would cause problems if the libs for whatever reason get updated independently.
(like right now.)

I uploaded coinmp 1.8.3 to experimental today so I don't think we need bin-NMUs
for coinmp and libreoffice (5.4.1 release will be next week) if we uploaded
coinmp 1.8.3 to unstable...

Regards,

Rene

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?

[Anton Gladky]

Hi Rene,

thanks for the bug report and sorry for inconvenience. Upstream did
not change the SO-version, so I decided not to do it explicitly and
request transition. Looks like the changes were minimal.

If the coinmp-recompilation really fixes your problem, I would ask for
binnmus of all rdepends.

Thanks

Anton


2017-08-27 0:53 GMT+02:00 Rene Engelhard :
> Package: coinor-libcoinutils3v5
> Version: 2.10.14+repack1-1
> Severity: serious

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#873362: coinor-libcoinutils3v5: unannounced ABI change without SONAME change?

[Rene Engelhard]

Package: coinor-libcoinutils3v5
Version: 2.10.14+repack1-1
Severity: serious

Hi,

LOs unit tests fail (don't get confused by the name, also tests the CoinMP
based solver) since the last updates in sid:

build CUT] sccomp_lpsolver
S=/data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2 && 
I=$S/instdir && W=$S/workdir &&mkdir -p $W/CppunitTest/ && rm -fr 
$W/CppunitTest/sccomp_lpsolver.test.user && mkdir 
$W/CppunitTest/sccomp_lpsolver.test.user &&rm -fr 
$W/CppunitTest/sccomp_lpsolver.test.core && mkdir 
$W/CppunitTest/sccomp_lpsolver.test.core && cd 
$W/CppunitTest/sccomp_lpsolver.test.core && (   
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
   MALLOC_CHECK_=2 MALLOC_PERTURB_=153  
$W/LinkTarget/Executable/cppunittester 
$W/LinkTarget/CppunitTest/libtest_sccomp_lpsolver.so --headless 
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share" 
"-env:UserInstallation=file://$W/CppunitTest/sccomp_lpsolver.test.user"   
"-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry 
xcsxcu:file://$W/unittest/registry"  
"-env:UNO_TYPES=file://$I/program/types.rdb file://$I/program/types/offapi.rdb" 
 "-env:UNO_SERV
 ICES=file://$W/Rdb/ure/services.rdb file://$W/Rdb/services.rdb"  
-env:URE_INTERNAL_LIB_DIR=file://$I/program -env:LO_LIB_DIR=file://$I/program 
-env:LO_JAVA_DIR=file://$I/program/classes --protector 
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector 
--protector $W/LinkTarget/Library/unobootstrapprotector.so 
unobootstrapprotector   --protector 
$W/LinkTarget/Library/libvclbootstrapprotector.so vclbootstrapprotector   
"-env:CPPUNITTESTTARGET=$W/CppunitTest/sccomp_lpsolver.test"   )  > 
$W/CppunitTest/sccomp_lpsolver.test.log 2>&1 || ( RET=$?; 
$S/solenv/bin/gdb-core-bt.sh $W/LinkTarget/Executable/cppunittester 
$W/CppunitTest/sccomp_lpsolver.test.core $RET >> 
$W/CppunitTest/sccomp_lpsolver.test.log 2>&1; cat 
$W/CppunitTest/sccomp_lpsolver.test.log; 
$S/solenv/gbuild/platform/unittest-failed-default.sh Cppunit sccomp_lpsolver)
Segmentation fault (core dumped)
(anonymous namespace)::LpSolverTest::testLpSolver finished in: 579ms

It looks like 
/data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2/workdir/LinkTarget/Executable/cppunittester
 generated a core file at 
/data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2/workdir/CppunitTest/sccomp_lpsolver.test.core/core
Backtraces:
[New LWP 11917]
[New LWP 11918]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by 
`/data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2/workdir/Li'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f6dca552b9e in CoinMessageHandler::internalPrint() () from 
/usr/lib/x86_64-linux-gnu/libCoinUtils.so.3
[Current thread is 1 (Thread 0x7f6de7e2e740 (LWP 11917))]
warning: File 
"/data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2/instdir/program/libuno_sal.so.3-gdb.py"
 auto-loading has been declined by your `auto-load safe-path' set to 
"$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path 
/data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2/instdir/program/libuno_sal.so.3-gdb.py
line to your configuration file "/tmp/tmp.Aw8SthVoRj/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/tmp/tmp.Aw8SthVoRj/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
info "(gdb)Auto-loading safe path"
warning: File 
"/data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2/instdir/program/libuno_cppu.so.3-gdb.py"
 auto-loading has been declined by your `auto-load safe-path' set to 
"$debugdir:$datadir/auto-load".
warning: File 
"/data/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-5.4.1.2/instdir/program/libmergedlo.so-gdb.py"
 auto-loading has been declined by your `auto-load safe-path' set to 
"$debugdir:$datadir/auto-load".
rax0x0  0
rbx0x55fce8a092d0   94544722957008
rcx0x55fce8a094f8   94544722957560
rdx0x30 48
rsi0x0  0
rdi0x55fce8a092d0   94544722957008
rbp0x55fce8a092d0   0x55fce8a092d0
rsp0x7ffe59817bc0   0x7ffe59817bc0
r8 0x4  4
r9 0x4  4
r100x0  0
r110x1  1
120x0  0
r130x1  1
r140x7ffe59818020   140730400079904
r150x0  0
rip0x7f6dca552b9e   0x7f6dca552b9e 

eflags 0x10212  [ AF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0  0
es