Re: [gentoo-dev] Re: check-reqs* vs CFLAGS=-g
Dnia 2013-08-02, o godz. 02:07:18 Duncan <1i5t5.dun...@cox.net> napisał(a): > Michał Górny posted on Thu, 01 Aug 2013 13:33:48 +0200 as excerpted: > > > LLVM has peek build space consumption around: > > > > - 400-550M without clang (depending on targets), > > - 950-1200M with clang, > > - 16G with clang & USE=debug (assertions, checks). > > Ouch! > > Thanks for the heads-up. I didn't realize -g/debug added THAT much! For > sure I'll have to keep that in mind if I ever decide to build llvm with > debug... and the general rule in mind for building anything else with > debug. Just to make it clear, USE=debug doesn't imply -g. It gets 16G with -O2. Curious enough, -O0 -g gave me 14G but maybe I screwed something up :). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: check-reqs* vs CFLAGS=-g
Unlikely you screwed up, -O0 makes bigger code than -O2 almost in every case; then -g annotates it. I'm expecting -ggdb to take some few GBs more. It'll be the same if not worse with almost all software, -g3 would make it even worse. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Fri, Aug 2, 2013 at 9:05 AM, Michał Górny wrote: > Dnia 2013-08-02, o godz. 02:07:18 > Duncan <1i5t5.dun...@cox.net> napisał(a): > > > Michał Górny posted on Thu, 01 Aug 2013 13:33:48 +0200 as excerpted: > > > > > LLVM has peek build space consumption around: > > > > > > - 400-550M without clang (depending on targets), > > > - 950-1200M with clang, > > > - 16G with clang & USE=debug (assertions, checks). > > > > Ouch! > > > > Thanks for the heads-up. I didn't realize -g/debug added THAT much! For > > sure I'll have to keep that in mind if I ever decide to build llvm with > > debug... and the general rule in mind for building anything else with > > debug. > > Just to make it clear, USE=debug doesn't imply -g. It gets 16G with > -O2. Curious enough, -O0 -g gave me 14G but maybe I screwed something > up :). > > -- > Best regards, > Michał Górny >
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
On 01/08/13 04:48, William Hubbs wrote: > I would rather not carry distro-specific patches forever to support > something like this, so please forward your patches upstream. The code is in a public git, it is even not written by me, anybody can forward it to upstream... lu
[gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
Pacho Ramos wrote: > How the /usr in other partition ended finally then? I though that, since > there are a lot of things in / that rely in others in /usr, people were > supposed to either use initramfs or busybox to get /usr mounted As Rich said, lvm doesn't link outside rootfs so it's not an issue: you only really need an initramfs if rootfs is on lvm/encrypted/raid, or you need udev to get through localmount. William Hubbs wrote: > Unfortunately it hasn't ended; the debating over it just stopped. > > There was a council vote in April 2012 over this, but it isn't even > clear what they voted for. You know it was perfectly clear: zmedico had even posted the initial clarification of chainsaw's agenda item, immediately it was raised, and as ulm made it clear the last time this was discussed, that was what was voted on. What happened after was that people who didn't like the decision tried to weasel out of it by claiming that it wasn't really what was discussed, despite the clear trail. More of "the stupidity of not accepting decisions" and moving on to implementation, that is usually attributed to "traditionalists." > My personal opinion though, is that if people have /usr separate from > /, they should be using an initramfs to get /usr mounted. If they want > to use busybox[sep-usr] this is an option that we came up with > internally in gentoo, but it has many limitations. It's funny how you always discuss those two options and consistently fail to mention the one option that allows people who never needed an initramfs before to continue without one, and still use udev in line with upstream requirements, but there it is: http://forums.gentoo.org/viewtopic-t-901206.html (constructive feedback welcome, as ever: ie stuff that helps improve the situation, not arguments about why udev's upstream requirement isn't really what GregKH said it was.) -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
Steven J. Long posted on Fri, 02 Aug 2013 12:31:08 +0100 as excerpted: > As Rich said, lvm doesn't link outside rootfs so it's not an issue: you > only really need an initramfs if rootfs is on lvm/encrypted/raid, or you > need udev to get through localmount. Or, unfortunately, for root on mult-device btrfs[1], since the usual kernel commandline rootflags=device=/dev/whatever doesn't seem to work for some reason.[2] Tho hopefully that bug will be fixed before the "experimental" label is stripped from btrfs... --- [1] Yes, as appropriate for running on an experimental fs, I have backups, tho the dual-device raid1 mode I'm using is /reasonably/ stable, now. I switched to btrfs when I upgraded to ssd, both for the ssd support and for checksummed data/metadata with a second copy to retrieve from if the first fails the checksum. [2] I tried with a btrfs raid1 and could mount either device with root= and rootflags=degraded, so it was definitely parsing rootflags, but no way was it taking rootflags=device= to mount them undegraded without a userspace btrfs device scan first, and that requires an initr*. Maybe it was a problem with the kernel splitting at the second = instead of the first, I don't know, but it definitely wasn't working. So now I'm running dracut with several of its default modules stripped via INSTALL_MASK including the one pulling in kmod since I'm running monolithic kernel and have kmod package.provided, and USE=btrfs plus adding it to the module config. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] check-reqs* vs CFLAGS=-g
Am Donnerstag 01 August 2013, 13:33:48 schrieb Michał Górny: > > - 1.2G for -O2 (as shown above), > - 12G for -O0 -g. > I thought -O0 was generally discouraged, even for debugging?! -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing
Re: [gentoo-dev] check-reqs* vs CFLAGS=-g
Dnia 2013-08-02, o godz. 14:08:46 "Andreas K. Huettel" napisał(a): > Am Donnerstag 01 August 2013, 13:33:48 schrieb Michał Górny: > > > > - 1.2G for -O2 (as shown above), > > - 12G for -O0 -g. > > > > I thought -O0 was generally discouraged, even for debugging?! Depends on what you want to achieve. It's often hard to debug when stuff is 'optimized out' :). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] check-reqs* vs CFLAGS=-g
On Fri, Aug 2, 2013 at 1:08 PM, Andreas K. Huettel wrote: > I thought -O0 was generally discouraged, even for debugging?! As Michał said, it all depends on what you want to debug. I would say that for 90% of issues you *do not* want to use -O0. Your code might not even compile (libav for instance used to rely heavily in the DCE pass being executed, GCC disables DCE at -O0), and even if it, you're now given a different program altogether, so if you're looking for a crash, it might magically disappear (memory areas get cleared out at -O0 but they might be re-used without clearing at any other -O level). But if you're trying to step through an algorithm, an optimized version of the code will most likely reorder the code that you read from the sources. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
On Fri, Aug 2, 2013 at 7:31 AM, Steven J. Long wrote: > It's funny how you always discuss those two options and consistently fail to > mention > the one option that allows people who never needed an initramfs before to > continue > without one, and still use udev in line with upstream requirements, but there > it is: > > http://forums.gentoo.org/viewtopic-t-901206.html If we clarify the decision (which seems increasingly likely as there seems to be demand), I'd suggest we would vote on something like: On Gentoo we (do, do not) support configurations that do not place /usr on the root filesystem without an early-boot mechanism to mount it (eg an initramfs, early-running script, init replacement, etc). When I use the term initramfs it is intended just as a stand-in. That said, I think that the initramfs is honestly the cleanest solution for early-boot setup as it supports a huge variety of configurations. However, the actual policy would be more general, and the options that are available to users will be whatever the community is willing to supply/support. If anybody considers that ambiguous in any way please speak up now. As far as my own position goes, I'll be voting for do not. That doesn't mean that I think that maintainers should look to make dramatic changes overnight - we should still be sending out news/etc. I think that maintainers have made a sufficient case that this is where the winds are blowing. I was pretty concerned about this when the topic came up early last year, but I found getting dracut working wasn't hard (it is easier and more robust now) and brought a number of benefits beyond just mounting /usr. My root is now on lvm+mdadm, and I have a separate /usr and /var and it all works just fine (they're bind-mounts on top of yet another mount). When I build a new kernel it only takes one line to build an initramfs to go with it. Rich
[gentoo-dev] Last rites: git.eclass
# Michał Górny (2 Aug 2013) # This eclass has been superseded by git-2 eclass and will be removed # on 2013-09-02. Please modify your ebuilds to use git-2 instead. # Bug #479474. git.eclass -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] OpenRc-0.12 is coming soon
All, This message is an announcement and a reminder. OpenRc-0.12 will be introduced to the portage tree in the next few days. If you are using ~arch OpenRc, the standard disclaimer applies: remember that you might be subject to breakage. I do not know of any breakage personally. It does work on my system, and I know of others who are using OpenRc from git successfully. Some are OpenRc team members, and at least one is a Gentoo user. If you are not comfortable with the possibility of breakage, I recommend that you make sure you do not upgrade right away. If, on the other hand, you are comfortable with that possibility and you are willing to help us test and get rid of bugs before we go stable, feel free to run ~arch. In other words, this is the standard Gentoo disclaimer, so consider yourself warned. Thanks much, William signature.asc Description: Digital signature
[gentoo-dev] Global USE flag: git
Hello, we have "subversion" and "cvs" ad global flags, but not "git" (or hg|mercurial). I'm about to add the 14th [1] package using this flag. I propose a description "git - Enable git (version control system) support" in use.desc. Yes/No? Timeout in 7 days. Michael [1] % grep ":git " /usr/portage/profiles/use.local.desc app-admin/pass:git - Use dev-vcs/git for password revisions. app-editors/gedit-plugins:git - Shows document changes related to git's HEAD app-portage/layman:git - Support dev-vcs/git based overlays dev-python/anyvc:git - Add support for Git dev-qt/qt-creator:git - Add support for dev-vcs/git version control system dev-util/metro:git - Enable support for git snapshots dev-util/monodevelop:git - Enable Git version control support dev-vcs/cvs2svn:git - Support for dev-vcs/git dev-vcs/fromcvs:git - Add support for conversion to dev-vcs/git repositories dev-vcs/rabbitvcs:git - Enable plugin for dev-vcs/git kde-base/dolphin-plugins:git - Enable support for the git VCS sys-devel/gettext:git - When running `autopoint`, use git to store the internal development files; this requires git at runtime, but will be faster/smaller than raw archives xfce-extra/thunar-vcs-plugin:git - Enable dev-vcs/git support [2] % grep -ir version /usr/portage/profiles/use.desc cvs - Enable CVS (Concurrent Versions System) integration [...] subversion - Enable subversion (version control system) support -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
