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
