Le 16/02/2013 15:22, Jeff Squyres (jsquyres) a écrit :
> 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).
I can't find the URL of the main RHEL6 RPM repo, but
contains a RPM spec file that says they build libpciaccess-devel
libpciaccess-devel is needed to build X.org. Building it and using it
for other builds and then dropping it instead of distributing it looks
like non-sense to me.
>> If we add the upstream URL for all packages that are not available by
>> default, we need one for libxml-devel and numactl-devel too since devel
>> headers are rarely installed by default.
>> In brief, just remove that URL :)
> Since this is a GPL taint issue, and since PCI support is pretty important, I think it's worth listing that URL -- especially since the first hit for googling libpciaccess reveals developer tarballs (http://cgit.freedesktop.org/xorg/lib/libpciaccess/), not official release tarballs (e.g., http://lists.x.org/archives/xorg-announce/2012-March/001845.html)
> So having this URL *somewhere* would be a good idea, IMHO.
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
>>> +<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>
>> 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
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 :/