<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 distribution). 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 SYSTEM_LIBS. On Mon, Feb 21, 2011 at 4:46 PM, Boroondas Gupte <slli...@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 > _______________________________________________ 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
