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>
index | next in thread | previous in thread | raw e-mail
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. Khelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46E7421B.5060606>