From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Warren <swarren@wwwdotorg.org>
Date: Thu, 27 Feb 2014 10:07:29 -0700
Subject: [U-Boot] [PATCH 2/4] kbuild: add CONFIG_ prefix to
	USE_PRIVATE_LIBS
In-Reply-To: <1393511304-9432-3-git-send-email-yamada.m@jp.panasonic.com>
References: <1393511304-9432-1-git-send-email-yamada.m@jp.panasonic.com>
	<1393511304-9432-3-git-send-email-yamada.m@jp.panasonic.com>
Message-ID: <530F70D1.9040803@wwwdotorg.org>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 02/27/2014 07:28 AM, Masahiro Yamada wrote:
> Before this commit, USE_PRIVATE_LIBS is defined in
> arch-specific config.mk and referenced in
> arch/$(ARCH)/lib/Makefile.

I think you need to s/USE_PRIVATE_LIBS/USE_PRIVATE_LIBGCC/ throughout
the patch subject and description. With that change,

Acked-by: Stephen Warren <swarren@nvidia.com>

> diff --git a/Makefile b/Makefile
....
> +ifdef CONFIG_USE_PRIVATE_LIBGCC
> +ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y)
>  PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a
>  else
> +PLATFORM_LIBGCC = -L $(CONFIG_USE_PRIVATE_LIBGCC) -lgcc
>  endif
>  else

Here, it seems that CONFIG_USE_PRIVATE_LIBGCC can be (a) unset (b) set
to y, (c) set to a specific library path name.

> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile

> +lib-$(CONFIG_USE_PRIVATE_LIBGCC) += _ashldi3.o _ashrdi3.o _divsi3.o \
> +			_lshrdi3.o _modsi3.o _udivsi3.o _umodsi3.o div0.o

In case (c) above, that will set variable lib-$(the_library_path_name).
I guess that variable simply won't be used, so that's OK, assuming that
the path name doesn't contain any characters that are illegal as a make
variable name. That's probably true though.

> diff --git a/spl/Makefile b/spl/Makefile

>  # Add GCC lib
> +ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y)
>  PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a
>  PLATFORM_LIBS := $(filter-out %/lib.a, $(filter-out -lgcc, $(PLATFORM_LIBS))) $(PLATFORM_LIBGCC)
>  endif

Should the SPL code here also handle case (c) above? I suppose that's a
pre-existing issue, and not related to this patch though, so feel free
to ignore it.