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 02:53:37 2007