Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 Nov 2012 12:03:41 -0800
From: Isaac Dunham <>
Subject: Re: Design idea for subarchs/abivariants

On Wed, 28 Nov 2012 14:26:18 -0500
Rich Felker <> wrote:

> The problem: how to have subarch variants on the bits headers and asm
> for a given arch without ugly build system complications or massive
> duplication of files.
> Proposed solution:
> 1. $(ARCH)$(SUBARCH)/%.s is searched in addition to $(ARCH)/%.s for
> arch-specific files replacing general %.c files in the src tree. This
> would allow src/fenv/arm-hf/%.s and src/setjmp/mips-sf/%.s files, for
> example.

> 2. Making bits/endian.h, bits/fenv.h, and any other bits headers that
> need to vary per-subarch into generated headers. 
> 3. Having configure derive separate $(ARCH), $(ENDIAN), and $(SUBARCH)
> from the gcc-style machine strings or combined musl-format arch string.
> Comments?
Seems fairly clean to me, though I'd been thinking of a variant of 1: $(ARCH)/$(SUBARCH)/%.s (on the premise that anything that gets used for an arch should be in one place).
But now that I think about it, I'm not certain that's a meaningful advantage, and with your approach, */<file>.s is going to get every appropriate file.

By the way, while we're on the makefile:
in the past, I've run into issues with cycles like:
<forget to check for builds>
git pull # or git checkout ....
make clean # doesn't handle files that were moved/deleted
make # link breaks, due to remaining oject files

I usually do this to cleanup in such cases: 
find src arch -name '*.*o' |xargs rm
Would adding some similar logic be sensible (at least for the distclean target)?

Isaac Dunham <>

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.