Date: Tue, 11 Sep 2007 20:34:19 -0500 From: Kyle Allender <kallender@completecomputing.com> To: Giorgos Keramidas <keramida@ceid.upatras.gr> Cc: freebsd-questions@freebsd.org Subject: Re: subversion 1.4.4_1: svnserve.in missing Message-ID: <46E7421B.5060606@completecomputing.com> In-Reply-To: <20070911141755.GB10913@kobe.laptop> References: <46E4C243.7010605@completecomputing.com> <20070910064901.GA2353@kobe.laptop> <46E53681.3060904@completecomputing.com> <20070910123327.GA9629@kobe.laptop> <46E5EFFD.2010801@completecomputing.com> <20070911110953.GB2167@kobe.laptop> <46E67EA0.8010305@completecomputing.com> <20070911141755.GB10913@kobe.laptop>
next in thread | previous in thread | raw e-mail | index | archive | help
Giorgos Keramidas wrote: > On 2007-09-11 06:40, Kyle Allender <kallender@completecomputing.com> wrote: > >> Giorgos Keramidas wrote: >> >>>> sia# svn co \ >>>> http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk \ >>>> CalendarServer >>>> /libexec/ld-elf.so.1: /usr/lib/libkrb5.so: Undefined symbol "initialize_asn1_error_table_r" >>>> >>> Hmmm, very odd indeed. >>> >>> What does ldd(1) show for your subversion binary? >>> >>> Which kerberos library does it link with? >>> >>> This looks like something to ld-elf.so.1 picking up the wrong >>> Kerberos library from /usr/lib, while the port-build picked up >>> another Kerberos installation from /usr/local :-/ >>> >> sia# /usr/bin/ldd /usr/local/bin/svn >> /usr/local/bin/svn: >> [...] >> (0x28093000) >> libgssapi_krb5.so => /usr/local/lib/libgssapi_krb5.so (0x2840f000) >> libkrb5.so => /usr/lib/libkrb5.so (0x28439000) >> libk5crypto.so => /usr/local/lib/libk5crypto.so (0x2846d000) >> libkrb5.so => /usr/local/lib/libkrb5.so (0x2869c000) >> libcom_err.so => /usr/local/lib/libcom_err.so (0x2871c000) >> libkrb5support.so => /usr/local/lib/libkrb5support.so (0x28722000) >> [...] >> > > Nice. This is a strange mixture of ports-based and non ports-based krb5 > libraries. I'm not sure how the subversion binary managed to link with > this sort of library mismatch, but here's the source of your problems :( > > >> It looks like libk5crypto.so is pointing to /usr/local/lib while >> libkrb5.so points to /usr/local. >> > > Right, and a few others too. > > >> There is the kerberos installed with the OS and then the libraries I >> installed from ports - could that be the problem? >> >> sia# pkg_info | grep krb >> krb5-1.6.2 An authentication system developed at MIT, successor to Ker >> sia# >> > > Do you really need two separate Kerberos implementations? > > If the port version is aabsolutely necessary, then it may be necessary > to remove the kerberos5 parts of the base-system and rebuild with: > > WITHOUT_KERBEROS='yes' > > Alternatively, you should rebuild the ports which use Kerberos5 after > removing the security/heimdal port. > > *sigh* OK. I _thought_ I had a grasp on this, but... I did have the security/krb5 port installed. I removed that (pkg_delete). I then checked pkg_info output for any reference to heimdal - it was not installed. So... Subversion now fails to build with this error: cd subversion/libsvn_ra_dav && /usr/local/bin/libtool --tag=CC --silent --mode=link cc -O2 -fno-strict-aliasing -pipe -g -O2 -L/usr/local/lib -L/usr/local/lib/db42 -rpath /usr/local/lib -o libsvn_ra_dav-1.la commit.lo fetch.lo file_revs.lo log.lo merge.lo options.lo props.lo replay.lo session.lo util.lo ../../subversion/libsvn_delta/libsvn_delta-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la /usr/local/lib/libaprutil-1.la -lgdbm -ldb-4.2 -lexpat -liconv /usr/local/lib/libapr-1.la -lcrypt -lpthread -L/usr/local/lib -rpath=/usr/lib:/usr/local/lib -L/usr/local/lib -lneon -lintl -lssl -lcrypto -lz -L/usr/local/lib -Wl,-rpath -Wl,/usr/local/lib -O2 -fno-strict-aliasing -pipe -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lexpat -lintl -lz /usr/bin/ld: cannot find -lgssapi_krb5 *** Error code 1 Stop in /usr/ports/devel/subversion/work/subversion-1.4.4. *** Error code 1 Stop in /usr/ports/devel/subversion. sia# According to what you've suggested previously, I need to run portupgrade -vu -N -R -f subversion to repair the dependencies such that everything will look at the system kerberos, not the port one. I will do that, but will ask one more question in the meantime (the build will take some time to complete): If that does not work, I would guess my next course of action would be to fetch the latest cvs changes to the system source tree and buildworld. But if I do that, do I go ahead and change the WITHOUT_KERBEROS="yes" line in /etc/make.conf or leave it as is? Will subversion build correctly if kerberos is not in the main system? Thanks for your patience and assistance. K
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46E7421B.5060606>