[lmi] '--disable-apple_ieee' [Was: PATCH: disable the of system libraries when building wx]

[Greg Chicares]

On 2020-07-23 14:08, Vadim Zeitlin wrote:
> On Thu, 23 Jul 2020 13:50:16 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> 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
> 
> https://github.com/wxWidgets/wxWidgets/blob/v3.1.4/src/common/extended.c#L20,L33

It seems to be in 'lame':

http://lab.llvm.org:8080/artifacts/opt-view_test-suite/build/MultiSource/Benchmarks/MiBench/consumer-lame/CMakeFiles/consumer-lame.dir/html/_org_test-suite_MultiSource_Benchmarks_MiBench_consumer-lame_portableio.c.html

and in 'python', which blithely re-copyrights it:

https://ftp.nice.ch/pub/next/audio/converter/_GISO.3.3.s/GISO/Sox/_aiff.c.html

It's also here:

https://plan9.io/sources/plan9/sys/src/games/mp3enc/portableio.c

but relicensed there in a way incompatible with the GPL:

https://www.gnu.org/licenses/license-list.en.html#lucent102

> 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[10];
  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.