[sldev] Proprietary dependencies

[Dzonatas]

Argent Stonecutter wrote:
>> I did not suggest to just switch from static to shared.
>
> "We've heard the issue saying that it makes installation easier, but 
> that is all that is being said. If the installation scripts and 
> procedure were made to handle dynamic libraries, the issue of there 
> being a proprietary or open-source library attached become really a 
> non-issue as long as they are dynamically linked."
>
> The following paragraph, beginning with "Further, the client code 
> could..." after the line "That is one part there" did not appear to be 
> an essential part of the proposal, because it DID begin with 
> "Further...". So I responded to that separately.
>
> That's one part there.
>
> Further, that doesn't deal with the main point, the one I'm trying to 
> get back to, which is that Linden Labs has to be a part of any such 
> scheme, and Linden Labs has indicated reluctance to even support a far 
> less ambitious proposal.

=/

Obviously an assumption was made when I said "to handle dynamic 
libraries" that the "to handle" bit was overlook.  I targeted the interface.

The client/installation can still be made to handle dynamic libraries 
without any specific proprietary or open-source library being 
interfaced.  Just the ability to handle them is what I mentioned.

For example, I wrote code to handle a standard low-level interface to 
dynamic shared libraries. It is very simple. It enabled me to isolate 
SSE code into a library, so that on machines that don't have SSE it 
would not load, and on machines that have SSE it would load. That FIXES 
the problem with SSE leaks and improves the features of the client. Why 
won't LL accept such a patch and instead keep the official client 
disabled of any SSE code on win32?  Part of the scheme you suggest? Go 
figure?