This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 521261 - llvm: please build with --disable-assertions
llvm: please build with --disable-assertions
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: llvm (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Bryan O'Sullivan
Fedora Extras Quality Assurance
:
Depends On:
Blocks: OpenGTL
  Show dependency treegraph
 
Reported: 2009-09-04 11:03 EDT by Rex Dieter
Modified: 2009-09-08 23:16 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-08 12:24:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Rex Dieter 2009-09-04 11:03:50 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 :)
Comment 1 Rex Dieter 2009-09-08 12:24:34 EDT
Fixed in llvm-2.5-6 (and newer), thanks.
Comment 2 Rex Dieter 2009-09-08 13:11:12 EDT
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.
Comment 3 Rex Dieter 2009-09-08 14:28:23 EDT
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
Comment 4 Michel Alexandre Salim 2009-09-08 21:26:13 EDT
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.
Comment 5 Rex Dieter 2009-09-08 22:14:01 EDT
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.
Comment 6 Michel Alexandre Salim 2009-09-08 23:16:06 EDT
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!)

Note You need to log in before you can comment on or make changes to this bug.