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 Sun Apr 15 05:04:16 2007