Re: [Xen-devel] [PATCH 1 of 1 v2] tools: honour --libdir when it is passed to ./configure

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2012-06-20 at 23:51 +0100, Matt Wilson wrote:
> Currently shared libraries are automatically installed into /usr/lib
> or /usr/lib64, depending on the supplied --prefix value and
> $(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
> do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
> 
> With this change, packagers can supply the desired location for shared
> libraries on the ./configure command line. Packagers need to note that
> the default behaviour on 64-bit Linux systems will be to install shared
> libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
> to ./configure.
> 
> Additionally, the libfsimage plugins are now loaded explicitly from
> $LIBDIR/fs, removing platform-based decision trees in code.
> 
> Signed-off-by: Matt Wilson <msw@xxxxxxxxxx>
> 
> diff -r 32034d1914a6 -r 4ba90ad04596 Config.mk
> --- a/Config.mk       Thu Jun 07 19:46:57 2012 +0100
> +++ b/Config.mk       Wed Jun 20 00:40:15 2012 +0000
> @@ -43,6 +43,7 @@ endif
>  
>  include $(XEN_ROOT)/config/$(XEN_OS).mk
>  include $(XEN_ROOT)/config/$(XEN_TARGET_ARCH).mk
> +include $(XEN_ROOT)/config/Tools.mk

Unfortunately this won't work, our policy is that you only need to
invoke configure in order to build the tools -- so the top-level
Config.mk cannot include configure generated files.

>  
>  SHAREDIR    ?= $(PREFIX)/share
>  DOCDIR      ?= $(SHAREDIR)/doc/xen
> @@ -67,7 +68,7 @@ endef
>  
>  ifneq ($(EXTRA_PREFIX),)
>  EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
> -EXTRA_LIB += $(EXTRA_PREFIX)/$(LIBLEAFDIR)
> +EXTRA_LIB += $(EXTRA_PREFIX)/$(shell basename $(LIBDIR))

since we are sort of reverting 16950:0faf620bc749 here this could in
theory $(EXTRA_PREFIX)/$(LIBDIR)? That doesn't remove the need to
include Tools.mk though. :-/

Does anyone know if this EXTRA_PREFIX stuff is intended to be used for
hypervisor and other non-tools builds? If not then we could consider
pushing it down a level.

In the tools case I think we already have a way to inject arbitrary -L
and -I options -- so maybe this can just go away?

CCing Ian (who wrote 16950) and Olaf, whose been doing stuff in this
area.

> diff -r 32034d1914a6 -r 4ba90ad04596 config/StdGNU.mk
> --- a/config/StdGNU.mk        Thu Jun 07 19:46:57 2012 +0100
> +++ b/config/StdGNU.mk        Wed Jun 20 00:40:15 2012 +0000
> @@ -32,13 +32,7 @@ INSTALL_PROG = $(INSTALL) -m0755 -p
>  PREFIX ?= /usr
>  BINDIR = $(PREFIX)/bin
>  INCLUDEDIR = $(PREFIX)/include
> -LIBLEAFDIR = lib
> -LIBLEAFDIR_x86_32 = lib
> -LIBLEAFDIR_x86_64 ?= lib64
> -LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
> -LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
> -LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)
> -LIBEXEC = $(LIBDIR_x86_32)/xen/bin
> +LIBEXEC = $(PREFIX)/lib/xen/bin

Wouldn't this be $(LIBDIR)/xen/bin ?

I suppose configure defines a libexec but it isn't the one we want?

> @@ -131,27 +130,12 @@ static int load_plugins(void)
>       int err;
>       int ret = -1;
>  
> -#if defined(FSIMAGE_FSDIR)
> +#if !defined(FSIMAGE_FSDIR)
> +#error FSIMAGE_FSDIR not defined

FWIW I'd be happy with the regular message you get from using an
undefined symbol, if you want to ditch this #error.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel