Thread: patch to fix configure(.in) on openbsd wrt/ krb5/com_err and readline linking
patch to fix configure(.in) on openbsd wrt/ krb5/com_err and readline linking
From
Simon Bertrang
Date:
Hi,
the following patch does two things on OpenBSD:
1) Add missing libs to the krb5/com_err check that are required.
We have this in our ports tree since 7.4.3 but i can't find any
report about it, so here it finally is.
2) Prevent the use of -Wl,--as-needed in the readline case but use
-Wl,-Bdynamic instead. This became necessary with 8.4, otherwise
psql won't start because lazy binding fails.
The good news though is that i'm running 8.4beta2 successfully on
-current OpenBSD/amd64 with this.
Kind regards,
Simon
Index: configure.in
===================================================================
RCS file: /projects/cvsroot/pgsql/configure.in,v
retrieving revision 1.597
diff -u -p -r1.597 configure.in
--- configure.in 19 May 2009 22:32:41 -0000 1.597
+++ configure.in 10 Jun 2009 09:14:20 -0000
@@ -913,8 +913,13 @@ fi
if test "$with_krb5" = yes ; then
if test "$PORTNAME" != "win32"; then
- AC_SEARCH_LIBS(com_err, [krb5 'krb5 -lcrypto -ldes -lasn1 -lroken' com_err], [],
- [AC_MSG_ERROR([could not find function 'com_err' required for Kerberos 5])])
+ if test "$PORTNAME" = "openbsd"; then
+ AC_SEARCH_LIBS(com_err, [krb5 'krb5 -lcrypto -ldes -lasn1 -lroken' 'com_err -lssl -lcrypto'], [],
+ [AC_MSG_ERROR([could not find function 'com_err' required for Kerberos 5])])
+ else
+ AC_SEARCH_LIBS(com_err, [krb5 'krb5 -lcrypto -ldes -lasn1 -lroken' com_err], [],
+ [AC_MSG_ERROR([could not find function 'com_err' required for Kerberos 5])])
+ fi
AC_SEARCH_LIBS(krb5_sendauth, [krb5 'krb5 -lcrypto -ldes -lasn1 -lroken'], [],
[AC_MSG_ERROR([could not find function 'krb5_sendauth' required for Kerberos 5])])
else
@@ -1788,7 +1793,9 @@ if test "$with_readline" = yes; then
else
link_test_func=exit
fi
-if test "$PORTNAME" != "darwin"; then
+if test "$PORTNAME" = "openbsd"; then
+ PGAC_PROG_CC_LDFLAGS_OPT([-Wl,-Bdynamic], $link_test_func)
+elif test "$PORTNAME" != "darwin"; then
PGAC_PROG_CC_LDFLAGS_OPT([-Wl,--as-needed], $link_test_func)
else
# On Darwin it's spelled -Wl,-dead_strip_dylibs, but don't try that elsewhere
Re: patch to fix configure(.in) on openbsd wrt/ krb5/com_err and readline linking
From
Greg Stark
Date:
On Wed, Jun 10, 2009 at 10:25 AM, Simon Bertrang<janus@errornet.de> wrote: > > the following patch does two things on OpenBSD: Thank you. > =A01) Add missing libs to the krb5/com_err check that are required. > =A0 =A0We have this in our ports tree since 7.4.3 but i can't find any > =A0 =A0report about it, so here it finally is. 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?!?! If it is necessary, putting in an "if portname =3D openbsd" is defeating the whole purpose of using autoconf here. Surely something like =A0 =A0AC_SEARCH_LIBS(com_err, [krb5 'krb5 -lcrypto -ldes -lasn1 -lroken' 'com_err' 'com_err -lssl -lcrypto'], [], would be better since it would detect this situation regardless of what OS it's on. --=20 Gregory Stark http://mit.edu/~gsstark/resume.pdf
Re: Re: patch to fix configure(.in) on openbsd wrt/ krb5/com_err and readline linking
From
Tom Lane
Date:
Greg Stark <stark@enterprisedb.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 ...
regards, tom lane
Re: patch to fix configure(.in) on openbsd wrt/ krb5/com_err and readline linking
From
Simon Bertrang
Date:
On Wed, Jun 10, 2009 at 02:19:30PM +0100, Greg Stark wrote:
> On Wed, Jun 10, 2009 at 10:25 AM, Simon Bertrang<janus@errornet.de> wrote:
> >
> > the following patch does two things on OpenBSD:
>
> Thank you.
>
>
> > 1) Add missing libs to the krb5/com_err check that are required.
> > We have this in our ports tree since 7.4.3 but i can't find any
> > report about it, so here it finally is.
>
> 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?!?!
>
We do use ELF on most arches. Those few who don't, aren't relevant to
the discussion nor a good choice to run a database on.
Anyway, the reason why our com_err depends on libssl and libcrypto is
because it is linked into libkrb5; libcom_err is just a link to libkrb5:
$ ls -il /usr/lib/libkrb5.so.16.0 /usr/lib/libcom_err.so.16.0
1117313 -r--r--r-- 4 root bin 5427316 Apr 18 18:57 /usr/lib/libcom_err.so.16.0
1117313 -r--r--r-- 4 root bin 5427316 Apr 18 18:57 /usr/lib/libkrb5.so.16.0
> If it is necessary, putting in an "if portname = openbsd" is defeating
> the whole purpose of using autoconf here. Surely something like
>
> AC_SEARCH_LIBS(com_err, [krb5 'krb5 -lcrypto -ldes -lasn1 -lroken'
> 'com_err' 'com_err -lssl -lcrypto'], [],
>
> would be better since it would detect this situation regardless of
> what OS it's on.
>
Makes sense to me even though i'm (obviously) no autoconf expert;
updated diff below.
Regards,
Simon
Index: configure.in
===================================================================
RCS file: /projects/cvsroot/pgsql/configure.in,v
retrieving revision 1.597
diff -u -p -r1.597 configure.in
--- configure.in 19 May 2009 22:32:41 -0000 1.597
+++ configure.in 10 Jun 2009 15:04:31 -0000
@@ -913,7 +913,7 @@ fi
if test "$with_krb5" = yes ; then
if test "$PORTNAME" != "win32"; then
- AC_SEARCH_LIBS(com_err, [krb5 'krb5 -lcrypto -ldes -lasn1 -lroken' com_err], [],
+ AC_SEARCH_LIBS(com_err, [krb5 'krb5 -lcrypto -ldes -lasn1 -lroken' com_err 'com_err -lssl -lcrypto'], [],
[AC_MSG_ERROR([could not find function 'com_err' required for Kerberos 5])])
AC_SEARCH_LIBS(krb5_sendauth, [krb5 'krb5 -lcrypto -ldes -lasn1 -lroken'], [],
[AC_MSG_ERROR([could not find function 'krb5_sendauth' required for Kerberos 5])])
@@ -1788,7 +1788,9 @@ if test "$with_readline" = yes; then
else
link_test_func=exit
fi
-if test "$PORTNAME" != "darwin"; then
+if test "$PORTNAME" = "openbsd"; then
+ PGAC_PROG_CC_LDFLAGS_OPT([-Wl,-Bdynamic], $link_test_func)
+elif test "$PORTNAME" != "darwin"; then
PGAC_PROG_CC_LDFLAGS_OPT([-Wl,--as-needed], $link_test_func)
else
# On Darwin it's spelled -Wl,-dead_strip_dylibs, but don't try that elsewhere
Re: patch to fix configure(.in) on openbsd wrt/ krb5/com_err and readline linking
From
Greg Stark
Date:
On Wed, Jun 10, 2009 at 4:07 PM, Simon Bertrang<janus@errornet.de> wrote: > > Anyway, the reason why our com_err depends on libssl and libcrypto is > because it is linked into libkrb5; libcom_err is just a link to libkrb5: > > $ ls -il /usr/lib/libkrb5.so.16.0 /usr/lib/libcom_err.so.16.0 > 1117313 -r--r--r-- =A04 root =A0bin =A05427316 Apr 18 18:57 /usr/lib/libc= om_err.so.16.0 > 1117313 -r--r--r-- =A04 root =A0bin =A05427316 Apr 18 18:57 /usr/lib/libk= rb5.so.16.0 So shouldn't the first option "krb5" have just worked? --=20 Gregory Stark http://mit.edu/~gsstark/resume.pdf
Re: Re: patch to fix configure(.in) on openbsd wrt/ krb5/com_err and readline linking
From
Simon Bertrang
Date:
On Wed, Jun 10, 2009 at 10:05:36AM -0400, Tom Lane wrote: > Greg Stark <stark@enterprisedb.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. Regards, Simon
Re: Re: patch to fix configure(.in) on openbsd wrt/ krb5/com_err and readline linking
From
Simon Bertrang
Date:
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@enterprisedb.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. Regards, Simon
Re: Re: patch to fix configure(.in) on openbsd wrt/ krb5/com_err and readline linking
From
Tom Lane
Date:
Simon Bertrang <janus@errornet.de> writes:
> 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.
Applied to HEAD only. We might consider a back-patch if there are no
reports of trouble.
regards, tom lane
Re: Re: patch to fix configure(.in) on openbsd wrt/ krb5/com_err and readline linking
From
Greg Stark
Date:
On Wed, Jun 10, 2009 at 4:32 PM, Simon Bertrang<janus@errornet.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@enterprisedb.com> writes: >> > > This seems really weird. Firstly, doesn't OpenBSD use ELF? Shouldn't >> > > the library pull in the indirectly needed libraries automatically? B= ut >> > > more to the point, why on *earth* would com_err depend on -lssl and >> > > -lcrypto? com_err is just a standard error handling library. =A0Why >> > > 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. =A0I'm comparing the config and build logs but >> nothing jumped into my face yet. =A0I should fire up my sparc64 to have = the >> same arch as spoonbill for comparison... =A0configure 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. =A0We 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. --=20 Gregory Stark http://mit.edu/~gsstark/resume.pdf