You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Steve Salkin <st...@salkin.org> on 2002/12/10 00:35:15 UTC
keeping current without deleting old versions
Hi-
The INSTALL document has under "Building the Latest Source under Unix"
the following instructions:
First off, if you have any Subversion libraries lying around
from previous 'make installs', clean them up first!
# rm -f /usr/local/lib/libsvn*
# rm -f /usr/local/lib/libapr*
# rm -f /usr/local/lib/libexpat*
# rm -f /usr/local/lib/libneon*
I want to build from HEAD pretty regularly, but I don't necessarily want
to deploy if I see regressions in make check. Is there a good way to
build from the HEAD without blowing away old installs? I do the build
from a shell script, so maybe I could do some magic with library paths
in there?
Any ideas appreciated.
S-
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: keeping current without deleting old versions
Posted by Ross Mark <ro...@controllingedge.com.au>.
Nicholas Riley wrote:
>
> One caveat with this method - apr-config and apu-config get confused
> by the symbolic links:
>
> % apr-config --link-ld; apu-config --link-ld
> -L/usr/local/bin -lapr-0
> -L/usr/local/bin -laprutil-0
>
> I work around it by replacing /usr/local/bin/lib with
> /usr/local/lib/lib in Subversion's Makefile after running configure.
> Of course this is moot if you don't use Encap to manage
> APR/APR-util... Subversion itself does not have any problems with
> Encap that I've seen.
>
I had not heard of Encap but I have been doing a similar thing by hand
and my installation of apr/apu-config have the symlink problem. The
problem appears to be that apr/apu-config do a dir=`cd some_path && pwd`
and then compare $dir. The problem is that in the shell that
apr/apu-config use on my system (Redhat 7.2) pwd is a builtin and
returns the path as typed by the user. It does not resolve symlinks. I
just changed to two references of pwd with /bin/pwd and now I don't have
any problems with the correct directory being used.
I do have the annoying problem of the libtool generated errors if
-pthread is listed a dependency library. Since this is only a problem
after autogen.sh it is not as annoying as it is an easy patch to libtool
to skip -pthread when checking deplib.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: keeping current without deleting old versions
Posted by Chris Stork <cs...@ics.uci.edu>.
Hi everybody,
Sorry for the late follow-up on something a little off topic, but I just
did a some research regarding these symlink-based package managers, which
might be helpful to people on this list...
On Tue, Dec 10, 2002 at 06:53:22AM -0600, Nicholas Riley wrote:
> On Mon, Dec 09, 2002 at 07:35:15PM -0500, Steve Salkin wrote:
...
> > I want to build from HEAD pretty regularly, but I don't necessarily want
> > to deploy if I see regressions in make check. Is there a good way to
> > build from the HEAD without blowing away old installs? I do the build
> > from a shell script, so maybe I could do some magic with library paths
> > in there?
>
> I use Encap <http://www.encap.org/>, which manages symbolic links, so
> I end up with:
>
> lrwxr-xr-x 1 root wheel 43 Dec 9 23:45
> /usr/local/lib/libapr-0.0.9.2.dylib -> ../encap/httpd-2.0/lib/libapr-0.0.9.2.dylib*
> lrwxr-xr-x 1 root wheel 41 Dec 9 23:45
> /usr/local/lib/libsvn_wc-1.dylib -> ../encap/subversion/lib/libsvn_wc-1.dylib*
>
> etc. It's very simple to use - just ./configure
> --prefix=/usr/local/encap/<product>-<version>, and epkg <product>
Shouldn't it be
./configure --prefix=/usr/local
make
make prefix=/usr/local/encap/subversion-rXYZ install
?
...
> One caveat with this method - apr-config and apu-config get confused
> by the symbolic links:
Maybe this is fixed by the above? Also take a look at srcpkg, which
allows you to install to /usr/local. srcpkg automatically recognises
all the installed files based on c/mtime and/or filesize and moves them
to their own directory before replacing them with symlinks. This
directory could even be managed by epkg then.
Just some thoughts. Back to lurking mode.
--
Chris Stork (PhD student at UC Irvine) http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: keeping current without deleting old versions
Posted by Nicholas Riley <nj...@uiuc.edu>.
On Mon, Dec 09, 2002 at 07:35:15PM -0500, Steve Salkin wrote:
> First off, if you have any Subversion libraries lying around
> from previous 'make installs', clean them up first!
>
> # rm -f /usr/local/lib/libsvn*
> # rm -f /usr/local/lib/libapr*
> # rm -f /usr/local/lib/libexpat*
> # rm -f /usr/local/lib/libneon*
>
> I want to build from HEAD pretty regularly, but I don't necessarily want
> to deploy if I see regressions in make check. Is there a good way to
> build from the HEAD without blowing away old installs? I do the build
> from a shell script, so maybe I could do some magic with library paths
> in there?
I use Encap <http://www.encap.org/>, which manages symbolic links, so
I end up with:
lrwxr-xr-x 1 root wheel 43 Dec 9 23:45
/usr/local/lib/libapr-0.0.9.2.dylib -> ../encap/httpd-2.0/lib/libapr-0.0.9.2.dylib*
lrwxr-xr-x 1 root wheel 41 Dec 9 23:45
/usr/local/lib/libsvn_wc-1.dylib -> ../encap/subversion/lib/libsvn_wc-1.dylib*
etc. It's very simple to use - just ./configure
--prefix=/usr/local/encap/<product>-<version>, and epkg <product>
after you've installed. For apps which I update frequently, I usually
omit the version number (or at least the minor version number, in the
case of httpd).
Before building, I do:
# apachectl stop
# cd /usr/local/encap
# tar zcf subversion-rXXXX.tar.gz subversion httpd-2.0/lib/modules/mod_dav_svn.so
# epkg -r subversion
# rm -rf subversion
If the new installation is broken, I just nuke the build directory,
untar the old version, 'epkg subversion', restart Apache and I'm back
where I started.
One caveat with this method - apr-config and apu-config get confused
by the symbolic links:
% apr-config --link-ld; apu-config --link-ld
-L/usr/local/bin -lapr-0
-L/usr/local/bin -laprutil-0
I work around it by replacing /usr/local/bin/lib with
/usr/local/lib/lib in Subversion's Makefile after running configure.
Of course this is moot if you don't use Encap to manage
APR/APR-util... Subversion itself does not have any problems with
Encap that I've seen.
--
=Nicholas Riley <nj...@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
Pablo Research Group, Department of Computer Science and
Medical Scholars Program, University of Illinois at Urbana-Champaign
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: keeping current without deleting old versions
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
cmpilato@collab.net wrote:
>Ben Collins-Sussman <su...@collab.net> writes:
>
>
>
>>Steve Salkin <st...@salkin.org> writes:
>>
>>
>>
>>> # rm -f /usr/local/lib/libsvn*
>>> # rm -f /usr/local/lib/libapr*
>>> # rm -f /usr/local/lib/libexpat*
>>> # rm -f /usr/local/lib/libneon*
>>>
>>>
>>I think these instructions are ancient, paranoid, and unnecessary.
>>Maybe we can delete them?
>>
>>I think they only exist because a long time ago, I used to get burned
>>by libtool on FreeBSD. Nobody else (on Linux) had my problem.
>>
>>
>
>Not true. I had this problem on my Linux laptop and on
>svn.collab.net. I've not seen the problem in a long while, though.
>
>
i've also seen the same issue on Mac OS X, recently.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: keeping current without deleting old versions
Posted by cm...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> Steve Salkin <st...@salkin.org> writes:
>
> > # rm -f /usr/local/lib/libsvn*
> > # rm -f /usr/local/lib/libapr*
> > # rm -f /usr/local/lib/libexpat*
> > # rm -f /usr/local/lib/libneon*
>
> I think these instructions are ancient, paranoid, and unnecessary.
> Maybe we can delete them?
>
> I think they only exist because a long time ago, I used to get burned
> by libtool on FreeBSD. Nobody else (on Linux) had my problem.
Not true. I had this problem on my Linux laptop and on
svn.collab.net. I've not seen the problem in a long while, though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: keeping current without deleting old versions
Posted by Ben Collins-Sussman <su...@collab.net>.
Steve Salkin <st...@salkin.org> writes:
> # rm -f /usr/local/lib/libsvn*
> # rm -f /usr/local/lib/libapr*
> # rm -f /usr/local/lib/libexpat*
> # rm -f /usr/local/lib/libneon*
I think these instructions are ancient, paranoid, and unnecessary.
Maybe we can delete them?
I think they only exist because a long time ago, I used to get burned
by libtool on FreeBSD. Nobody else (on Linux) had my problem.
The problem is that on FreeBSD, the linker would notice that I had
/usr/local/lib in my LD_LIBRARY_PATH, and actually link against the
*installed* svn libraries rather than the ones freshly built in my
source tree. Totally broken, IMO, that LD_LIBRARY_PATH should take
precedence over the --runpath's passed by libtool to ld. As soon as I
blanked my LD_LIBRARY_PATH, the problem went away. And to this day,
this problem has only ever existed on FreeBSD.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org