On 11/21/12 11:37 PM, Murray S. Kucherawy wrote:
> On Wed, 21 Nov 2012, Eray Aslan wrote:
> It's not odd if you don't intend to have others use the installed
> library. But either way, since 2.7.0, we have installed a strl.h in a
> subdirectory called "strl" inside whatever the configured include
> directory is. On my test system it's in /usr/local/include/strl/strl.h.
<strl/strl.h> on mine. Missed it somehow. Bah.
> Why would we not link against an older version of our own library? In
> fact, as of now at least, they're codewise identical.
For future proofing. If you are sure that the interface won't change,
then go ahead and link against it. It just did not feel right.
> That's basically what I suggested below: If strl.h and strlcat/strlcpy
> are not all available, build our own static one, link against that, and
> never install it. Then it doesn't matter what the rest of the system
> has or doesn't have, and we don't leave any files on the system that
> have anything to do with this issue.
Yes agreed.
> It's possible the error is simply that we aren't adding a check for
> strl.h in the aforementioned subdirectory. If you do a "find" to locate
> it and then add CPPFLAGS=-I<that-location> to your ./configure command,
> does the warning go away?
Can't try at the moment but yes the warning should go away. Sorry, I
missed the strl/strl.h header.
[...]
> Unless you mean don't try to link against the system's libstrl if strl.h
> is not installed, and use our own. That's possible, of course, but it
> shouldn't be necessary.
Yes, that was what I meant.
[...]
> Why? Since there have been no changes to the library itself, the output
> library is identical.
No changes so far to the library but maybe in the future. But this is
not a library that will change its API frequently, if ever. So up to
you. As I said, linking against our older version just does not seem right.
--
Eray
Received on Wed Nov 21 2012 - 22:40:52 PST