On 7/15/2014 10:59 AM, Henri Beauchamp wrote: > This raises the question whether or not using static libraries to > compile the viewer, for the ones that might conflict with their > dynamic counterparts that get loaded at runtime anyway (especially > libpcre, libxml2 and libz)...
Yes, it does raise the question. I talk about this in the new doc file indra/cmake/00-COMPILE-LINK-RUN.txt (lousy name but collates to the top in my locale). With Linux, I'm stuck with a flat symbol resolution process at startup. I am managing this a bit in ZLIB.cmake and PNG.cmake with --whole-archive options forcing the new libraries to be authoritative. That leaves open the question of backwards incompatibility for shared libraries built against an old version of an API getting symbols resolved with a new API . I don't have a magic solution for that. There is plenty of potential here for incompatibility even with C APIs. Both zlib and libpng have a history of structure non-opacity. But the approach is to test for compatibility and then try to deal with actual problems as they arise. None of the solutions here is particularly attractive but ensuring that run-time version is not less than compile-time version gives us a chance. m -- Monty Brandenberg | Unit of Production Skype monty.linden | Second Life Monty Linden Linden Lab | Makers of Shared Creative Spaces Check out what we're working on! _______________________________________________ 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
