| If the binary distribution was statically linked with the octave and c++
| libraries, wouldn't that eliminate the need for -R and LD_LIBRARY_PATH?
| I configured mine on Solaris 2.5.1 with just './configure' and no command-
| line options; ldd on the resulting binary says:
| libdl.so.1 => /usr/lib/libdl.so.1
| libsocket.so.1 => /usr/lib/libsocket.so.1
| libm.so.1 => /usr/lib/libm.so.1
| libc.so.1 => /usr/lib/libc.so.1
| libnsl.so.1 => /usr/lib/libnsl.so.1
| libintl.so.1 => /usr/lib/libintl.so.1
| libmp.so.1 => /usr/lib/libmp.so.1
| libw.so.1 => /usr/lib/libw.so.1
| which are all standard system dynamic libraries.
That means you probably don't have a shared version of libstdc++.
| But maybe you have
| other reasons for wanting dynamically linked binary distributions...
No, I just thought that since I was creating the shared libraries, I
should use them with the distributed binary.
One of the goals was to allow people to build their own .oct files,
but the binary distributions don't contain the necessary .h and .cc
files for that to work (yet). My reason for not distributing the
necessary .h and .cc files was that I assumed that people who were
going to be writing C++ code would be capable of compiling Octave.
If I do add the .h and .cc files to the binary distributions so that
people can build .oct files without having to also compile Octave,
then I suppose it would be ok to distribute a statically linked binary
along with the shared library files so that people could link their
code without creating 2MB .oct files.
If people want to do better than that, they can re-link (to allow
that, I could also distribute octave.o and builtins.o, which are the
only files needed other than the shared libraries).
So, we could have just two binary distributions for each system (one
with debugging symbols, the other stripped). They would contain the
statically linked octave binary
all the README files and scripts for installing octave
the doc files
the .m files
if shared libraries and dynamic linking are supported:
the script for building .oct files
shared libraries, octave.o, and builtins.o
all .oct files
all .h and .cc files that are needed for building .oct files
Re: Octave 2.0.2 : linking error on alpha-dec-osf3.2
On 6-Feb-1997, I wrote:
| So, we could have just two binary distributions for each system (one
| with debugging symbols, the other stripped). They would contain the
| following things:
| statically linked octave binary
The problem with this is that some systems (like Linux) don't seem to
allow a statically linked binary to also be able to do dynamic
When I tried building Octave with -static and -ldl, it failed because
there is only a shared version of libdl. Does anyone know if it is
possible to build a non-shared version of this library?
If not, it looks like I am back to building different binary
distributions. (Or maybe just giving up on dynamic linking for the
binary distributions -- it certainly does seem to cause a lot of
| Quoting John W. Eaton,
| > ... (Or maybe just giving up on dynamic linking for the
| > binary distributions -- it certainly does seem to cause a lot of
| > trouble...)
| That is my conclusion. I see nothing wrong with binary distributions
| having less installation flexibility and options (shared vs. static) than
| source distributions.
Since I'd rather not waste much more time on this, I decided to
simplify things so that all you will have to do is this
tar zxf octave-2.0.3.tar.gz
to create a binary distribution that includes a statically linked
version of Octave. It won't support dynamic linking, and it won't
include any libraries or header files. If people want something else,
they can do the work to make it happen.
| I don't think it should be your responsibility to
| create binaries for every possible system configuration, just the basics.
| Keeping flexibility and portability in the source distribution and
| configuration is the main concern in such a large software project.
| That's my 2.5 cents...
I agree, though I was willing to try to do something more than that if
it wasn't too hard. Unfortunately, it is. I would prefer to have the
binary distributions support dynamic linking, but I think it's more
important for them to work reliably.