Conversation
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.
Incompatible .so files based arbitrarily on which compiler you used. GNU/ugh.
2
0
1
Alexandre Oliva (moved to @lxo@gnusocial.jp)
lxo@gnusocial.net
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
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
1
0
1
@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"?
2
0
0
Alexandre Oliva (moved to @lxo@gnusocial.jp)
lxo@gnusocial.net
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)
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)
1
0
1
@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.
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.
0
0
1