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.1 is
>> 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 Sat Apr 14 21:42:53 2007