> It's `namebuf` in mkfile (cmd/hare/plan.ha:312) being called from
> `sched_hare_object` in cmd/hare/schedule.ha:229

That was it! Thanks everybody :D

Hi, I'm trying to build a hare module deeply nested within an existing
mixed hare and C project and encountering the following error:

`Abort: ./bufio/memstream.ha:65:22: bufio::fixed buffer exceeded`

user.ha:
│ use targets::socs::allwinner;
│ //use targets::socs::allwinne;
│ ...
└ let number: size = allwinner::test;

targets/socs/allwinner/todo.ha:
│ export def test: size = 42;
└

---
 docs/hare.scd | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/docs/hare.scd b/docs/hare.scd
index 1b8196e2..3003951d 100644
--- a/docs/hare.scd
+++ b/docs/hare.scd
@@ -92,7 +92,8 @@ value, and optional context, separated by tabs.
 	linker flags.
 
 	Note: use of *-l* currently implies the build tag *libc*. Use *-T -libc* to
-	override this behavior. See *CUSTOMIZING BUILD TAGS*.
+	override this behavior. See *CUSTOMIZING BUILD TAGS*. Furthermore, combining
[message trimmed]

---
 docs/hare.scd | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/docs/hare.scd b/docs/hare.scd
index ba23eb25..1b8196e2 100644
--- a/docs/hare.scd
+++ b/docs/hare.scd
@@ -91,6 +91,9 @@ value, and optional context, separated by tabs.
 	*pkg-config --libs* (see *pkg-config*(1)) to obtain the appropriate
 	linker flags.
 
+	Note: use of *-l* currently implies the build tag *libc*. Use *-T -libc* to
+	override this behavior. See *CUSTOMIZING BUILD TAGS*.
[message trimmed]

👍

Lassi: thanks for the thorough response!

> the presence of -l flags is used as a heuristic to select which linker
> and tags to use.
That makes enough sense. This probably fixes more builds than it breaks
at this point.

> It would probably make sense to add a flag to disable this behavior,
> or maybe only enable it when -lc is used

Or maybe a notice about this in the man page section for the -l flag?
I'm happy to submit a patch for that!

Drew: yeah I've steered clear of linking with libc (-lc, -l:libc.a, etc)

Hi,

I've encountered some behavior surprising to me while playing around 
with some basic mixing of hare, C, and cross-compilation. I'm writing to
ask for each of these two surprises:
	1. Have I done something wrong / missed something in a man page?
	2. Does this look like a hare issue, gcc issue, or qbe issue?

# Setup
I'm on x86_64 Alpine Edge with the master branches of harec, hare, and 
qbe. The only interesting difference is: I'm using aarch64-none-elf-gcc
for cross compiling. I have edited config.mk to reflect this:

```Makefile

---
 src/main.ha | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/main.ha b/src/main.ha
index ae42c2a..9365d99 100644
--- a/src/main.ha
+++ b/src/main.ha
@@ -402,8 +402,11 @@ fn find_do_file(target: str) (do_paths | void | errors::overflow) = {
 		};
 		path::add(&dobuf, "..")!;
 		const pathseg = path::basename(&dobuf);
+
 		if (pathseg == "/") break;
[message trimmed]

I spoke too soon here:
> A cursory skim over src/main.ha didn't trigger any red-flags for me, 
> but if you also suspect this to be a bug then I'd love to try and 
> find+patch it!

I think I found it!

src/main.ha:415 Is reading and writing from targetbuf at the same time.

Patch in progress...
-RKL

First: Hi, thanks for making haredo!

I'm trying out haredo, migrating a Makefile project to haredo and I may
have encountered a bug while replicating the segregated build/ layout.

https://git.sr.ht/~roselandgoose/kyu

Context:
I like being able to have the 'clean' task and .gitignore be as simple as
`rm -r build/`, so I have my Makefiles live next to their source files
but targetting build/$file.c.o for example.

Problem:
I have a default.do file that is called for a build/$file.o target, but