Re: ISO image: where is the CLANG compiler?

On Thu, Jan 19, 2017 at 10:16:46AM +0100, O. Hartmann wrote:
> On Thu, 19 Jan 2017 06:58:16 +0100
> Matthias Apitz <guru_at_unixarea.de> wrote:
> 
> > El día Wednesday, January 18, 2017 a las 08:00:04PM -0500, Allan Jude
> > escribió:
> > 
> > > On 2017-01-18 14:37, O. Hartmann wrote:  
> > > > Am Wed, 18 Jan 2017 16:38:32 +0100
> > > > Matthias Apitz <guru_at_unixarea.de> schrieb:
> > > >   
> > > >> Why you do not just boot from USB some mem stick image, mount some disk
> > > >> space to /mnt, svn checkout CURRENT to /mnt and build a booteable system
> > > >> (world and kernel) and install to DESTDIR=/mnt ?
> > > >>
> > > >> I do not understand all this hassle?
> > > >>
> > > >> 	matthias
> > > >>  
> > > > 
> > > > Wow!
> > > > 
> > > > As I initially stated, that is EXACTLY what I was inclined to do except
> > > > the fact that I had already an intact /usr/obj and usr/src with a
> > > > complete compiled system.
> > > > 
> > > > I booted from mem stick and I was lost due to no cc!
> > > > 
> > > > Even for "make installworld" it seems I have to rely on the compiler. And
> > > > the images (ISO, memstick et cetera) provided these days do not contain
> > > > any clang.  
> > 
> > Yes, you will need it and it will complain about missing it, if for
> > example you moved 'obj and 'src' to other dirs after 'make build...'
> > 
> > But, in your case the mem image really is lacking the cc/clang; I
> > fetched the image an did:
> > 
> > 
> > # mdconfig -a -t vnode -u 1 -f
> > ~guru/Downloads/FreeBSD-11.0-RELEASE-amd64-memstick.img # mount -o
> > ro /dev/md1p3 /mnt # find /mnt -name clang
> > /mnt/usr/share/doc/llvm/clang
> > /mnt/usr/lib/clang
> > /mnt/usr/lib/debug/usr/lib/clang
> > # find /mnt -name cc
> > /mnt/usr/include/netinet/cc
> > 
> > With this img  alone, you can't compile a system :-(
> > 
> > Setup a system from DVD and build your own image containing a complete
> > system on an USB key; with this boot your damaged system, recompile and
> > reinstall world and kernel. If you (O. Hartmann) need a step by step
> > guide, I could send it to you.
> > 
> > 	matthias
> > 
> 
> Hello,
> 
> thanks for your help offering! very kind.
> 
> I've already solved the problem - not with the suggested process, but via
> copying missing libs and files from and identical intact source. After that, I
> ran make buildword/buildkernel and was able to successfully install the new
> system.
> 
> As I stated before: I already had a complete compiled world and kernel existing
> in their proper, intact folders (usr/src and usr/obj). There was no need to
> compile a whole world.
> Intending to "make installworld" failed, this is the real problem, because the
> ISO/memstick images provided lack obviously in the required infrastructure and
> so these images are worthless for sophisticated rescue operations - or even
> such a simple ask as described initially in my posting.
> 
> I created images on CURRENT of my own - they all lack in the ability of having
> the necessary tools aboard. So I consider every image useless for rescue
> operations except, maybe, the DVD image - but this one is not provided anymore.
> For what reason? Time? Accepted. Space/disk usage? Well, welcome back in the
> stoneage of computer technology ... 
> 
> I remember faintly that there was a small discussion on the _at_CURRENT list, but
> I didn't realize that the result would be the extraction of the compiler.
> 
> Just for the record: most servers delivered to us do not have CD/DVD drives
> anymore - they are outdated and considered an extra these days. Purchasing 1 GB
> USB thumbdrives is getting even harder, smallest size my employer provides now
> is 2 GB. And most optical drives are DVD. From my point of view - and this is a
> personal view - the "standard" is > 1GB so there is no need to break down by
> force the FreeBSD image (if size is the reason) down to < 800 MB or < 1 GB. I'd
> consider having < 2GB the line of standards (2 GB USB mem drive).
> And for those, with need of very small images, smaller images could be provided
> as the extra.
> 

I do want to weigh in here and inform I am actively watching this
thread.  clang(1) is not in disc1.iso or bootonly.iso because the
MK_TOOLCHAIN knob is disabled in the targets that generate them.  This
has actually been the case for quite some time for these images.

dvd1.iso does contain clang, but very rarely (if ever, actually) are
there dvd1.iso images produced for development snapshots.  This is, in
part, solely because of the additional space/bandwidth required on the
mirrors (not just mirrors controlled by the Project, but third-party
mirrors as well).

I am working on splitting out how the memstick.img and disc1.iso images
are produced, but ran into a problem which I'm looking into a workaround
that is backwards-compatible.  Since for USB images, a 700MB limit does
not make sense, and right now it just so happens that the memstick.img
is created from the same contents of disc1.iso.

I know this does not help with the immediate issue, but wanted to chime
in with I do see and understand the larger issue, and am working on
a more long-term resolution instead of a one-line workaround.

Glen