[2/4] Allow make-link-multidir to make subdirectories

  The RISC-V Linux ABI doesn't define any libraries that go directly in
lib, instead they go into lib/ilp32 or lib/lp64.  This casuse
make-link-multidir to fail when attempting to make library directories
when building a static libc on multilib RISC-V systems.

This patch uses scripts/mkinstalldirs to make the base directory of the
target symlink of make-link-multidir.
---
 ChangeLog | 4 +++-
 Makerules | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)
  

On Sat, Jan 6, 2018 at 2:32 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> The RISC-V Linux ABI doesn't define any libraries that go directly in
> lib, instead they go into lib/ilp32 or lib/lp64.

Why did you invent a new convention for this, instead of using the
existing lib{32,64} or lib/<target-triple> conventions?

zw
  

On Sat, 06 Jan 2018 07:04:45 PST (-0800), zackw@panix.com wrote:
> On Sat, Jan 6, 2018 at 2:32 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> The RISC-V Linux ABI doesn't define any libraries that go directly in
>> lib, instead they go into lib/ilp32 or lib/lp64.
>
> Why did you invent a new convention for this, instead of using the
> existing lib{32,64} or lib/<target-triple> conventions?

Sorry, the message was a bit truncated.  We currently install libraries in the 
following directories:

* lib32/ilp32: RV32 (the 32-bit ISA), with the 32-bit soft float ABI
* lib32/ilp32d: RV32, with the 32-bit hard float ABI
* lib64/lp64: RV64 (the 64-bit ISA), with the 64-bit soft float ABI
* lib64/lp64d: RV64, 64-bit hard float

we plan on eventually also supporting lib64/ilp32 and lib64/ilp32d (x32-style 
ABIs).

The convention is slightly different because we wanted thing regular: we could 
have picked something like "lib32" and "lib32/softfloat" (IIRC ARM does this), 
but it seemed better to make thing orthogonal.
  

On Fri, 5 Jan 2018, Palmer Dabbelt wrote:

> diff --git a/Makerules b/Makerules
> index d94e4ca0c18f..ef6abeac6d9d 100644
> --- a/Makerules
> +++ b/Makerules
> @@ -1081,6 +1081,7 @@ mv -f $@.new $@
>  endef
>  define make-link-multidir
>  $(patsubst %/,cd %,$(objpfx)); \
> +  $(addprefix $(abspath $(..)scripts/mkinstalldirs) ,$(dir $(multidir))); \
>    $(LN_S) . $(multidir) 2> /dev/null; \
>    test -L $(multidir)
>  endef

This doesn't actually achieve the desired effect.

That is, it stops the build from failing.  But the point of HJ's commit 
abcb584d0eae7270b35e1b3fed1f9661e26b8be0 was that multidir ends up as a 
symlink pointing to the csu object directory containing crt*.o.  When 
there are multiple subdirectory levels involved, you're still creating a 
symlink to ".", which is just the subdirectory one level up; you need a 
symlink that actually points to the csu object directory, however many 
levels up it might be.  So presumably the "wrong" (previously built) 
crt*.o could get used in some cases for building shared libraries.

(I think the case of no ln -s support gets this right, though I haven't 
tested that case.)