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 <jcowg...@debian.org>:
> These appear to be the 4 symbols which have disappeared after compiling
> with GCC-7:
>
>  469: 00000000000cce10   430 FUNC    WEAK   DEFAULT   12 
> _ZNK16CoinPackedMatrix14getVectorFirstEi
>  614: 00000000000ccfc0   437 FUNC    WEAK   DEFAULT   12 
> _ZNK16CoinPackedMatrix13getVectorLastEi
> 1119: 00000000000fc710   120 FUNC    WEAK   DEFAULT   12 
> _Z26presolve_delete_from_majoriiPKiPiS1_Pd
> 1198: 0000000000043f80   566 FUNC    WEAK   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
>

Reply via email to