[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Compiling Static Subversion Binaries on RHEL

From: Jeremy Whitlock <jcscoobyrs_at_gmail.com>
Date: 2007-04-17 05:46:52 CEST

David,
    We did it four times from scratch and they have all been successful. We
have even created a tarball of the fully-configured server and reproduced a
failover server by untarring it on another system and setting up svnsync.
How's that? ;)

Take care,

Jeremy

On 4/16/07, david x callaway <dxc@pobox.com> wrote:
>
> if your client is smart, they will want a reproducible process, so you
> might consider doing it one more time, from scratch ;-).
>
> Jeremy Whitlock wrote:
> > David,
> > I'm not sure how I got it working but I did. I'm not a gcc guru but
> I
> > did build things and get everything linked properly so that I didn't
> > have to
> > update LD_LIBRARY_PATH or /etc/ld.so.conf. I'll learn it and come back
> to
> > you all.
> >
> > Take care,
> >
> > Jeremy
> >
> > On 4/14/07, david x callaway <dxc@pobox.com> wrote:
> >>
> >> remember there is no such thing as "locating" a lib that is built
> >> static; you either link it into the binary when you build or you don't
> >> connect to it at all.
> >>
> >> if all the client systems are the same you could use -rpath to get the
> >> search path built in when you build the libs, but the whole biz seems
> >> overly complicated for the simple problem of finding a few shared libs.
> >> doesn't RH have an rpm for open ldap? fedora core 6 certainly does,
> >> and it is basically the testing ground for future RHEL releases. at
> >> worst you can specify LD_LIBRARY_PATH in the client's init files at
> the
> >> same time as you are adding to the PATH to pick up other custom stuff.
> >>
> >> Jeremy Whitlock wrote:
> >> > David,
> >> > It doesn't have to be completely static so linking against system
> >> > libraries like libc doesn't bother me. I think I have the best
> >> available
> >> > approach working which was to compile Subversion and its dependencies
> >> > statically but the libraries of each as shared. This way, the
> >> executables
> >> > are still linked to shared objects but the paths to those shared
> >> objects
> >> > are
> >> > linked into the executable. This is still pretty much
> >> self-contained as
> >> > long as the servers my client is running on is the same, which they
> >> are.
> >> > Although I still have a few problems making my compilation process
> not
> >> > ideal, it does work. In case you are interested, here is the list of
> >> the
> >> > problems I had to work around:
> >> >
> >> > apr-util doesn't locate the OpenLDAP libraries when OpenLDAP is built
> >> > completely static
> >> > OpenLDAP cannot locate a suitable SSL/TLS library even though OpenSSL
> >> was
> >> > compiled on this system with everything enabled
> >> >
> >> > Like I said, the above was worked around by compiling OpenLDAP
> >> libraries
> >> as
> >> > shared and not having SSL/TLS support built into OpenLDAP/mod_ldap.
> >> >
> >> > Take care,
> >> >
> >> > Jeremy
> >> >
> >> > On 4/14/07, david x callaway <dxc@pobox.com> wrote:
> >> >>
> >> >> libc.so.6 and libc.so.1 are not only different versions of the c
> >> runtime
> >> >> library, but both of them are *shared* libraries, presumably not
> what
> >> >> you want. in order to get a fully static build you need static
> >> versions
> >> >> of all the libs you are going to link, e.g libc.a. you are going
> to
> >> >> scream when you find out how many libraries svn alone uses (40 of
> them
> >> >> on my fedora core 6 system, plus 30 for apache), but in theory all
> the
> >> >> standard installed libs will be there as both static and shared
> libs,
> >> >> which means you just need to produce the statics for things you are
> >> >> custom building. for example my fc6 system with apache has both
> >> shared
> >> >> and static libldap plus the re-entrant versions.
> >> >>
> >> >> if you want to find out the shared lib dependencies on svn built
> >> shared,
> >> >> do this:
> >> >>
> >> >> ldd /usr/bin/svn # or wherever yours is
> >> >>
> >> >> the fact that you are ending up needing both libc.so. 1 and 6 means
> >> that
> >> >> two parts of your builds want different versions of glibc, but this
> is
> >> >> pretty surprising on rhel4. maybe you have the legacy development
> >> >> packages installed, e.g. gcc-2.96? for sure this will be an issue
> >> when
> >> >> you get ready to link the whole mess. also, aren't there issues
> >> >> building apache static? it likes to load its modules dynamically as
> I
> >> >> remember?
> >> >>
> >> >> if you really really want to do it, I'd try starting with the static
> >> >> build pkg discussed below, but I'd do it on a system that doesn't
> have
> >> >> the legacy development tools on it to eliminate one area of
> confusion.
> >> >>
> >> >> wrt selinux, I posted a while back on how to make that work on fc6,
> >> >> possibly not close enough to rhel4 for you, but I think I gave some
> >> >> links. the changes to just allow the binaries to load are small, you
> >> may
> >> >> not need to kill the whole thing.
> >> >>
> >> >> dxc
> >> >>
> >> >> Jeremy Whitlock wrote:
> >> >> > Hi All,
> >> >> > I found the culprit but I'm not sure why. When I pass the
> >> >> > "--enable-all-static" to configure for Subversion, that is what
> >> causes
> >> >> the
> >> >> > problem. The exact version of RHELS is "Red Hat Enterprise Linux
> ES
> >> >> > release
> >> >> > 4 (Nahant)", as per the /etc/redhat-release. If anyone has any
> >> input,
> >> >> > advice or suggestions, please let me know. At least I can build a
> >> >> > partially
> >> >> > static Subversion instance which works for now.
> >> >> >
> >> >> > Take care,
> >> >> >
> >> >> > Jeremy
> >> >> >
> >> >> > On 4/14/07, Jeremy Whitlock <jcscoobyrs@gmail.com> wrote:
> >> >> >>
> >> >> >> David,
> >> >> >> Thanks for the input. As for the ELF interpreter, I'm not
> sure
> >> >> what
> >> >> >> the problem is. When I build everything shared, the ELF
> >> interpreter
> >> >> >> is fine
> >> >> >> because the Subversion executables are linked with libc.so.6 ,
> >> >> which is
> >> >> >> available. When I change things to more of a static build,
> >> >> libc.so.1is
> >> >> >> used and is not present on the system. I've started with fresh
> >> builds
> >> >> >> everytime it has filed. I even remove all sources and reextract
> >> the
> >> >> >> tarballs. I am at a loss. I may have found something but I
> don't
> >> >> >> want to
> >> >> >> discuss until I prove/disprove it.
> >> >> >>
> >> >> >> Take care,
> >> >> >>
> >> >> >> Jeremy
> >> >> >>
> >> >> >> On 4/14/07, David James <james@cs.toronto.edu> wrote:
> >> >> >> >
> >> >> >> > On 4/13/07, Jeremy Whitlock <jcscoobyrs@gmail.com> wrote:
> >> >> >> > > Hi All,
> >> >> >> > > I have spent over 12 hours today trying to build a static
> >> >> >> > Subversion
> >> >> >> > > binary, and static binary dependencies of Subversion, on
> >> >> RHEL. After
> >> >> >> > > fighting with apr-util and OpenLDAP, I finally decided to
> stop
> >> >> >> > building
> >> >> >> > > OpenLDAP statically and got Apache compiled and running. The
> >> >> problem
> >> >> >> > is
> >> >> >> > > when I build Subversion statically on RHEL, I get the
> following
> >> >> >> error:
> >> >> >> >
> >> >> >> >
> >> >> >> > Hi Jeremy,
> >> >> >> >
> >> >> >> > If you're trying to build Subversion statically, a good place
> to
> >> >> start
> >> >> >> > is with D.J. Hagberg's static build. If you look inside the
> >> >> >> > svn-linux-build.zip file you'll see that D.J. has scripts which
> >> >> >> > carefully configure all of the dependencies.
> >> >> >> > http://svn.haxx.se/dev/archive-2007-02/0046.shtml
> >> >> >> >
> >> >> >> > I recommend starting with his script and adding any additional
> >> >> >> > dependencies to that.
> >> >> >> >
> >> >> >> > If you got a bad ELF interpreter error, it likely means that
> one
> >> of
> >> >> >> > the files in your build got corrupted somehow, or that you
> built
> >> >> some
> >> >> >> > of the binaries on a different processor architecture. That's
> my
> >> >> >> > experience anyway. To avoid this error, it would be a good
> >> idea to
> >> >> >> > start fresh with a clean build.
> >> >> >> >
> >> >> >> > Cheers,
> >> >> >> >
> >> >> >> > David
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
>
Received on Tue Apr 17 05:47:19 2007

This is an archived mail posted to the Subversion Users mailing list.