Install DragonFlyBSD on 32 MB RAM

[Chris Turner]

On 03/06/12 05:24, v_2e at ukr.net wrote:
> On Mon, 05 Mar 2012 23:28:59 -0800
 >
> But maybe it is worth fixing this page:
>
>      http://www.dragonflybsd.org/docs/newhandbook/pkgsrc/#index7h3
>
> as well, because that was the place where I learned about the
> '/etc/mk.conf/ file?

Fixed - thanks for the report. Pkgsrc used to default to /etc/mk.conf
a while ago but now uses /usr/pkg/etc/mk.conf. The documentation
wasn't yet updated.

>    By the way, is it a good idea to disable the "threads' option when
> building the applications on the machine with such a small amount of
> memory as mine has? I'm not sure about the exact meaning of this option
> - where can I get any description of it (as well as any other options)?

Generally I wouldn't mess with the options unless you're 100% sure
you want to disable it. To find out what it does, check the Makefile
or options.mk file in the package directory and if it's not well
documented, you'll need to see how the options affect the build
process and dig in the package's source to see what this implies.

The pkgsrc guide is quite good:

http://www.netbsd.org/docs/pkgsrc/

and aside from this and the makefiles, perhaps check the CVS history.

see also: http://pkgsrc.se for a nice web interface

> And also, the question about kernel build failure remains - I would
> appreciate any input on that case as well.

Can you build GENERIC with a stock /etc/make.conf?

If not, checkout a fresh source tree & try a clean build.

if so - you'll need to be making your kernel config file
available and any build flags used if you want someone to try
to fix.

This particular error looks to be related to changing the
VISUAL_USERCONFIG and can be found fairly simply by checking
the file in question at the line where the build fails -
the entire function is ifdef'ed out based on this option..
so - looks like this option is required most likely (I'm not 100%)

Really - if you're making a custom kernel config and are changing
options without checking what they do in the source tree - expect
things to fail both in the build and while running, and expect to
get your hands dirty - which means reading the source and finding
out what the options do to the code.

In other words - by continuing down the (unsupported) low memory path,
with a custom kernel config, you've essentially become the
'low memory tester / developer' - and so will need to do
'tester/developer like things' if you want to make progress..

Hope this doesn't come across too harshly - the goal isn't
to yell but to try and describe what I think is the reality on
this thread for whatever that's worth.

Cheers & good luck!

- Chris