On Sun, Feb 06, 2005 at 10:53:18PM -0500, Mark Phippard wrote:
| > Let me ask you this: if I leave my working binary RPM of
| > subversion-1.1.3 alone, get the tarball, untar it, and then follow the
| > build instructions for javahl and install that (in other words, a binary
| > RPM for subversion itself and a statically linked javaHL) is that a
| > workable configuration?
|
| It will not be statically linked unless you do something special to make it
| so.
Specify '--enable-all-static' to 'configure' when building subversion.
| If you do, let us know.
I tried. I thought it was easy enough ...
| If we could provide a static JavaHL for Linux we would do so in a
| heartbeat.
You cannot. The problem is that java will use the libdl (aka
"dlopen()") API to dynamically load third party libraries at runtime.
So, even though you can trivially build a static libsvnjavahl.a, java
won't use it.
Now if Sun were to relicense Java with a Free license all of these
problems would go away because distributions would have no politics
hindering them from providing binaries for everything.
| > Look, I don't mind installing a statically linked application (Mozilla
| > Firefox works flawlessly on my system that way without requiring me to
| > change my system. So does straight Eclipse.) Nor do I mind installing
| > RPMs that play nicely with the rest of my system. But subversion seems
| > to want to take over my whole system - and a good portion of my life -
| > and that's asking too much.
|
| You are preaching to the choir. I am not a Linux user, this seems to be a
| problem in the Linux world in that ultimately if the distributor does not
| provide the packages you need, it gets very messy to install software.
The problem starts with how low-level the C runtime environment is.
It continues with dynamic linking (which drastically reduces the
memory needs of your system) and ends with more libraries used by one
program than any (probably) conceived back in 1970 (and even through
the the '80s, I imagine).
The issue you are seeing is the many inter-dependencies of various
pieces of your system and the rapid change facilitated by Open Source.
You have some version of some libraries already. You have some
versions of some programs that need those versions of those libraries.
Now you are trying to install a certain version of another library,
which itself needs certain versions of other libraries. This only
becomes a problem when you can't find a version of a necessary library
that satisfies all the programs and libraries that need it. This is
when it gets ugly. Of course, when the OS vendor builds everything
for you, this isn't a problem because they will give you a set of
binaries that work together.
My recommendation (what I did) is to leave your system libraries
alone. Build subversion with javahl and install it somewhere (ie in
/usr/local or under your home directory). I notice that subversion
provides its own copy of apr and neon rather than relying on the system
libraries by default. This reduces the risk of conflicts, although it
also increases disk and memory usage[1].
If you find that your system has some libraries that are too old to
build the current subversion and you can't upgrade them (for whatever
reason), then build and install a new version of those libraries
locally in another directory and point subversion's build process to
that copy. If you need to do this, provide specifics (specific
libraries, versions, and paths) and I can provide specific steps to
accomplish this. Trying to describe it generically will be rather
long and confusing.
[...]
| Just look at the hoops you have to go through to install Java itself
| as a Debian package as an example.
What hoops? It is four steps:
1) download java
2) run 'make-jpkg'
3) run 'dpkg -i <filename>'
:-)
[...]
| We are mostly Java programmers here,
Although I, too, am a Java programmer, it really helps to have a
basic knowledge of assembly, and C. When you learn assembly you learn
a lot about how the processor handles low-level things like addresses
(pointers) and the stack and function calls. Even though those
details are really not pertinent to someone writing Java code, it
really helps to understand the environments a C program operates in.
Understanding the build and runtime environments of a C program helps
when building software, particularly when it involves libraries, that
aren't provided by the OS vendor. Note that I'm not knocking anyone,
just expressing my observations.
HTH,
-D
[1] If you have a program 'foo' that uses libneon from the system, and
at the same time you run 'svn' that uses its own libneon, you will
have two identical yet distinct copies of libneon in memory at the
same time.
Note that all java libraries suffer from this excess memory usage
because java doesn't implement any sort of "shared library"
arrangement for .class and .jar files.
--
The teaching of the wise is a fountain of life,
turning a man from the snares of death.
Proverbs 13:14
www: http://dman13.dyndns.org/~dman/ jabber: dman_at_dman13.dyndns.org
Received on Sun Feb 13 13:05:01 2005