On Mon, 23 Mar 2015 19:53:45 +0900 Joel Rees <joel.r...@gmail.com> wrote:
> But this probably is not my real question.
but to answer it still, A LOT. (i vaguely remember it being over a gig).
>
> I saw the notice about libssl and decided it was time to update things.
>
> Updated kernel and system userland (5.6 stable).
>
> Forgetting what I was doing. My mind was shot, should not have had the hood
> up in the condition I was in. Instead of doing a pkg_add -u, I did a cvs up
> in /usr/ports. Got some updates, remember firefox and some other stuff
> among them.
tired? i think everybody who has been around long enough has done such
misjudging of their state.. when you realize it is taking longer to think
thru some things, it is time to go to sleep..
>
> Started to just do make in /usr/ports, and it started sequencing through
> the archivers, installing things like cabextract, which I'm pretty sure I
> don't need. Thought it was trying to install everything. I stopped that
> with a ctrl-c and scratched my head, did a make clean and a pkg_check.
>
it is indeed trying to build everything, since you started in /usr/ports.
if you started in one of the subdirs and did 'make' it would try to build
everything in that subdir (eg /usr/ports/net).
> Then tried a pkg_add -u and nothing gets added.
>
> I'm a bit worried about not updating firefox (31.0 to 31.5, if I read the
> text flying by on the screen right) even though it isn't specifically
> mentioned on the errata page. (Is it perhaps listed in the patches?) So I
> tried doing make update in www/firefox-esr, and it finds lots of things to
> update, then dies on a full disk. 1.6G for just /usr/ports, 104% in use.
i think you need more room on ports. there is some data in one of the faqs.
>
> make clean brings it down to 50% use, and I've located a ballooning build
> within gcc 4.8.3, which firefox 31.5 requires. (Why, I wouldn't care to
> guess.)
a lot of things need non-base versions of gcc anymore.
look in /usr/ports/pobj, where the ports are built. not everything cleans
itself up. i have a small script that removes at least what is installed.
it does't work for flavors though (the directories are pkgname,no_x11), but
you can just manually check what is installed and delete that dir.
ports_pobj_clean:
-------------------------------
#!/bin/ksh
#@PURPOSE clean out ports/pobj, remove dirs of installed pkg
cd /usr/ports/pobj
#pkg_info can be very slow, save a local copy
pkg_info >pklist
for _port in *;do
[ -d $_port ] || continue
grep -q "^$_port[pv ]" pklist && { echo $_port; rm -fr $_port; }
done
rm pklist
>
> I thought gmp was the culprit, but trying to trap the culprit by teeing the
> output of make, it seems to get past that through some gnat-bind stuff and
> cp ecj-4.5.jar (bleaugh) and then a perl script that apparently tries to
> fix up some #defines related to GLIBCXX_HAVE_GETS and then starts in on
> patching.
tee-ing is a good idea, i have my scripts do this automatically so when
problems arise, it's easy to reference. especially with long builds (like
release).
>
> And patch-boehm-gc-dyn_load_c did not apply cleanly. And about five
> not-patched-cleanly patches later it reports no room left on the device.
> (I'm thinking about wiping each directory under lang/gcc and trying a cvs
> get there, but du seems to say the ballooned file is elsewhere.)
all build files are in /usr/ports/pobj, nothing gets saved in the main
directories.
>
> I have another 5.6 box that is currently building the userland, for
> reference, but while I'm waiting, I thought I'd ask about the ballooning
> build.
make sure your ports are in sync with your build. if you are using cvs, make
sure to update both /usr/src and /usr/ports. if you install from a snapshot
make sure to grab the ports.tar.gz in the snapshot dir as well.
>
> And if anyone cares to help me untangle my thinking, ...
>
> Joel Rees
>
> Computer memory is just fancy paper,
> CPUs just fancy pens.
> All is a stream of text
> flowing from the past into the future.
>
clear out pobj and try again. you can also just 'rm -fr /usr/ports/pobj' if
you don't mind deleting half-built ports. it may be a good idea anyway as
some things may apply, and some not, so your build will be in a bad state.
if a port won't compile right, delete and retry. this has worked for me for
some odd errors i couldn't explain, and they didn't recur. if they do recur
that is possibly a matter for ports@.
and if you want to answer your original question, after you have built gcc,
do a 'du -sk /usr/ports/pobj/gcc*'.
cheers
