Red Hat Bugzilla – Bug 521261
llvm: please build with --disable-assertions
Last modified: 2009-09-08 23:16:06 EDT
Working on packaging OpenGTL (for koffice, among other things), and it fails to build against llvm with assertions enabled. I talked to a developer on irc:
[09:49] <rdieter> CyrilleB: ping, I'm working on packaging OpenGTL for fedora, and have a couple of questions about it, if you have some moments
[09:50] <rdieter> first, with the latest version, the cryptic: llvm was build with asserts, this is not supported by OpenGTL.
[09:50] <rdieter> (llvm is built --enable-asserts on fedora, so I'll need a good justification to lobby for a change there)
[09:52] <CyrilleB> rdieter: llvm's asserts aren't thread safe, and therefore anyone using JIT of llvm in a threaded environment will experience crash
[09:52] <CyrilleB> rdieter: the question is why would anyone want to use asserts in a production environment :)
Fixed in llvm-2.5-6 (and newer), thanks.
Darn, OpenGTL builds only with 2.5, not 2.6 (api change?), but that's something we'll have to deal with sooner or later.
More OpenGTL comment (wrt my asking about llvm-2.6): (which you may or may not be aware of... but...):
[12:21] <rdieter> CyrilleB: another silly OpenGTL/llvm question from me. fedora's development branch just switched to llvm-2.6pre, but OpenGTL won't build with it. Is that something easily fixed or soon to be fixed?
<CyrilleB> rdieter: :( it's clearly not easily fixed, and won't be fixed until 2.6 is out
[12:26] <CyrilleB> rdieter: llvm doesn't maintain API compatibility between release, I don't know how many packages you have in fedora that depends on it at the moment, but I would suggest that you mention that issue to llvm packagers
Thanks for mentioning that. We don't have any for the moment that has API issues -- Pure is being packaged, but its maintainer is making sure it builds with 2.5, 2.6 and the current trunk (that will be 2.7).
Should we keep F-11 at 2.5 for a bit longer? I can push 2.5-6 to F-10 and F-11, now that -5 has made it to -stable. Though I might first spend some time backporting the 2.6 build script patches, so we don't have the buildroot embedded in the library files.
Unfortunately, my primary target for OpenGTL is F-12 (for koffice2), but I can understand other pressures, and can wait until llvm-2.6 (final) lands and OpenGTL gets fixed for it.
Ah. well, would it be possible to get OpenGTL in for F-11 (and maybe F-10) first, and then when 0.9.11 comes out you can just build for F-12 also? That will shake out any oddities and let the package review not stall for too long.
The timing is a bit unfortunate -- LLVM 2.6's release schedule is a perfect fit for F-12, though if OpenGTL and more packages like it are already in our repositories, the decision would have been different (and we would be shouting at upstream, both LLVM and dependent projects, to coordinate better among themselves!)