[opensource-dev] Is 'STANDALONE' confusing?

Aleric Inglewood aleric.inglewood at gmail.com
Mon Feb 21 12:48:03 PST 2011

<paragraph to show its not that simple>
Regarding libraries and the second life viewer we have the following issues:

The version of a library (source code + headers) at the moment it is compiled
into a binary. In all cases we should only use THOSE headers whenever
we compile anything that will link with that binary. This is not always the
case, but that is a bug then, so lets leave that out of our consideration.
Hence, for this analysis we condense the header and library versions
into one: the version of the library (and it's headers) that is being compiled,
and are being used when compiling. This version is not necessarily the
same as the runtime version of a library (where headers do not come
into play at all).

Furthermore we may assume that internally Linden Lab uses the same
versions (that is, they compile a viewer and possibly other libraries,
against the same version as that they ship as prebuilt with that viewer).
However, there is an interdependency between libraries: some libraries
are compiled against other libraries (and both need to be shipped).
Again theoretically it would be possible that a TPV releases prebuilt
libraries for some libraries but not for all: using the LL prebuilt for some.
Also here I will assume that if a TPV replaces some libraries, then they
will at least replace also all libraries that depend on that library or use
that library, so that we can ignore library interdependencies mostly.
Mostly, because we cannot ignore those dependencies for libraries
that are never shipped as prebuilt: it is possible that LL compiles it's
prebuilt libs against libc 2.9, some TPV compiles some prebuilts against
libc 2.10 and the user that compiles her own compiler uses libc 2.11.
Theoretically this can lead to problems, but that is unlikely when it
concerns C libraries. Thus, as long as every C++ library is a prebuilt
then we can probably ignore this anyway. Plus we probably should
ignore the existance of TPV's anyway here :p

Having simplified things thus, we end up with:
LL prebuilt version (assumed to be shipped WITH headers)
System library version (with headers in it's -dev package), or
User compiled version (libraries not provided by the standard

If we built 'standalone' then it's simple: we compile everything
using the same version of any particular library (all libraries are
compiled against eachother: the same version was used even
when compiling the system libs (and should have been used
while compiling the user compiled libraries). Also here an
exception: if you do not compile your own libraries, but use
for example Michelle's debian repository for those libraries
that are not distributed with the stock debian, then those libraries
might be compiled against different versions. We also ignore
this since we trust that Michelle makes sure can ignore that.

If we DO use the prebuilt libraries it is possible that we
compile against headers that are newer than what LL used,
and link with same, newer versions, at runtime. This usually
shouldn't be a problem, and when it is it should be detected
by one of the developers and fixed in the viewer code
(ie, developers using a newer version of boost asked
for viewer code fixes that are backwards compatible and
cause things to work in such a case).
</paragraph to show its not that simple>

Now to answer your question: the above is complex, even
with a lot of simplification and ignoring stuff. Calling everything
that is not a "Linden Lab prebuilt" a "system library" doesn't cut
it. The only really clear constant in all of the above is what
"prebuilt" means, especially "Linden Lab prebuilt". Therefore
I think it's better to use PREBUILT as keyword than

On Mon, Feb 21, 2011 at 4:46 PM, Boroondas Gupte
<sllists at boroon.dasgupta.ch> wrote:
> On 02/21/2011 04:41 PM, Aleric Inglewood wrote:
>> A LOT worse, but still better than 'standalone' would be USE_SYSTEM_LIBS.
> Why would you consider USE_SYSTEM_LIBS worse than other suggestions?
> Cheers,
> Boroondas
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

More information about the opensource-dev mailing list