On Sat, 17 Nov 2001, Peter Eisentraut wrote:
> Bill Studenmund writes:
>
> > The problem I had with AC_SEARCH_LIBS was that if I don't add all of the
> > libraries (-lasn1 -lroken etc.) the test program won't compile, even
> > though the .o compiles fine. Can we make the test only depend on
> > generating a .o?
>
> That wouldn't tell you a whole lot about the existence of a function. You
> do need to link to be able to verify that.
The thought was that the existance of the symbol (not function)
__heimdal_version is an easy way to tell which version is in use.
> > I'd like to make it a bug fix for 7.2 if we can, so I'd appreciate the
> > help. I can test any new versions of the patch. :-)
>
> The attached patch should handle the different struct members (at least it
> doesn't break them for me) and it doesn't gratuitously fail on libraries
> that are not really needed. I haven't done anything about -lasn1 -lroken
> -lcrypto because I'd need to know what functions you need from there. You
> should be able to get it to work when you configure thus:
Well, the real problem is that libkrb5 needs these libraries. More
importantly, the tests to see if libkrb5 is ok need them. :-)
> $ LIBS='-lasn1 -lroken -lcrypto' ./configure --with-krb5 ...other options...
Unfortunatly that won't work as libasn1 needs libcom_err. So the above
line complains that gcc is broken. :-(
So what needs to happen is that libasn1, libroken, and libcrypto need to
be looked for part way through the kerberos tests, if we have heimdal. If
we have MIT, we shouldn't look for them.
Well, more to the point, not having working libasn1 and libroken is only a
problem for heimdal; it's an ok state of affairs for MIT kerberos.
Thoughts?
> If you can confirm that this patch works I can check it in so it appears
> in whatever beta3+1 is going to be. However, be aware that we're
> approaching the first release candidate, and since this issue doesn't
> represent a regression from 7.1 it's not going to hold up the release.
I understand.
Take care,
Bill
