On Feb 16, 2013, at 9:43 AM, Brice Goglin <brice.gog...@inria.fr> wrote:
>> No, it's not. RHEL6, for example, does have libpciaccess, but does not >> have a libpciaccess-dev (or devel). > > Are you sure? CentOS 6.3 has it (Ubuntu, Debian and OpenSuse too). Per your second mail, I guess I was wrong about that. > It all depends on RHEL6 shipping the -devel or not. If -devel is widely > available as a package, the situation is exactly like libxml2-devel or > numactl-devel Hmm. It looks like numactl and numactl-devel are on my main RHEL6 DVD. But only libpciaccess -- not libpciaccess-devel -- is on my main RHEL6 DVD. Here's checking all the RHEL6 DVD iso's that I have: ----- [8:52] savbu-usnic-a:~/downloads % cat check-rhel.csh #!/bin/csh foreach iso (`ls rhel-server*.iso`) mount -o ro,loop $iso /mnt echo === $iso find /mnt | grep pciaccess umount /mnt end [8:52] savbu-usnic-a:~/downloads % sudo ./check-rhel.csh === rhel-server-6.0-source-dvd1.iso === rhel-server-6.0-source-dvd2.iso /mnt/SRPMS/libpciaccess-0.10.9-2.el6.src.rpm === rhel-server-6.0-x86_64-boot.iso === rhel-server-6.0-x86_64-dvd.iso /mnt/Packages/libpciaccess-0.10.9-2.el6.i686.rpm /mnt/Packages/libpciaccess-0.10.9-2.el6.x86_64.rpm === rhel-server-6.1-x86_64-boot.iso === rhel-server-6.1-x86_64-dvd.iso /mnt/Packages/libpciaccess-0.10.9-4.el6.i686.rpm /mnt/Packages/libpciaccess-0.10.9-4.el6.x86_64.rpm === rhel-server-6.2-x86_64-boot.iso === rhel-server-6.2-x86_64-dvd.iso /mnt/Packages/libpciaccess-0.12.1-1.el6.i686.rpm /mnt/Packages/libpciaccess-0.12.1-1.el6.x86_64.rpm === rhel-server-6.3-x86_64-boot.iso === rhel-server-6.3-x86_64-dvd.iso /mnt/Packages/libpciaccess-0.12.1-1.el6.i686.rpm /mnt/Packages/libpciaccess-0.12.1-1.el6.x86_64.rpm [8:52] savbu-usnic-a:~/downloads % ----- Looking inside the spec file in the SRPM, I see that it builds a devel RPM, but I don't see that devel package anywhere on the RHEL6 DVDs. Are there RHEL6 DVD's other than the boot DVD and the main DVD? >>>> + >>>> +<li>pciutils (libpci). The relevant development package is usually >>>> +<tt>pciutils-devel</tt> or <tt>libpci-dev</tt>. Unfortunately, while >>>> +the libpci library from the pciutils package is pre-installed (or >>>> +readily available) on many platforms, it is licensed under the GPL. >>>> +Hence, if hwloc is configured to build/link against libpci, the hwloc >>>> +library and binaries will be tainted with GPL (<strong>this has >>>> +serious implications for 3rd parties developing tools that link >>>> +against libhwloc!</strong>)</li> >>>> +</ol> >>>> </li> >>>> + >>>> >>> This text is way too long. That section about dependencies was meant to >>> be easy to read before a first manual build of hwloc, that's why it's >>> a small list of short items. You're adding half a page about libpci in the >>> middle, making it hard to read. That long discussion can move somewhere >>> else, I'd say a FAQ entry at the end of doxy. >> I can see moving it out of this short list, but something like it should >> stay within the installation section. > > Move it to the end of that section then, right after the small list of > dependencies? Sounds good. > We just have to make sure that "GPL" appears nearby each occurence of > --enable-libpci. But that won't ever prevent bad users from enabling it > without reading the doc. If they don't read configure --help or the doc > before adding --enable-libpci, they won't read you 20 lines about the > GPL issue :/ But you might well notice it in boldfaced text in the PDF when figuring out how to install PCI support (because you didn't get it by default). :-) -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
