Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 17 Nov 2015 21:37:37 +0000
From: Petr Hosek <>
Subject: Re: Support for out-of-tree build

How would you express the fact that e.g. armhf subarch should use armel
implementation of memcpy.s?

On Tue, Nov 17, 2015 at 1:00 PM Rich Felker <> wrote:

> On Tue, Nov 17, 2015 at 02:45:58AM +0000, Petr Hosek wrote:
> > This is the final solution I've converged to. It's a bigger change than
> the
> > previous version, but the implementation is actually cleaner. In
> nutshell,
> > I've replaced all .sub files with .mk equivalent files which are included
> > from the Makefile. I'm then filtering out all C object files which have
> > assembly equivalent. This allowed me to simplify the build rules while we
> > still support both in-tree and out-of-tree builds. Please let me know
> what
> > you think, I'll be happy to iterate on this.
> What I had in mind was something more like a single fragment for the
> arch containing something like (example on sh with 3 subarch
> dimensions, where full arch with subarch is sheb-nofpu-fdpic):
> %.o: sheb/%.s
>         $(AS_CMD)
> %.o: sh-nofpu/%.s
>         $(AS_CMD)
> %.o: sh-fdpic/%.s
>         $(AS_CMD)
> Even better would be just an ordered list of subarch subdirs that the
> top-level makefile can interpret:
> SUBARCH_ASM_DIRS = sheb sh-nofpu sh-fdpic
> Replacing *.sub with *.mk is not an improvement from my perspective;
> rather, it's replacing N files which just contained one piece of data
> (a filename) with N files each coupled with the makefile logic.
> Rich

Content of type "text/html" skipped

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.