[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] tools: don't expand prefix and exec_prefix too early



On Wed, 2012-08-08 at 15:52 +0100, Jan Beulich wrote:
> >>> On 08.08.12 at 16:45, Matt Wilson <msw@xxxxxxxxxx> wrote:
> > On Wed, Aug 08, 2012 at 07:39:13AM -0700, Jan Beulich wrote:
> >> >>> On 08.08.12 at 16:26, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> >> > A comment in tools/configure says that it is intended for these to be
> >> > command line overridable, so they shouldn't get expanded at configure
> >> > time.
> >> 
> >> In addition, it would have been _very_ nice if it had been
> >> prominently announced that with (I believe) 25594:ad08cd8e7097
> >>
> >> it is now _required_ to configure with --libdir on x86-64, or else all
> >> the .so-s end up under /usr/lib. Figuring this out and getting the
> >> patch here in the right form to be able to use the most compatible
> >> form --libdir='${exec_prefix}'/lib64 has taken me a good part of
> >> the day, which could have been avoided if this whole configure
> >> adjustment (much like had apparently been missing already in
> >> earlier cases) had been done properly. I just can't imagine I'm
> >> the only one having used no options at all, and things working
> >> nevertheless despite .../lib not being in the library search paths
> >> used when running xl et al.
> > 
> > I'm sorry for the trouble it cause you today, Jan. I thought I called
> > it out sufficiently in the commit log:
> > 
> >     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.
> 
> No, this comment says "can", not "have to". Plus you don't really
> expect people to read every changeset's description, do you?
> 
> > The new behavior is consistent with all packages that use autoconf.
> 
> That indeed appears to be the case, admittedly to my not
> insignificant surprise.
> 
> > Would a separate email on the topic to xen-devel, apart from the patch
> > discussion, have helped raise awareness?
> 
> Yes. I for my part follow only very selected tools side discussions,
> and expect the tools maintainers to get things sorted out. But of
> course I need to build and run the tools, so if some change gets
> done to the way things need to get built (or run) successfully
> then announcing this independently of the patch would certainly
> be helpful in general.

FWIW I've just added it http://wiki.xen.org/wiki/Xen_4.2_Release_Notes
which probably wouldn't have helped you but should help in general.

Ian.



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.