Summary: | sys-devel/llvm improvements from ::mgorny overlay | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
Component: | Current packages | Assignee: | Bernard Cafarelli <voyageur> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | alexander, my, nikoli, ryao |
Priority: | Normal | Keywords: | PMASKED |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 417349, 422121, 434200, 453788, 473690, 474450, 477250 | ||
Attachments: | fix some stuff |
Description
Michał Górny
2013-07-19 21:24:26 UTC
I'll allow myself to block all the bugs I've fixed so far. Good news, everyone! I've finally got working 3.3 build in my overlay. Last issue that remains is the USE=debug build failing. However, it is horribly space-consuming so it will take a while before I can investigate it further. And this is low-priority to me, to be honest. Created attachment 353696 [details, diff]
fix some stuff
I do not have time to catch up with you
once again rewrite your patch
please see
and if you have any questions can be discussed?
And some comments We should check broken gcc version only if we use gcc I don't know how truth way to determine which compiler we use (In reply to Michał Górny from comment #0) > I still believe that we should work on having clang built separately and > therefore I believe we should keep other ebuilds depending on proper > sys-devel/clang versions. We cannot fix #417349 if we build clang separately and use clang as compiler Now ebuilds in overlay are broken, seems someone did not run 'repoman -pxv full': IUSE.missing 2 sys-devel/llvm/llvm-3.3-r1.ebuild: RDEPEND: USE flag 'vim-syntax' referenced in conditional 'vim-syntax?' is not in IUSE sys-devel/llvm/llvm-9999-r1.ebuild: RDEPEND: USE flag 'vim-syntax' referenced in conditional 'vim-syntax?' is not in IUSE See attached patch. (In reply to Nikoli from comment #6) > Now ebuilds in overlay are broken, seems someone did not run 'repoman -pxv > full': > IUSE.missing 2 > sys-devel/llvm/llvm-3.3-r1.ebuild: RDEPEND: USE flag 'vim-syntax' > referenced in conditional 'vim-syntax?' is not in IUSE > sys-devel/llvm/llvm-9999-r1.ebuild: RDEPEND: USE flag 'vim-syntax' > referenced in conditional 'vim-syntax?' is not in IUSE Fixed now. sys-devel/llvm-3.3-r1 builds fine, all tests work fine too, building vacuum package with clang works fine, scan-build also works fine. But there are QA warnings: * QA Notice: The following files contain writable and executable sections * Files with such sections will not work properly (or at all!) on some * architectures/operating systems. A bug should be filed at * http://bugs.gentoo.org/ to make sure the issue is fixed. * For more information, see http://hardened.gentoo.org/gnu-stack.xml * Please include the following list of files in your report: * Note: Bugs should be filed for the respective maintainers * of the package in question and not hardened@g.o. * !WX --- --- usr/lib/clang/3.3/lib/linux/libclang_rt.full-x86_64.a:floatundidf.o * !WX --- --- usr/lib/clang/3.3/lib/linux/libclang_rt.full-x86_64.a:floatundisf.o * !WX --- --- usr/lib/clang/3.3/lib/linux/libclang_rt.full-x86_64.a:floatundixf.o Also there is QA warning about a lot of files: * QA Notice: The following files contain insecure RUNPATHs * Please file a bug about this at http://bugs.gentoo.org/ * with the maintaining herd of the package. * /var/tmp/portage/sys-devel/llvm-3.3-r1/image/usr/bin/clang * /var/tmp/portage/sys-devel/llvm-3.3-r1/image/usr/bin/c-index-test ... (In reply to Nikoli from comment #8) > Also there is QA warning about a lot of files: > * QA Notice: The following files contain insecure RUNPATHs > * Please file a bug about this at http://bugs.gentoo.org/ > * with the maintaining herd of the package. > * /var/tmp/portage/sys-devel/llvm-3.3-r1/image/usr/bin/clang > * /var/tmp/portage/sys-devel/llvm-3.3-r1/image/usr/bin/c-index-test > ... Are you sure you've used the newest version? I think I've fixed this.already. But please wait a few minutes, my next batch of LLVM builds shall finish and I'll have a fresh result and push next changes to the overlay. Two new commits in the overlay. One fixes the runpath issue Nikoli mentioned. The other adds out-of-source build support. Using it, I was able to get multilib llvm+clang down to ~2G of disk space. 'insecure RUNPATHs' are fixed, but these warnings are still here: * !WX --- --- usr/lib/clang/3.3/lib/linux/libclang_rt.full-x86_64.a:floatundidf.o * !WX --- --- usr/lib/clang/3.3/lib/linux/libclang_rt.full-x86_64.a:floatundisf.o * !WX --- --- usr/lib/clang/3.3/lib/linux/libclang_rt.full-x86_64.a:floatundixf.o (In reply to Nikoli from comment #11) > 'insecure RUNPATHs' are fixed, but these warnings are still here: > * !WX --- --- > usr/lib/clang/3.3/lib/linux/libclang_rt.full-x86_64.a:floatundidf.o > * !WX --- --- > usr/lib/clang/3.3/lib/linux/libclang_rt.full-x86_64.a:floatundisf.o > * !WX --- --- > usr/lib/clang/3.3/lib/linux/libclang_rt.full-x86_64.a:floatundixf.o I'm afraid this one is outside my abilities and shall be taken upstream. Committed to the tree and added to multilib p.mask. (In reply to Michał Górny from comment #13) > Committed to the tree and added to multilib p.mask. in tree missing llvm-3.3-insecure-rpath.patch which require for llvm-3.3-r1.ebuild and why we check broken gcc version in pkg_setup it can be checked in pkg_pretend or no? (In reply to Oleg Ageev from comment #14) > (In reply to Michał Górny from comment #13) > > Committed to the tree and added to multilib p.mask. > in tree missing llvm-3.3-insecure-rpath.patch > which require for llvm-3.3-r1.ebuild Missing patch added. > and why we check broken gcc version in pkg_setup > it can be checked in pkg_pretend or no? That's something for a separate bug and careful consideration. I'm not sure if we can safely do that pkg_pretend() (gcc may be updated during the 'emerge @world' run). (In reply to Michał Górny from comment #15) package masked because have dependency which also masked? but if I have no-multilib profile, I should unmask manually? (In reply to Oleg Ageev from comment #16) > (In reply to Michał Górny from comment #15) > package masked because have dependency which also masked? > but if I have no-multilib profile, I should unmask manually? Yes, because of deps and because it waits for voyageur's review. Committed and unmasked as -3.3-r1 and 9999. |