Re: Re: patch to fix configure(.in) on openbsd wrt/ krb5/com_err and readline linking

On Wed, Jun 10, 2009 at 4:32 PM, Simon Bertrang<janus(at)errornet(dot)de> wrote:
> On Wed, Jun 10, 2009 at 05:20:00PM +0200, Simon Bertrang wrote:
>> On Wed, Jun 10, 2009 at 10:05:36AM -0400, Tom Lane wrote:
>> > Greg Stark <stark(at)enterprisedb(dot)com> writes:
>> > > This seems really weird. Firstly, doesn't OpenBSD use ELF? Shouldn't
>> > > the library pull in the indirectly needed libraries automatically? But
>> > > more to the point, why on *earth* would com_err depend on -lssl and
>> > > -lcrypto? com_err is just a standard error handling library.  Why
>> > > would it fail to link without ssl and crypto libraries?!?!
>> >
>> > And you'd also need to explain why the spoonbill buildfarm member
>> > is building just fine without this ... it does have kerberos
>> > enabled ...
>> >
>>
>> Indeed a good question.  I'm comparing the config and build logs but
>> nothing jumped into my face yet.  I should fire up my sparc64 to have the
>> same arch as spoonbill for comparison...  configure flags differ too...
>> i'll let you know when i found out more.
>>
>
> Found it: spillboon has --with-gssapi in configure flags which pulls the
> missing pieces in.  We don't build with GSSAPI enabled though, hence the
> patch.

That just raises the same question though. Why are we having to
explicitly list the dependencies on an ELF platform? Why are your
libraries missing the "NEEDED" entries that should make this just work
automatically?

And incidentally this explanation implies that the patch doesn't need
-lssl since there's no -lssl in the gss configure line either. It
looks like -lcrypto was all that was needed here. Which makes sense
since otherwise the krb5 test would also be broken.

Finally do you happen to know which other BSD flavours use the same
linker option to strip unused symbols? I assume OpenBSD didn't write
their own linker and suspect you're using the same one as any other
variant that hasn't switched to GNU ld or some other toolchain.

--
Gregory Stark
http://mit.edu/~gsstark/resume.pdf