Hi all,
I'm going to implement a couple of changes which I'm rumbling about from
a while and I 'd like to share some thoughts.
* Short summary (and quick rationale)
-------------------------------------
1) Add an option (enabled by default) to install versioned files,
enabling parallel installation, (e.g. like gstreamer et. al does).
See below for an example.
2) Get rid at least partially of our static linking mess and ship
some of our internal libraries as shared but private.
See below for an example.
NEITHER OF THE ABOVE WILL AFFECT THE avi* TOOLS!
Because they changes much more slowly and because I wanto to avoid (as
much as is possible) hurting the people who already need only them
(think the transcode-tools package).
* Discussion
------------
* 2. Libraries linking sanitization
-----------------------------------
* 2.1. Linking overload
-----------------------
I've to say that's mostly a fault of mine, but why has the _transcode main
binary_
to be linked with, say, libX11, when it is import_x11.so to use it?
I'll do a deep review and sanitization of all the above, but my gut feeling
suggest
it's kinda of intermangled with the point 2 below.
* 2.2. Excessive static linking considered harmful
--------------------------------------------------
That's most a developer thing. I'm pretty sick and tired of the oddities of
our current linking model.
My impression (no numbers, so I'm likely wrong) is that doesn't save us from
the bloat, and for sure it's clumsy and has a fair number of rough edges.
For the best that I can remember, and as far as I know, such model never come
out from a precise design, but it has some good points on his side.
The key bonus of our current model is that is pointless to ship on the system
dirs librararies that noone else uses. There is little or no advantage in
having, say,
/usr/lib/libtc.so.1
since only the tc* stuff will use it.
On the other hand, since more than on program use such library, there is room
for having it shared. Having the libtc* stuff shared and the tc* programs link
to them
will save a fair number of headaches and annoyances (at least to me).
How to match those two aspects?
* 2.3. Proposed solution
------------------------
The solution of the dilemma:
- ship most of internal libraries as shared
- install them on /usr/lib/transcode-1.2.
- ship the binaries on /usr/libexec/transcode-1.2, linked to the above
- ship an helper program into /usr/bin, which will basically do something like
%%%
#!/bin/bash
# tclaunch
EXE="$0"
if [ "$EXE" == "tclaunch" ]; then
EXE="$1"
shift
fi
EXE=$( basename $EXE )
LD_LIBRARY_PATH="/usr/lib/transcode-$VER:$LD_LIBRARY_PATH"
exec /usr/libexec/transcode-$VER/$EXE $*
%%%
- ship all the (hard)links needed, e.g.
tcdecode-1.2 -> tclaunch-1.2
transcode-1.2 -> tclaunch-1.2
I know there are better and more elegant solution involvingthe ELF header and
the RPATH/RUNPATH field,
but I think tha above is the most portable and debuggable, since AFAIK we got a
fair MacOsX userbase
and since I had no reliable access to any OSX box (neither I'll have into the
foreseeable future)
I don't want to harm them unless it becomes absolutely unavoidable.
Why I said "most of the internal libraries"?
In my opinion, the above will not apply to all libraries. aclib comes to mind
as the prominent
(and maybe only) example of a library which will be still used as static only,
as it is speed critical.
The avi* tools will still link only static libraries as said above.
For point #1 of the above, see the previous email.
Comments and discussion always welcome.
--
Francesco Romani // Ikitt
http://fromani.exit1.org ::: transcode homepage
http://tcforge.berlios.de ::: transcode experimental forge
