[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |