I'm wondering why you added all those libFLAC.so.8 symbols to the
libflac++6 symbol file, seems quite unneeded.
It appears you used all the common symbols + the 32bit specific ones? Is
that any better than just using the common symbols or some other solution?
On 02/22/2015 01:42 PM, Phil Pratt-Szeliga wrote:
> Possible fix [1] updates symbol files of libflac++6. This problem is
> from libflac converting long to long long. On a 32bit system long will
> evaluate to int32 and on 64bit it will evaulate to int64. The change by
> libflac is attempting to make the values int64 on all architectures.
>
> If the libflac++6 symbols change, what repercussions does this have to
> the rest of the packages? Maybe just reverting the libflac long longs to
> long would be the best fix.
>
> [1] https://code.launchpad.net/~pcpratts/ubuntu/vivid/flac/fix-for-
> ftbfs/+merge/250557
>
I'm wondering why you added all those libFLAC.so.8 symbols to the /code.launchpad .net/~pcpratts/ ubuntu/ vivid/flac/ fix-for-
libflac++6 symbol file, seems quite unneeded.
It appears you used all the common symbols + the 32bit specific ones? Is
that any better than just using the common symbols or some other solution?
On 02/22/2015 01:42 PM, Phil Pratt-Szeliga wrote:
> Possible fix [1] updates symbol files of libflac++6. This problem is
> from libflac converting long to long long. On a 32bit system long will
> evaluate to int32 and on 64bit it will evaulate to int64. The change by
> libflac is attempting to make the values int64 on all architectures.
>
> If the libflac++6 symbols change, what repercussions does this have to
> the rest of the packages? Maybe just reverting the libflac long longs to
> long would be the best fix.
>
> [1] https:/
> ftbfs/+merge/250557
>