Re: [xml] (Broken) multi-arch support in xml2-config

On Wed, Nov 07, 2012 at 03:49:47PM -0500, Daniel Richard G. wrote:
I noticed that this bit was added about a month ago to

      if [ "`ldd /bin/sh | grep lib64`" = "" ]

This caused a subsequent build of LibXSLT to fail, because the
needed library was under $prefix/lib/, and the build system was
looking under $prefix/lib64/.

I'm not seeing why this code is there.

  Because I had that patch for years and years on Fedora and RHEL builds
and it was looking to me that this should not be a problem for others.
Apparently it is :-\

There are multiple problems
with this approach:

* Custom libdir values specified at configure time (i.e. --libdir=blah)
  are ignored in favor of the common-case default

* The lib64 subdir, if returned, is returned solely based on how /bin/sh
  is linked---rather than whether "make install" actually puts the library
  there or not

* As written, there isn't even a way to request an architecture explicitly
  if more than one is installed (something like --lib32/--lib64 options or

* "lib" versus "lib64" isn't the only possible distinction, either; my
  64-bit Ubuntu system, for example, has /usr/lib/ and /usr/lib32/.

* The "foo-config" script mechanism, to the degree that it can work in a
  multi-arch scenario, works a lot more cleanly when you have one instance
  of the script per architecture (rather than one script handling multiple
  architectures). All I would do then is set my PATH appropriately, e.g.




  when LibXML2 is installed for both amd64 and i386 under /usr/arch/.

What was the motivation for trying to shoehorn multi-arch support
into xml2-config?

  Avoid keeping a distro specific patch, assuming it would work
elsewhere. What is your suggestion, removal or fixing ?


Daniel Veillard      | Open Source and Standards, Red Hat
veillard redhat com  | libxml Gnome XML XSLT toolkit | virtualization library

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