On Wed, Dec 12, 2007 at 11:48:53AM -0500, Mike Frysinger wrote:
> On Wednesday 12 December 2007, Stepan Kasal wrote:
> > On Tue, Dec 11, 2007 at 05:54:11PM -0500, Mike Frysinger wrote:
> > > [...] you should use AC_PATH_TOOL [...]
> > A small question remains: why full path? wouldn't AC_CHECK_TOOL suffice?
>
> the purpose of using AC_CHECK_TOOL is not for the full path. AC_CHECK_TOOL
> provides two things:
Yes, I see. That's how you have convinced me that AC_CHECK_TOOL or
AC_PATH_TOOL is necessary.
But PKG_PROG_PKG_CONFIG uses AC_PATH_TOOL. My question is whether
there is any reason to use the _PATH_ variant instead of the _CHECK_
one. I cannot see any reason why _PATH_ is needed.
OTOH it is not a big issue, so I can happily use PKG_PROG_PKG_CONFIG.
> > > > : ${BLKID_LIBS='-lblkid'}
> > > > : ${VOLUMEID_LIBS='-lvolume_id'}
...
> again, it probably will work in most cases, but in the cases where it wont,
> there's no way for the user to control it without editing the configure
> script.
Not true. "./configure BLKID_LIBS="whatever" overrides the default
values used in the code, as quoted above. (But, as I said in the
other mail, this is only a theoretical discussion now.)
> > Until the blkid.pc is fixed (s/Requires/&.private/), the pkg-config
> > version of BLKID_LIBS is even slightly worse than the fixed
> > "-lblkid". (The build won't fail, but the binaries will have
> > unneeded DT_NEEDED tags.)
>
> is this really a big deal ?
Well, in general unneeded DT_NEEDED tags can add up to a big problem.
I mentioned an example where is could lead to a need to quicly
recompile half of Debian, and they really percpeted it as a big pain
back than. (See the first mail of thread "Beware pkg-config --libs"
in this list.)
But because there is high probability that blkid.pc and
libvolume_id.pc will be fixed really soon, I can suppose it's not
a big problem in this particular case.
Stay tuned for a next iteration of my patches.
Have a nice day,
Stepan
-
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
