Hi,
Fixing http://llvm.org/PR39427 in the release_70 branch, will change
the ABI of a clang built libLLVM-7.so so that it is no longer compatible
with the 7.0.0 release. libLLVM-7.so built by gcc will not be affected
by this fix.
Changing the ABI is something we aren't supposed to do in stable releases,
but this fixes an ABI difference between clang and gcc built
libLLVM-7.so that is impacting many users, including Linux distributions,
so an ABI change for clang only seems like the least bad solution in this case.
I am proposing that we hold this fix out of 7.0.1 and instead ship it in
a special 7.0.2 (or maybe 7.1.0 ?) release, so that users that want to
are still able to get all the bug-fixes without the ABI changes.
How does this sound to everyone?
Thanks,
Tom
I think this sounds reasonable. The important thing is that the fix
gets shipped, and if we do e.g. both 7.0.1 and 7.0.2 (I'm not sure
what version numbers would be best to use) that should hopefully serve
everyone well.
Thanks,
Hans
I am proposing that we hold this fix out of 7.0.1 and instead ship it in
a special 7.0.2 (or maybe 7.1.0 ?) release, so that users that want to
are still able to get all the bug-fixes without the ABI changes.
I think we should go with 7.1.0 instead of 7.0.2, since 7.1.0 looks unusual as opposed to 7.0.2, which looks like business as usual. This will help people to notice that the ABI changed.
How does this sound to everyone?
Sounds reasonable to me.
Jacob Lifshay
I am proposing that we hold this fix out of 7.0.1 and instead ship it in
a special 7.0.2 (or maybe 7.1.0 ?) release, so that users that want to
are still able to get all the bug-fixes without the ABI changes.
I think we should go with 7.1.0 instead of 7.0.2, since 7.1.0 looks unusual as opposed to 7.0.2, which looks like business as usual. This will help people to notice that the ABI changed.
+1 - ABI changes should increment the minor version number.
-Hal
How does this sound to everyone?
Sounds reasonable to me.
Jacob Lifshay
Hi,
While on topic of ABI changes, could I request that this (only the first
part which bumped the constant number up for OS targets) be merged into
an ABI breaking release?
https://reviews.llvm.org/rL347832
This is only the LLVMSupport part of the patch, the Clang half depends on
it but that is more of a feature thing so it's better left for 8.x.x. I'm
mentioning this because there was some confusion w/r Debian merging this
patch into their 7.x.x fork before it went into trunk which caused ABI
breakage for anyone who relied on the last enum member to determine
the size.
Thank you.
- Kristina
I am proposing that we hold this fix out of 7.0.1 and instead ship it in
a special 7.0.2 (or maybe 7.1.0 ?) release, so that users that want to
are still able to get all the bug-fixes without the ABI changes.
I think we should go with 7.1.0 instead of 7.0.2, since 7.1.0 looks unusual as opposed to 7.0.2, which looks like business as usual. This will help people to notice that the ABI changed.
This was my initial thought as well, but I'm not sure if this is technically
possible with our current system. The shared object only contains the
major version in its name, so we would need some other changes. I can look
into how feasible this would be.
-Tom
A separate release would be best for FreeBSD packages. I think 7.1.0
would be slightly better for me, but we can cope either way (we'd just
bump the versions of everything that depends on libLLVM.)
-- Brooks