Re: Heads up: F21 LLVM rebase
On Sat, 2014-12-13 at 01:51 +0100, Kevin Kofler wrote: There can be only one version of LLVM in the whole distribution at a time. To be entirely fair this is a failing of upstream LLVM for not using symbol versioning on Linux. On OSX, where clearly most of LLVM's development happens, this isn't an issue because Mach-O's two level namespacing means every imported symbol knows which library it came from. If libLLVM used ELF symbol versions we'd get the same effect, and then you could have llvm 3.5 and 3.6 in the same address space and things would Just Work. I'd submitted a patch for this but it didn't get merged in 3.5, at least partly because gold doesn't support all the same command line options as binutils' ld. I'd make a snarky comment here about how the freedom to choose to use a different linker is clearly a great thing that improves users' lives, and about how mere packaging policy by definition cannot fix implementation bugs, but at this point I feel like I'm screaming at a wall. I'll try again for 3.6. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F21 LLVM rebase
On Thu, 2014-12-11 at 12:16 -0500, Adam Jackson wrote: I've started staging an LLVM 3.5 rebase in F21. I hope to have everything built by this Friday and the update available in testing by Monday. Test feedback would be particularly appreciated on secondary arches and radeonsi 3D hardware. Well, submitted for testing today anyway: https://admin.fedoraproject.org/updates/gambas3-3.6.1-2.fc21,julia-0.3.3-2.fc21,llvm-3.5.0-4.fc21,mesa-10.4.0-1.20141214.fc21,pocl-0.10-2.fc21,pure-0.62-2.fc21 Presumably that'll bubble out to mirrors tomorrow. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F21 LLVM rebase
On Fri, Dec 12, 2014 at 7:51 PM, Kevin Kofler kevin.kof...@chello.at wrote: Michael DePaulo wrote: I too come from an Ubuntu/Debian background. Like other major pieces of software, Ubuntu and Debian both make multiple 2.x or 3.x versions of LLVM available for each release of their OS. They do the following: 1. The major version is specified in the package name. For example, llvm-3.4 and llvm-3.5 are the names of separate packages. The actual package versions are like 3.4.2-13 3.5-6 respectively 2. The package llvm is a small package that depends on the recommended major version for developers. For example, in Jessie, 3.5 is the recommended major version, and Jessie llvm contains symlinks such as: /usr/bin/llvm-extract - /usr/bin/llvm-extract-3.5 Would Fedora permit someone like myself to contribute an LLVM packaging scheme like that? That would NOT be a good idea, for a simple reason: The version of LLVM Mesa (i.e., libGL) links ends up linked into MANY executables. If you link some other library against some other version of LLVM, and then an application ends up directly or indirectly linking both that library and libGL, it ends up indirectly linking the 2 incompatible versions of LLVM and crashing. We have already had this happen, and other distributions too, see e.g.: http://www.valdyas.org/fading/index.cgi/2011/10/08#llvm and still, months later (when it was already long fixed in Fedora by using a common shared LLVM, but apparently not on some other distributions): http://mail.kde.org/pipermail/kimageshop/2012-September/011387.html (Now, to be fair, it turns out that OpenGTL has since been removed from Fedora because Krita no longer uses it, but the exact same problem can happen with any of the other consumers of LLVM.) There can be only one version of LLVM in the whole distribution at a time. This topic has already come up several times on this mailing list (basically each time such a rebase was done), please read the archives, e.g., this thread: https://lists.fedoraproject.org/pipermail/devel/2014-March/197227.html and my reply to a proposal essentially identical to yours: https://lists.fedoraproject.org/pipermail/devel/2014-March/197278.html Kevin Kofler Understood, sorry for not searching the archives. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F21 LLVM rebase
W dniu 11.12.2014 o 18:16, Adam Jackson pisze: I've started staging an LLVM 3.5 rebase in F21. I hope to have everything built by this Friday and the update available in testing by Monday. Test feedback would be particularly appreciated on secondary arches and radeonsi 3D hardware. Can someone explain to me (like to total idiot would be best) why after release of stable version developers start to update components? IMHO time for it was during F21 development and now work should concentrate on F22 with just stable fixes for released versions. But maybe it is just yet another difference between Debian (which world I was living in for 14 years) and Fedora (year of using) world. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F21 LLVM rebase
On Fri, Dec 12, 2014 at 7:01 AM, Marcin Juszkiewicz mjuszkiew...@redhat.com wrote: W dniu 11.12.2014 o 18:16, Adam Jackson pisze: I've started staging an LLVM 3.5 rebase in F21. I hope to have everything built by this Friday and the update available in testing by Monday. Test feedback would be particularly appreciated on secondary arches and radeonsi 3D hardware. Can someone explain to me (like to total idiot would be best) why after release of stable version developers start to update components? IMHO time for it was during F21 development and now work should concentrate on F22 with just stable fixes for released versions. But maybe it is just yet another difference between Debian (which world I was living in for 14 years) and Fedora (year of using) world. [...] Unlike gcc, Isn't LLVM part of ring 2 in Fedora.next? http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-update-part-ii-whats-happening/ If you want a reason for why higher rings are upgraded after release, I think the answer is: http://fedoraproject.org/wiki/Staying_close_to_upstream_projects I wasn't able to find a definitive answer via DDG or Google, but I think that no more LLVM 3.4.x maintenance releases will be released. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F21 LLVM rebase
On Fri, Dec 12, 2014 at 1:01 PM, Marcin Juszkiewicz mjuszkiew...@redhat.com wrote: W dniu 11.12.2014 o 18:16, Adam Jackson pisze: I've started staging an LLVM 3.5 rebase in F21. I hope to have everything built by this Friday and the update available in testing by Monday. Test feedback would be particularly appreciated on secondary arches and radeonsi 3D hardware. Can someone explain to me (like to total idiot would be best) why after release of stable version developers start to update components? IMHO time for it was during F21 development and now work should concentrate on F22 with just stable fixes for released versions. But maybe it is just yet another difference between Debian (which world I was living in for 14 years) and Fedora (year of using) world. Rebasing mesa (with a new llvm) does enable features of hardware that currently cannot be used or enable use of hardware that does not work currently. Simply telling the users go buy different hardware or wait six months is not the way to go. (We have done this in the past multiple times; its not the first time). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F21 LLVM rebase
On Fri, 2014-12-12 at 13:01 +0100, Marcin Juszkiewicz wrote: W dniu 11.12.2014 o 18:16, Adam Jackson pisze: I've started staging an LLVM 3.5 rebase in F21. I hope to have everything built by this Friday and the update available in testing by Monday. Test feedback would be particularly appreciated on secondary arches and radeonsi 3D hardware. Can someone explain to me (like to total idiot would be best) why after release of stable version developers start to update components? IMHO time for it was during F21 development and now work should concentrate on F22 with just stable fixes for released versions. We need to update Mesa in stable releases for hardware enablement, otherwise people buy new hardware and can't use 3D and then Fedora sucks. Mesa and LLVM are sufficiently closely entwined these days that eventually I can't build fully-featured Mesa without updating LLVM. This isn't the first time the llvm soname has changed within a release, in fact it's happened at least once per release since F18 afaict. Yes, it's disruptive, it's a gigantic pain in the ass, I don't enjoy doing it at all. llvm upstream seem to have no concept of consumable interface design, so at this point around half of the llvm-using components in Fedora have to be built from the same srpm as llvm itself; most of them are only build-tested with clang, so I also get the joy of trying to port them to gcc. All this without having much working knowledge of C++, on account of how I want to be able to look myself in the mirror in the morning without crying. I'm not a toolchain hacker. I want not to work on this crap. But either someone does it, or Mesa goes stale, so it's gotta get done. On the flip side, by synchronizing llvm (and Mesa and friends) across releases, graphics devel has more time to spend on _everyone_'s issues, because we don't have to waste time tracking which bug was fixed in which branch. In this particular case I had _wanted_ to get 3.5 into F21 gold in the first place [1], since it's sort of mandatory to make ppc64le actually work. The timing didn't quite work out, so it happens in updates instead. Sorry about that, life doesn't always admit pretty solutions. [1] - https://lists.fedoraproject.org/pipermail/devel/2014-October/203463.html - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F21 LLVM rebase
On Fri, Dec 12, 2014 at 10:30 AM, Adam Jackson a...@redhat.com wrote: On Fri, 2014-12-12 at 13:01 +0100, Marcin Juszkiewicz wrote: W dniu 11.12.2014 o 18:16, Adam Jackson pisze: I've started staging an LLVM 3.5 rebase in F21. I hope to have everything built by this Friday and the update available in testing by Monday. Test feedback would be particularly appreciated on secondary arches and radeonsi 3D hardware. Can someone explain to me (like to total idiot would be best) why after release of stable version developers start to update components? IMHO time for it was during F21 development and now work should concentrate on F22 with just stable fixes for released versions. We need to update Mesa in stable releases for hardware enablement, otherwise people buy new hardware and can't use 3D and then Fedora sucks. Mesa and LLVM are sufficiently closely entwined these days that eventually I can't build fully-featured Mesa without updating LLVM. This isn't the first time the llvm soname has changed within a release, in fact it's happened at least once per release since F18 afaict. Yes, it's disruptive, it's a gigantic pain in the ass, I don't enjoy doing it at all. llvm upstream seem to have no concept of consumable interface design, so at this point around half of the llvm-using components in Fedora have to be built from the same srpm as llvm itself; most of them are only build-tested with clang, so I also get the joy of trying to port them to gcc. All this without having much working knowledge of C++, on account of how I want to be able to look myself in the mirror in the morning without crying. I'm not a toolchain hacker. I want not to work on this crap. But either someone does it, or Mesa goes stale, so it's gotta get done. On the flip side, by synchronizing llvm (and Mesa and friends) across releases, graphics devel has more time to spend on _everyone_'s issues, because we don't have to waste time tracking which bug was fixed in which branch. In this particular case I had _wanted_ to get 3.5 into F21 gold in the first place [1], since it's sort of mandatory to make ppc64le actually work. The timing didn't quite work out, so it happens in updates instead. Sorry about that, life doesn't always admit pretty solutions. [1] - https://lists.fedoraproject.org/pipermail/devel/2014-October/203463.html - ajax [...] 1st, thank you for the contributions you make. I too come from an Ubuntu/Debian background. Like other major pieces of software, Ubuntu and Debian both make multiple 2.x or 3.x versions of LLVM available for each release of their OS. They do the following: 1. The major version is specified in the package name. For example, llvm-3.4 and llvm-3.5 are the names of separate packages. The actual package versions are like 3.4.2-13 3.5-6 respectively 2. The package llvm is a small package that depends on the recommended major version for developers. For example, in Jessie, 3.5 is the recommended major version, and Jessie llvm contains symlinks such as: /usr/bin/llvm-extract - /usr/bin/llvm-extract-3.5 Would Fedora permit someone like myself to contribute an LLVM packaging scheme like that? -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F21 LLVM rebase
Michael DePaulo wrote: I too come from an Ubuntu/Debian background. Like other major pieces of software, Ubuntu and Debian both make multiple 2.x or 3.x versions of LLVM available for each release of their OS. They do the following: 1. The major version is specified in the package name. For example, llvm-3.4 and llvm-3.5 are the names of separate packages. The actual package versions are like 3.4.2-13 3.5-6 respectively 2. The package llvm is a small package that depends on the recommended major version for developers. For example, in Jessie, 3.5 is the recommended major version, and Jessie llvm contains symlinks such as: /usr/bin/llvm-extract - /usr/bin/llvm-extract-3.5 Would Fedora permit someone like myself to contribute an LLVM packaging scheme like that? That would NOT be a good idea, for a simple reason: The version of LLVM Mesa (i.e., libGL) links ends up linked into MANY executables. If you link some other library against some other version of LLVM, and then an application ends up directly or indirectly linking both that library and libGL, it ends up indirectly linking the 2 incompatible versions of LLVM and crashing. We have already had this happen, and other distributions too, see e.g.: http://www.valdyas.org/fading/index.cgi/2011/10/08#llvm and still, months later (when it was already long fixed in Fedora by using a common shared LLVM, but apparently not on some other distributions): http://mail.kde.org/pipermail/kimageshop/2012-September/011387.html (Now, to be fair, it turns out that OpenGTL has since been removed from Fedora because Krita no longer uses it, but the exact same problem can happen with any of the other consumers of LLVM.) There can be only one version of LLVM in the whole distribution at a time. This topic has already come up several times on this mailing list (basically each time such a rebase was done), please read the archives, e.g., this thread: https://lists.fedoraproject.org/pipermail/devel/2014-March/197227.html and my reply to a proposal essentially identical to yours: https://lists.fedoraproject.org/pipermail/devel/2014-March/197278.html Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Heads up: F21 LLVM rebase
I've started staging an LLVM 3.5 rebase in F21. I hope to have everything built by this Friday and the update available in testing by Monday. Test feedback would be particularly appreciated on secondary arches and radeonsi 3D hardware. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
