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 Sat Apr 14 22:10:33 2007