Re: GCC backport for atomic operations on armel
On 27/11/2018 17:18, Emilio Pozuelo Monfort wrote:
> Hi,
>
> Currently llvm-toolchain-4.0 fails to build on armel [1] because std::future is
> broken there, see [2]. To fix this, I have backported the upstream patch to not
> require lock-free atomic ops (armel doesn't have them). This makes llvm build
> fine, which should in turn allow rustc/cargo/firefox/thunderbird to build. My
> biggest question is how to handle the symbol vers. I have added them to the
> latest version that this gcc-4.9 has (GLIBCXX_3.4.19, CXXABI_1.3.7) whereas the
> upstream fix (and I suppose the libstdc++ in stretch) have them in a newer
> version. I am not sure if having the symbols with a newer version when upgrading
> would be problematic, so I wonder if the patch as is would be fine, or if I
> should stick to the version that stretch has (which would mean adding new tags
> as jessie's GCC doesn't have those versions). Any thoughts?
FTR:
After some investigation and asking Aurelien about this, I looked into using the
same version for these symbols than newer libstdc would have. So I looked at
using the newer versions that GCC 4.9 doesn't really have, which gave me some
problems. I then looked at stretch's libstdc++ and realised that these symbols
are present in armel and have their original version (same one as in other
architectures), as this patch wasn't applied yet to GCC. That means that for sid
the version differs. However for jessie this simplifies things as we can just
use the same version as in other arches, which will also match stretch's
libstdc++, without having to mess with the symbol versioning.
Cheers,
Emilio
Reply to: