>Mike Hearn <[EMAIL PROTECTED]> writes:
>
>> Paul Davis of Ardour has raised a good point: currently despite the fact
>> that the symbols in libwine are versioned, we change them at will and
>> don't change the symbol version, for instance in the patch that made
>> environ passed through to wine_in
Mike Hearn <[EMAIL PROTECTED]> writes:
> The problem then is that the WINE_1.0 symbol means the 1.0 frozen
> interfaces *and* any that were used before then. What is the point of
> symbol versioning if the linker can't meet the guarantees it's supposed to
> provide?
Symbol versioning is enabled r
On Sun, 13 Jun 2004 09:22:37 -0700, Alexandre Julliard wrote:
> No, the interfaces are not considered frozen, they will be frozen in
> 1.0; until then it is possible that things will still need to
> change. For the specific wine_init case, I suppose we could back out
> the change if it causes troub
Mike Hearn <[EMAIL PROTECTED]> writes:
> Paul Davis of Ardour has raised a good point: currently despite the fact
> that the symbols in libwine are versioned, we change them at will and
> don't change the symbol version, for instance in the patch that made
> environ passed through to wine_init fro
>Finally, apparently Paul has had to duplicate a fair amount of Wine code
>inside his libfst (library for loading Cubase VST plugins) because the
>relevant functions are declared static in Wine. Paul, could you post a
>list of exactly what you use?
actually, a "fair amount" is an overstatement. it
Hi Alexandre,
Paul Davis of Ardour has raised a good point: currently despite the fact
that the symbols in libwine are versioned, we change them at will and
don't change the symbol version, for instance in the patch that made
environ passed through to wine_init from main to hack around the general
