I guess that "...I'm not sure how I got it working..." wasn't
strictly true then, eh? ;-)
Jeremy Whitlock wrote:
> 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
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 17 12:59:28 2007