Backporting LLVM 3.1 for Fedora 17

[Michel Alexandre Salim]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/11/2012 22:32, Jakub Jelinek wrote:
> On Fri, Nov 16, 2012 at 09:49:19AM -0500, Adam Jackson wrote:
>> That said, llvm consumers are difficult to keep in sync with
>> llvm anyway.  Many llvm projects seem like they pick a point
>> release to build against and then never get updated when the ABI
>> changes.  If we do this we might want to start by building
>> compat-llvm30 for the libraries and migrating the consumers
>> independently afterwards.  It'd be fine if that compat package
>> only lived for the one release that needs it (ie no compat-llvm30
>> in F18 or later, apps that aren't ported get deadpackaged), but
>> at least that way we could avoid breaking llvm apps in F17
>> updates that worked in F17 gold.
> 
Hm, that sounds really messy. We could have a compat package that
targets the release before the current release, certainly, but AIUI
the Fedora policy is that once you block a package from a release
(because it's not being used), you need a re-review before bringing
the package back to life. Seems like a high-overhead option.

What I envisage is more upgrading all the LLVM-dependent packages to
their F18 version. Right now, given that Adam's amenable to upgrading
Mesa, it's more a question of if any of the other packagers have any
objection. (I package pure, and it builds cleanly against multiple
LLVM versions, happily, so there's no problem there).

> I guess for that it doesn't help that only one of the 4 llvm-libs 
> shared libraries (libLLVM-3.*.so) has the version in its name, the
> other 3 clearly dependent on that one don't, eventhough I very much
> doubt they are anywhere close to be ABI compatible. Not to mention
> that somebody should tell the LLVM folks about the ld -soname 
> option, none of those 4 have DT_SONAME.
> 
Ah yes, that *is* another problem. I noticed it when they started
versioning libLLVM (that they did it in a bizarre way), but it's
something that certainly needs fixing. Now that the *BSDs are using
LLVM more (FreeBSD is making it their default compiler, even), perhaps
there's more traction into asking upstream to change this (though the
way FreeBSD builds LLVM is rather hard to decipher, so for all I know
they don't even use dynamic linking).

I'll check with upstream, since second-guessing what version to put in
the soname is a recipe for a versioning problem. It'll probably only
go in for 3.3 though.

Best,

- -- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  salimma at fedoraproject.org  | GPG key ID: A36A937A
Jabber: hircus at jabber.ccc.de       | IRC: hircus at irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQpuTpAAoJEEr1VKujapN6WNYH/irUWj9ZnR9NovVXfY9FFHsS
Tt8k8tkK02pyFVmLCeDm5aA4xQyxOW1vkgEwiokYPLGG2n1ixfhQ1CiXtVv0dbGn
OjOgTzdk1cLS+jcE387GWR4OUByCBBsLGGsIAhB2CMdlUKS/xcduyx5Dc9P098dD
gsaaJDYNxDQKc4GMrPQcOHSJwGkJAEzljkOlijdMPEFYzzPuzK1K2Fut9dAXgNrJ
FgUg0oR3dpq+MnDPCnoopsqM3o6+7OUb2uLuwbkFSLn5xSUukXqAR/0dpxUiI0Us
etTa8cr05vhn4sV+7rUro9t2C3bn88Y53HyPplLugYwFuWUsD1DFzF13gKIiJFE=
=dUDO
-----END PGP SIGNATURE-----