Conversation

Notices

1. Embed this notice
   Lorenzo Stoakes (ljs@social.kernel.org)'s status on Friday, 22-Sep-2023 04:52:21 JST Lorenzo Stoakes
   If you think about it, the fact that gcc fucking broke the C++ ABI between 4 and 5 is absolutely goddamn insane.
   
   Incompatible .so files based arbitrarily on which compiler you used. GNU/ugh.
   • Embed this notice
     Alexandre Oliva (lxo@gnusocial.net)'s status on Friday, 22-Sep-2023 04:52:21 JST Alexandre Oliva

     in reply to
     not so much "broke" as "fixed"
     IIRC it was incompatible with other compilers due to bugs, and at some point the time came to fix them, otherwise the state of "incompatible .so files based arbitrarily on which compiler you used" would have remained there, permanently.
     but yeah, such fixes are painful and unfortunate
     on the good side, they offer opportunities to fix other problems that would be a permanent maintenance burden, but that the ABI barrier enables tools to overcome
   • Embed this notice
     Lorenzo Stoakes (ljs@social.kernel.org)'s status on Friday, 22-Sep-2023 05:25:18 JST Lorenzo Stoakes

     in reply to

     • Alexandre Oliva
     @lxo so they replaced "incompatible .so files based arbitrarily on which compiler you use" with "incompatible .so files based arbitrarily on which compiler you use"?
   • Embed this notice
     Alexandre Oliva (lxo@gnusocial.net)'s status on Friday, 22-Sep-2023 05:25:18 JST Alexandre Oliva

     in reply to
     yeah, but you omitted the ends of the quotes. the first ends with "with no foreseeable end to the pain", whereas the latter ends with "that will hurt a lot at first but slowly fade away over time"
     
     the least worst thing might be to enable painless ABI transition, but that is often incredibly hard (as in not worth the trouble) and brings about its own set of pain spots and pitfalls that most casual users are not prepared to deal with, so it doesn't even avoid the pain
     
     so making lots of such incompatible fixes and improvements at once, painful as it is, is probably the least painful approach overall
     
     and then, most of the pain arises because of code that one can't or doesn't want to recompile (e.g., because it's proprietary and you don't have source code to recompile)
   • Embed this notice
     Lorenzo Stoakes (ljs@social.kernel.org)'s status on Friday, 22-Sep-2023 08:43:18 JST Lorenzo Stoakes

     in reply to

     • Alexandre Oliva
     @lxo yeah you're right, sorry, I was missing the context previously that existing breaks were present.
     
     It's frustrating but I do agree given that that was the case, the most sensible thing is to rip the bandage off and get it done (along side the whole std::string thing).
     
     It is precisely that use case that's the issue I'm encountering. Recompiling resolves it, but in this instance isn't possible.
     Alexandre Oliva likes this.