Re: [PATCH] build-sys: use pkg-config to find the libs for static build

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

 



On Wednesday 12 December 2007, Stepan Kasal wrote:
> 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.

erp, you're right ... i missed the PATH/CHECK difference in your e-mail.  
AC_CHECK_TOOL should be fine as you're right we dont care about the full 
path.

> OTOH it is not a big issue, so I can happily use PKG_PROG_PKG_CONFIG.

that works for me as well :)

> > > > >  : ${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.)

ah you're right of course, manually intervention is allowed

> > > 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.

what i meant was, historically DT_NEEDED over population would occur, but 
moving down in time as fixed versions of those packages are released, this 
gets addressed.  so having us track the issue when it really isnt a big deal 
to start with doesnt seem like it is worthwhile.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux