[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] '--disable-apple_ieee' [Was: PATCH: disable the of system librarie
[lmi] '--disable-apple_ieee' [Was: PATCH: disable the of system libraries when building wx]
Thu, 23 Jul 2020 21:35:42 +0000
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
On 2020-07-23 14:08, Vadim Zeitlin wrote:
> On Thu, 23 Jul 2020 13:50:16 +0000 Greg Chicares <firstname.lastname@example.org>
> GC> As for that apple IEEE thing...
> I'll need to look into this before answering your questions below. I've
> avoided doing it for 20+ years, but it seems the time has finally come to
> dive into it. For now, I can only say that "Apple" is a red herring, AFAICS
> this has nothing to do with neither Apple the company nor the platform. The
> reason we have a separate option for disabling this is that this code uses
> a different licence, that you need to separately accept, see
It seems to be in 'lame':
and in 'python', which blithely re-copyrights it:
It's also here:
but relicensed there in a way incompatible with the GPL:
> AFAICS this licence doesn't really contradict anything,
That's good sense, but not necessarily a legally safe interpretation.
> but it would still
> be simpler if we could avoid using this code completely. I'll add this to
> my TODO...
AFAICT, this code enables wx to serialize and deserialize 80-bit
floating-point numbers written to binary files, so the use case is
making such files readable (and even writable) on platforms that
don't support that format (otherwise, something like this:
unsigned char ten_bytes;
fread(&ten_bytes, 10, 1, file_ptr);
long double x = *(long double*) ten_bytes;
double y = bourn_cast<double>(x);
would suffice). Is that use case important to anyone? in 2020?
If you're thinking of reimplementing it, let me know so that I
can design some tests that try to break it.
Many years ago, lmi or its predecessor really did serialize
doubles (but not long doubles) as eight-byte packets. But we
haven't done that since about two decades ago, and we never
used wx for that purpose, so this code is unreachable by lmi.
> GC> I'm thinking maybe we should just get rid of
> GC> --disable-apple_ieee
> GC> --disable-gif
> GC> for lmi.
But now I have second thoughts about the apple ieee part, so...
> I definitely wouldn't object to doing this but, on their own, these
> options are not a problem -- as long as we're building our private wx
> anyhow, we can use whichever options we want for it. Getting rid of the
> corresponding checks in wx_checks.cpp would be helpful, however.
Okay, I'll do that. Otherwise, those checks would probably
prevent us from using a debian wx package.