Mailing List Archive

On 28/04/2021 6:52 am, John P Poet wrote:
> Are the instructions @
> https://github.com/MythTV/packaging/blob/master/android/Readme.md
> <https://github.com/MythTV/packaging/blob/master/android/Readme.md> up
> to date? I am trying to build latest master on a Fedora 34 machine.
>
> First error I got was that
> Android/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-clang
> did not exist. To fix that I soft linked the version specific file:
> $ ln -s aarch64-linux-android29-clang aarch64-linux-android-clang
>
> Then `make SDK=29 MODE=arm64 libs` produces:

I have not used the command line variables in a long time. SDK=29 should
not be necessary.

In fact the SDK=XX mode may be broken. Not sure.

Not sure about the override. shouldnt need to use the SDK=29 it should
be the default. see setenv.sh.

The NDK is still on 28. The layout changed and caused problems when I
tried it.

I have recently been trying QT5.15.2 but had some problems but there are
a couple of fixes to the setenv script for detecting tool paths which I
will attach for you to test. This is still on QT 5.14.1 but is sort of
ready to go for qt 5.15.2 when I figure out the issue (some API change I
think).

Then all I do is run 'make libs' and then 'make' or 'make distclean
everything'

my buildrc will show you which NDK's Ive been trying. use android studio
to install ndks with the correct version.

Sorry Ive been lazy and havent commited some of these updates yet. Not
happy yet with them and I dont want to break things.

See how you go. But it does work for me.

Mark

>
> make[2]: Entering directory
> '/home/john/src/Myth/Android/packaging/android/libs64/openssl-1.0.2u/crypto'
> make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent
> make rule.
> /usr/bin/perl ../util/mkbuildinf.pl <http://mkbuildinf.pl>
> "/home/john/Android/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-clang
> -I. -I.. -I../include  -DOPENSSL_THREADS
>  --cross-compile-prefix-cc=/home/john/Android/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android29-
> -D__ANDROID_API__=29 " "os.api_level" >buildinf.h
> /home/john/Android/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-clang
> -I. -I.. -I../include  -DOPENSSL_THREADS
>  --cross-compile-prefix-cc=/home/john/Android/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android29-
> -D__ANDROID_API__=29    -c -o cryptlib.o cryptlib.c
> clang: error: unsupported option
> '--cross-compile-prefix-cc=/home/john/Android/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android29-'
> make[2]: *** [<builtin>: cryptlib.o] Error 1
> make[2]: Leaving directory
> '/home/john/src/Myth/Android/packaging/android/libs64/openssl-1.0.2u/crypto'
> make[1]: *** [Makefile:288: build_crypto] Error 1
> make[1]: Leaving directory
> '/home/john/src/Myth/Android/packaging/android/libs64/openssl-1.0.2u'
> ~/src/Myth/Android/packaging/android/libs64
> ~/src/Myth/Android/packaging/android
> make: *** [Makefile:33: libs] Error 2
>
> I have hunted a bit trying to solve that, but have not found a
> solution. Can anyone tell me how to get past this?
>
> Thanks,
>
> John




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

On Tue, Apr 27, 2021 at 5:40 PM Mark Spieth <mark@digivation.com.au> wrote:

> On 28/04/2021 6:52 am, John P Poet wrote:
>
> Are the instructions @
> https://github.com/MythTV/packaging/blob/master/android/Readme.md up to
> date? I am trying to build latest master on a Fedora 34 machine.
>
> First error I got was that
>
> Android/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-clang
> did not exist. To fix that I soft linked the version specific file:
> $ ln -s aarch64-linux-android29-clang aarch64-linux-android-clang
>
> Then `make SDK=29 MODE=arm64 libs` produces:
>
> I have not used the command line variables in a long time. SDK=29 should
> not be necessary.
>
> In fact the SDK=XX mode may be broken. Not sure.
>
> Not sure about the override. shouldnt need to use the SDK=29 it should be
> the default. see setenv.sh.
>
> The NDK is still on 28. The layout changed and caused problems when I
> tried it.
>
> I have recently been trying QT5.15.2 but had some problems but there are a
> couple of fixes to the setenv script for detecting tool paths which I will
> attach for you to test. This is still on QT 5.14.1 but is sort of ready to
> go for qt 5.15.2 when I figure out the issue (some API change I think).
>
> Then all I do is run 'make libs' and then 'make' or 'make distclean
> everything'
>
> my buildrc will show you which NDK's Ive been trying. use android studio
> to install ndks with the correct version.
>
> Sorry Ive been lazy and havent commited some of these updates yet. Not
> happy yet with them and I dont want to break things.
>
> See how you go. But it does work for me.
>
> Mark
>

Hi Mark,

That got me a lot further. Unfortunately it is now failing trying to build
Qt 5.14.1 using build tools 29.0.3. Should I be using a different version?

Preparing build tree...
Creating qmake...
.....................................In file included from
/home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/qfloat16.h:1,
from
/home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/../../src/corelib/global/qendian.h:44,
from
/home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/qendian.h:1,
from
/home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/src/corelib/codecs/qutfcodec.cpp:43:
/home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:295:7:
error: ‘numeric_limits’ is not a class template
295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)> : public
numeric_limits<float>
| ^~~~~~~~~~~~~~
/home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:295:77:
error: expected template-name before ‘<’ token
295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)> : public
numeric_limits<float>
|
^
/home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:295:77:
error: expected ‘{’ before ‘<’ token
...

Thanks,

John

On 28/04/2021 10:54 am, John P Poet wrote:
>
>
> On Tue, Apr 27, 2021 at 5:40 PM Mark Spieth <mark@digivation.com.au
> <mailto:mark@digivation.com.au>> wrote:
>
> On 28/04/2021 6:52 am, John P Poet wrote:
>> Are the instructions @
>> https://github.com/MythTV/packaging/blob/master/android/Readme.md
>> <https://github.com/MythTV/packaging/blob/master/android/Readme.md>
>> up to date? I am trying to build latest master on a Fedora 34
>> machine.
>>
>> First error I got was that
>> Android/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-clang
>> did not exist. To fix that I soft linked the version specific file:
>> $ ln -s aarch64-linux-android29-clang aarch64-linux-android-clang
>>
>> Then `make SDK=29 MODE=arm64 libs` produces:
>
> I have not used the command line variables in a long time. SDK=29
> should not be necessary.
>
> In fact the SDK=XX mode may be broken. Not sure.
>
> Not sure about the override. shouldnt need to use the SDK=29 it
> should be the default. see setenv.sh.
>
> The NDK is still on 28. The layout changed and caused problems
> when I tried it.
>
> I have recently been trying QT5.15.2 but had some problems but
> there are a couple of fixes to the setenv script for detecting
> tool paths which I will attach for you to test. This is still on
> QT 5.14.1 but is sort of ready to go for qt 5.15.2 when I figure
> out the issue (some API change I think).
>
> Then all I do is run 'make libs' and then 'make' or 'make
> distclean everything'
>
> my buildrc will show you which NDK's Ive been trying. use android
> studio to install ndks with the correct version.
>
> Sorry Ive been lazy and havent commited some of these updates yet.
> Not happy yet with them and I dont want to break things.
>
> See how you go. But it does work for me.
>
> Mark
>
>
> Hi Mark,
>
> That got me a lot further. Unfortunately it is now failing trying to
> build Qt 5.14.1 using build tools 29.0.3. Should I be using a
> different version?
>
> Preparing build tree...
> Creating qmake...
> .....................................In file included from
> /home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/qfloat16.h:1,
>                  from
> /home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/../../src/corelib/global/qendian.h:44,
>                  from
> /home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/qendian.h:1,
>                  from
> /home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/src/corelib/codecs/qutfcodec.cpp:43:
> /home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:295:7:
> error: ‘numeric_limits’ is not a class template
>   295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)> : public
> numeric_limits<float>
>       |       ^~~~~~~~~~~~~~
> /home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:295:77:
> error: expected template-name before ‘<’ token
>   295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)> : public
> numeric_limits<float>
>       |                         ^
> /home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:295:77:
> error: expected ‘{’ before ‘<’ token
> ...
>
> Thanks,
>
> John

This sounds like an unsupported ndk version, compiler too new. I had
trouble with ndk 22.1.7171670 with similar results. The c++ headers are
a bit different I think but havent chased it down.

install one of the 21 ones. ~/Android/Sdk/ndk is where they live and you
can see what is installed.

I have 21.0.6113669 and 21.4.7075529 installed. both work for me.

HTH

Mark




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

On Wed, Apr 28, 2021 at 11:18:16AM +1000, Mark Spieth wrote:
> On 28/04/2021 10:54 am, John P Poet wrote:
> >
> >
> > On Tue, Apr 27, 2021 at 5:40 PM Mark Spieth <mark@digivation.com.au
> > <mailto:mark@digivation.com.au>> wrote:
> >
> > On 28/04/2021 6:52 am, John P Poet wrote:
> > > Are the instructions @
> > > https://github.com/MythTV/packaging/blob/master/android/Readme.md
> > > <https://github.com/MythTV/packaging/blob/master/android/Readme.md>
> > > up to date? I am trying to build latest master on a Fedora 34
> > > machine.
> > >
> > > First error I got was that
> > > Android/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-clang
> > > did not exist. To fix that I soft linked the version specific file:
> > > $ ln -s aarch64-linux-android29-clang aarch64-linux-android-clang
> > >
> > > Then `make SDK=29 MODE=arm64 libs` produces:
> >
> > I have not used the command line variables in a long time. SDK=29
> > should not be necessary.
> >
> > In fact the SDK=XX mode may be broken. Not sure.
> >
> > Not sure about the override. shouldnt need to use the SDK=29 it
> > should be the default. see setenv.sh.
> >
> > The NDK is still on 28. The layout changed and caused problems
> > when I tried it.
> >
> > I have recently been trying QT5.15.2 but had some problems but
> > there are a couple of fixes to the setenv script for detecting
> > tool paths which I will attach for you to test. This is still on
> > QT 5.14.1 but is sort of ready to go for qt 5.15.2 when I figure
> > out the issue (some API change I think).
> >
> > Then all I do is run 'make libs' and then 'make' or 'make
> > distclean everything'
> >
> > my buildrc will show you which NDK's Ive been trying. use android
> > studio to install ndks with the correct version.
> >
> > Sorry Ive been lazy and havent commited some of these updates yet.
> > Not happy yet with them and I dont want to break things.
> >
> > See how you go. But it does work for me.
> >
> > Mark
> >
> >
> > Hi Mark,
> >
> > That got me a lot further. Unfortunately it is now failing trying to
> > build Qt 5.14.1 using build tools 29.0.3. Should I be using a different
> > version?
> >
> > Preparing build tree...
> > Creating qmake...
> > .....................................In file included from /home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/qfloat16.h:1,
> >                  from /home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/../../src/corelib/global/qendian.h:44,
> >                  from /home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/qendian.h:1,
> >                  from /home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/src/corelib/codecs/qutfcodec.cpp:43:
> > /home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:295:7:
> > error: ‘numeric_limits’ is not a class template
> >   295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)> : public
> > numeric_limits<float>
> >       |       ^~~~~~~~~~~~~~
> > /home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:295:77:
> > error: expected template-name before ‘<’ token
> >   295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)> : public
> > numeric_limits<float>
> >       |                         ^
> > /home/john/src/Myth/Android/packaging/android/libs64/qt-everywhere-src-5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:295:77:
> > error: expected ‘{’ before ‘<’ token
> > ...
> >
> > Thanks,
> >
> > John
>
> This sounds like an unsupported ndk version, compiler too new. I had trouble
> with ndk 22.1.7171670 with similar results. The c++ headers are a bit
> different I think but havent chased it down.
>
> install one of the 21 ones. ~/Android/Sdk/ndk is where they live and you can
> see what is installed.
>
> I have 21.0.6113669 and 21.4.7075529 installed. both work for me.

I haven't rebuilt my libs in ages. In that past, that part has tended
to be fragile and best left alone for Mark to fix! :) It looks like I
last did that a little over a year ago with ndk 21.0.6113669.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, 2021-04-27 at 21:10 -0500, David Engel wrote:
> On Wed, Apr 28, 2021 at 11:18:16AM +1000, Mark Spieth wrote:
> > On 28/04/2021 10:54 am, John P Poet wrote:
> > >
> > >
> > > On Tue, Apr 27, 2021 at 5:40 PM Mark Spieth <
> > > mark@digivation.com.au
> > > <mailto:mark@digivation.com.au>> wrote:
> > >
> > >     On 28/04/2021 6:52 am, John P Poet wrote:
> > > >     Are the instructions @
> > > >    
> > > > https://github.com/MythTV/packaging/blob/master/android/Readme.md
> > > >     <
> > > > https://github.com/MythTV/packaging/blob/master/android/Readme.md
> > > > >
> > > >     up to date? I am trying to build latest master on a Fedora
> > > > 34
> > > >     machine.
> > > >
> > > >     First error I got was that
> > > >     Android/android-ndk/toolchains/llvm/prebuilt/linux-
> > > > x86_64/bin/aarch64-linux-android-clang
> > > >     did not exist. To fix that I soft linked the version
> > > > specific file:
> > > >     $ ln -s aarch64-linux-android29-clang aarch64-linux-
> > > > android-clang
> > > >
> > > >     Then `make SDK=29 MODE=arm64 libs` produces:
> > >
> > >     I have not used the command line variables in a long time.
> > > SDK=29
> > >     should not be necessary.
> > >
> > >     In fact the SDK=XX mode may be broken. Not sure.
> > >
> > >     Not sure about the override. shouldnt need to use the SDK=29
> > > it
> > >     should be the default. see setenv.sh.
> > >
> > >     The NDK is still on 28. The layout changed and caused
> > > problems
> > >     when I tried it.
> > >
> > >     I have recently been trying QT5.15.2 but had some problems
> > > but
> > >     there are a couple of fixes to the setenv script for
> > > detecting
> > >     tool paths which I will attach for you to test. This is still
> > > on
> > >     QT 5.14.1 but is sort of ready to go for qt 5.15.2 when I
> > > figure
> > >     out the issue (some API change I think).
> > >
> > >     Then all I do is run 'make libs' and then 'make' or 'make
> > >     distclean everything'
> > >
> > >     my buildrc will show you which NDK's Ive been trying. use
> > > android
> > >     studio to install ndks with the correct version.
> > >
> > >     Sorry Ive been lazy and havent commited some of these updates
> > > yet.
> > >     Not happy yet with them and I dont want to break things.
> > >
> > >     See how you go. But it does work for me.
> > >
> > >     Mark
> > >
> > >
> > > Hi Mark,
> > >
> > > That got me a lot further. Unfortunately it is now failing trying
> > > to
> > > build Qt 5.14.1 using build tools 29.0.3. Should I be using a
> > > different
> > > version?
> > >
> > > Preparing build tree...
> > > Creating qmake...
> > > .....................................In file included from
> > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > everywhere-src-5.14.1/qtbase/include/QtCore/qfloat16.h:1,
> > >                  from
> > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > everywhere-src-
> > > 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qendian.h:4
> > > 4,
> > >                  from
> > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > everywhere-src-5.14.1/qtbase/include/QtCore/qendian.h:1,
> > >                  from
> > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > everywhere-src-5.14.1/qtbase/src/corelib/codecs/qutfcodec.cpp:43:
> > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > everywhere-src-
> > > 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
> > > 295:7:
> > > error: ‘numeric_limits’ is not a class template
> > >   295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)> :
> > > public
> > > numeric_limits<float>
> > >       |       ^~~~~~~~~~~~~~
> > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > everywhere-src-
> > > 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
> > > 295:77:
> > > error: expected template-name before ‘<’ token
> > >   295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)> :
> > > public
> > > numeric_limits<float>
> > >       |                         ^
> > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > everywhere-src-
> > > 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
> > > 295:77:
> > > error: expected ‘{’ before ‘<’ token
> > > ...
> > >
> > > Thanks,
> > >
> > > John
> >
> > This sounds like an unsupported ndk version, compiler too new. I
> > had trouble
> > with ndk 22.1.7171670 with similar results. The c++ headers are a
> > bit
> > different I think but havent chased it down.
> >
> > install one of the 21 ones. ~/Android/Sdk/ndk is where they live
> > and you can
> > see what is installed.
> >
> > I have 21.0.6113669 and 21.4.7075529 installed. both work for me.
>
> I haven't rebuilt my libs in ages.  In that past, that part has
> tended
> to be fragile and best left alone for Mark to fix! :) It looks like I
> last did that a little over a year ago with ndk 21.0.6113669.
>
> David

I'm compiling regularly with ndk 21.0.6113669.

David H


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, Apr 27, 2021 at 8:56 PM David Hampton via mythtv-dev <
mythtv-dev@mythtv.org> wrote:

> On Tue, 2021-04-27 at 21:10 -0500, David Engel wrote:
> > On Wed, Apr 28, 2021 at 11:18:16AM +1000, Mark Spieth wrote:
> > > On 28/04/2021 10:54 am, John P Poet wrote:
> > > >
> > > >
> > > > On Tue, Apr 27, 2021 at 5:40 PM Mark Spieth <
> > > > mark@digivation.com.au
> > > > <mailto:mark@digivation.com.au>> wrote:
> > > >
> > > > On 28/04/2021 6:52 am, John P Poet wrote:
> > > > > Are the instructions @
> > > > >
> > > > > https://github.com/MythTV/packaging/blob/master/android/Readme.md
> > > > > <
> > > > > https://github.com/MythTV/packaging/blob/master/android/Readme.md
> > > > > >
> > > > > up to date? I am trying to build latest master on a Fedora
> > > > > 34
> > > > > machine.
> > > > >
> > > > > First error I got was that
> > > > > Android/android-ndk/toolchains/llvm/prebuilt/linux-
> > > > > x86_64/bin/aarch64-linux-android-clang
> > > > > did not exist. To fix that I soft linked the version
> > > > > specific file:
> > > > > $ ln -s aarch64-linux-android29-clang aarch64-linux-
> > > > > android-clang
> > > > >
> > > > > Then `make SDK=29 MODE=arm64 libs` produces:
> > > >
> > > > I have not used the command line variables in a long time.
> > > > SDK=29
> > > > should not be necessary.
> > > >
> > > > In fact the SDK=XX mode may be broken. Not sure.
> > > >
> > > > Not sure about the override. shouldnt need to use the SDK=29
> > > > it
> > > > should be the default. see setenv.sh.
> > > >
> > > > The NDK is still on 28. The layout changed and caused
> > > > problems
> > > > when I tried it.
> > > >
> > > > I have recently been trying QT5.15.2 but had some problems
> > > > but
> > > > there are a couple of fixes to the setenv script for
> > > > detecting
> > > > tool paths which I will attach for you to test. This is still
> > > > on
> > > > QT 5.14.1 but is sort of ready to go for qt 5.15.2 when I
> > > > figure
> > > > out the issue (some API change I think).
> > > >
> > > > Then all I do is run 'make libs' and then 'make' or 'make
> > > > distclean everything'
> > > >
> > > > my buildrc will show you which NDK's Ive been trying. use
> > > > android
> > > > studio to install ndks with the correct version.
> > > >
> > > > Sorry Ive been lazy and havent commited some of these updates
> > > > yet.
> > > > Not happy yet with them and I dont want to break things.
> > > >
> > > > See how you go. But it does work for me.
> > > >
> > > > Mark
> > > >
> > > >
> > > > Hi Mark,
> > > >
> > > > That got me a lot further. Unfortunately it is now failing trying
> > > > to
> > > > build Qt 5.14.1 using build tools 29.0.3. Should I be using a
> > > > different
> > > > version?
> > > >
> > > > Preparing build tree...
> > > > Creating qmake...
> > > > .....................................In file included from
> > > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > > everywhere-src-5.14.1/qtbase/include/QtCore/qfloat16.h:1,
> > > > from
> > > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > > everywhere-src-
> > > > 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qendian.h:4
> > > > 4,
> > > > from
> > > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > > everywhere-src-5.14.1/qtbase/include/QtCore/qendian.h:1,
> > > > from
> > > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > > everywhere-src-5.14.1/qtbase/src/corelib/codecs/qutfcodec.cpp:43:
> > > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > > everywhere-src-
> > > > 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
> > > > 295:7:
> > > > error: ‘numeric_limits’ is not a class template
> > > > 295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)> :
> > > > public
> > > > numeric_limits<float>
> > > > | ^~~~~~~~~~~~~~
> > > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > > everywhere-src-
> > > > 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
> > > > 295:77:
> > > > error: expected template-name before ‘<’ token
> > > > 295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)> :
> > > > public
> > > > numeric_limits<float>
> > > > | ^
> > > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > > everywhere-src-
> > > > 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
> > > > 295:77:
> > > > error: expected ‘{’ before ‘<’ token
> > > > ...
> > > >
> > > > Thanks,
> > > >
> > > > John
> > >
> > > This sounds like an unsupported ndk version, compiler too new. I
> > > had trouble
> > > with ndk 22.1.7171670 with similar results. The c++ headers are a
> > > bit
> > > different I think but havent chased it down.
> > >
> > > install one of the 21 ones. ~/Android/Sdk/ndk is where they live
> > > and you can
> > > see what is installed.
> > >
> > > I have 21.0.6113669 and 21.4.7075529 installed. both work for me.
> >
> > I haven't rebuilt my libs in ages. In that past, that part has
> > tended
> > to be fragile and best left alone for Mark to fix! :) It looks like I
> > last did that a little over a year ago with ndk 21.0.6113669.
> >
> > David
>
> I'm compiling regularly with ndk 21.0.6113669.
>
> David H
>

On Fedora? It looks like I am having to add
include <limits>
to various Qt headers. I am still figuring out all the headers where that
is necessary.

Thanks,

John

On Tue, 2021-04-27 at 21:18 -0600, John P Poet wrote:
>
>
> On Tue, Apr 27, 2021 at 8:56 PM David Hampton via mythtv-dev <
> mythtv-dev@mythtv.org> wrote:
> > On Tue, 2021-04-27 at 21:10 -0500, David Engel wrote:
> > > On Wed, Apr 28, 2021 at 11:18:16AM +1000, Mark Spieth wrote:
> > > > On 28/04/2021 10:54 am, John P Poet wrote:
> > > > >
> > > > >
> > > > > On Tue, Apr 27, 2021 at 5:40 PM Mark Spieth <
> > > > > mark@digivation.com.au
> > > > > <mailto:mark@digivation.com.au>> wrote:
> > > > >
> > > > >     On 28/04/2021 6:52 am, John P Poet wrote:
> > > > > >     Are the instructions @
> > > > > >    
> > > > > >
> > https://github.com/MythTV/packaging/blob/master/android/Readme.md
> > > > > >     <
> > > > > >
> > https://github.com/MythTV/packaging/blob/master/android/Readme.md
> > > > > > >
> > > > > >     up to date? I am trying to build latest master on a
> > Fedora
> > > > > > 34
> > > > > >     machine.
> > > > > >
> > > > > >     First error I got was that
> > > > > >     Android/android-ndk/toolchains/llvm/prebuilt/linux-
> > > > > > x86_64/bin/aarch64-linux-android-clang
> > > > > >     did not exist. To fix that I soft linked the version
> > > > > > specific file:
> > > > > >     $ ln -s aarch64-linux-android29-clang aarch64-linux-
> > > > > > android-clang
> > > > > >
> > > > > >     Then `make SDK=29 MODE=arm64 libs` produces:
> > > > >
> > > > >     I have not used the command line variables in a long
> > > > > time.
> > > > > SDK=29
> > > > >     should not be necessary.
> > > > >
> > > > >     In fact the SDK=XX mode may be broken. Not sure.
> > > > >
> > > > >     Not sure about the override. shouldnt need to use the
> > SDK=29
> > > > > it
> > > > >     should be the default. see setenv.sh.
> > > > >
> > > > >     The NDK is still on 28. The layout changed and caused
> > > > > problems
> > > > >     when I tried it.
> > > > >
> > > > >     I have recently been trying QT5.15.2 but had some
> > > > > problems
> > > > > but
> > > > >     there are a couple of fixes to the setenv script for
> > > > > detecting
> > > > >     tool paths which I will attach for you to test. This is
> > still
> > > > > on
> > > > >     QT 5.14.1 but is sort of ready to go for qt 5.15.2 when I
> > > > > figure
> > > > >     out the issue (some API change I think).
> > > > >
> > > > >     Then all I do is run 'make libs' and then 'make' or 'make
> > > > >     distclean everything'
> > > > >
> > > > >     my buildrc will show you which NDK's Ive been trying. use
> > > > > android
> > > > >     studio to install ndks with the correct version.
> > > > >
> > > > >     Sorry Ive been lazy and havent commited some of these
> > updates
> > > > > yet.
> > > > >     Not happy yet with them and I dont want to break things.
> > > > >
> > > > >     See how you go. But it does work for me.
> > > > >
> > > > >     Mark
> > > > >
> > > > >
> > > > > Hi Mark,
> > > > >
> > > > > That got me a lot further. Unfortunately it is now failing
> > trying
> > > > > to
> > > > > build Qt 5.14.1 using build tools 29.0.3. Should I be using a
> > > > > different
> > > > > version?
> > > > >
> > > > > Preparing build tree...
> > > > > Creating qmake...
> > > > > .....................................In file included from
> > > > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > > > everywhere-src-5.14.1/qtbase/include/QtCore/qfloat16.h:1,
> > > > >                  from
> > > > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > > > everywhere-src-
> > > > >
> > 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qendian.h:4
> > > > > 4,
> > > > >                  from
> > > > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > > > everywhere-src-5.14.1/qtbase/include/QtCore/qendian.h:1,
> > > > >                  from
> > > > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > > > everywhere-src-
> > 5.14.1/qtbase/src/corelib/codecs/qutfcodec.cpp:43:
> > > > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > > > everywhere-src-
> > > > >
> > 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
> > > > > 295:7:
> > > > > error: ‘numeric_limits’ is not a class template
> > > > >   295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)>
> > > > > :
> > > > > public
> > > > > numeric_limits<float>
> > > > >       |       ^~~~~~~~~~~~~~
> > > > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > > > everywhere-src-
> > > > >
> > 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
> > > > > 295:77:
> > > > > error: expected template-name before ‘<’ token
> > > > >   295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)>
> > > > > :
> > > > > public
> > > > > numeric_limits<float>
> > > > >       |                         ^
> > > > > /home/john/src/Myth/Android/packaging/android/libs64/qt-
> > > > > everywhere-src-
> > > > >
> > 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
> > > > > 295:77:
> > > > > error: expected ‘{’ before ‘<’ token
> > > > > ...
> > > > >
> > > > > Thanks,
> > > > >
> > > > > John
> > > >
> > > > This sounds like an unsupported ndk version, compiler too new.
> > > > I
> > > > had trouble
> > > > with ndk 22.1.7171670 with similar results. The c++ headers are
> > > > a
> > > > bit
> > > > different I think but havent chased it down.
> > > >
> > > > install one of the 21 ones. ~/Android/Sdk/ndk is where they
> > > > live
> > > > and you can
> > > > see what is installed.
> > > >
> > > > I have 21.0.6113669 and 21.4.7075529 installed. both work for
> > > > me.
> > >
> > > I haven't rebuilt my libs in ages.  In that past, that part has
> > > tended
> > > to be fragile and best left alone for Mark to fix! :) It looks
> > > like
> > I
> > > last did that a little over a year ago with ndk 21.0.6113669.
> > >
> > > David
> >
> > I'm compiling regularly with ndk 21.0.6113669.
> >
> > David H
> >
>
>
> On Fedora?  It looks like I am having to add 
> include <limits>
> to various Qt headers.  I am still figuring out all the headers where
> that is necessary.

Fedora 34, although I set it up under Fedora 33. I don't remember
having to do anything like that. It was quite easy compared to the
first time I set it up a two years ago. I just followed the
instructions in the Readme file.

Your missing clang executable sounds familiar. I think I started with a
more recent version of the ndk and saw problems like that. (I vaguely
remember trying to find the right executable for the compiler or
linker.) I'm pretty sure it was switching to the older ndk 21.0.6113669
that resolved all my problems.

David


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 28/04/2021 2:14 pm, David Hampton via mythtv-dev wrote:
> On Tue, 2021-04-27 at 21:18 -0600, John P Poet wrote:
>>
>> On Tue, Apr 27, 2021 at 8:56 PM David Hampton via mythtv-dev <
>> mythtv-dev@mythtv.org> wrote:
>>> On Tue, 2021-04-27 at 21:10 -0500, David Engel wrote:
>>>> On Wed, Apr 28, 2021 at 11:18:16AM +1000, Mark Spieth wrote:
>>>>> On 28/04/2021 10:54 am, John P Poet wrote:
>>>>>>
>>>>>> On Tue, Apr 27, 2021 at 5:40 PM Mark Spieth <
>>>>>> mark@digivation.com.au
>>>>>> <mailto:mark@digivation.com.au>> wrote:
>>>>>>
>>>>>>     On 28/04/2021 6:52 am, John P Poet wrote:
>>>>>>>     Are the instructions @
>>>>>>>
>>>>>>>
>>> https://github.com/MythTV/packaging/blob/master/android/Readme.md
>>>>>>>     <
>>>>>>>
>>> https://github.com/MythTV/packaging/blob/master/android/Readme.md
>>>>>>>     up to date? I am trying to build latest master on a
>>> Fedora
>>>>>>> 34
>>>>>>>     machine.
>>>>>>>
>>>>>>>     First error I got was that
>>>>>>>     Android/android-ndk/toolchains/llvm/prebuilt/linux-
>>>>>>> x86_64/bin/aarch64-linux-android-clang
>>>>>>>     did not exist. To fix that I soft linked the version
>>>>>>> specific file:
>>>>>>>     $ ln -s aarch64-linux-android29-clang aarch64-linux-
>>>>>>> android-clang
>>>>>>>
>>>>>>>     Then `make SDK=29 MODE=arm64 libs` produces:
>>>>>>     I have not used the command line variables in a long
>>>>>> time.
>>>>>> SDK=29
>>>>>>     should not be necessary.
>>>>>>
>>>>>>     In fact the SDK=XX mode may be broken. Not sure.
>>>>>>
>>>>>>     Not sure about the override. shouldnt need to use the
>>> SDK=29
>>>>>> it
>>>>>>     should be the default. see setenv.sh.
>>>>>>
>>>>>>     The NDK is still on 28. The layout changed and caused
>>>>>> problems
>>>>>>     when I tried it.
>>>>>>
>>>>>>     I have recently been trying QT5.15.2 but had some
>>>>>> problems
>>>>>> but
>>>>>>     there are a couple of fixes to the setenv script for
>>>>>> detecting
>>>>>>     tool paths which I will attach for you to test. This is
>>> still
>>>>>> on
>>>>>>     QT 5.14.1 but is sort of ready to go for qt 5.15.2 when I
>>>>>> figure
>>>>>>     out the issue (some API change I think).
>>>>>>
>>>>>>     Then all I do is run 'make libs' and then 'make' or 'make
>>>>>>     distclean everything'
>>>>>>
>>>>>>     my buildrc will show you which NDK's Ive been trying. use
>>>>>> android
>>>>>>     studio to install ndks with the correct version.
>>>>>>
>>>>>>     Sorry Ive been lazy and havent commited some of these
>>> updates
>>>>>> yet.
>>>>>>     Not happy yet with them and I dont want to break things.
>>>>>>
>>>>>>     See how you go. But it does work for me.
>>>>>>
>>>>>>     Mark
>>>>>>
>>>>>>
>>>>>> Hi Mark,
>>>>>>
>>>>>> That got me a lot further. Unfortunately it is now failing
>>> trying
>>>>>> to
>>>>>> build Qt 5.14.1 using build tools 29.0.3. Should I be using a
>>>>>> different
>>>>>> version?
>>>>>>
>>>>>> Preparing build tree...
>>>>>> Creating qmake...
>>>>>> .....................................In file included from
>>>>>> /home/john/src/Myth/Android/packaging/android/libs64/qt-
>>>>>> everywhere-src-5.14.1/qtbase/include/QtCore/qfloat16.h:1,
>>>>>>                  from
>>>>>> /home/john/src/Myth/Android/packaging/android/libs64/qt-
>>>>>> everywhere-src-
>>>>>>
>>> 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qendian.h:4
>>>>>> 4,
>>>>>>                  from
>>>>>> /home/john/src/Myth/Android/packaging/android/libs64/qt-
>>>>>> everywhere-src-5.14.1/qtbase/include/QtCore/qendian.h:1,
>>>>>>                  from
>>>>>> /home/john/src/Myth/Android/packaging/android/libs64/qt-
>>>>>> everywhere-src-
>>> 5.14.1/qtbase/src/corelib/codecs/qutfcodec.cpp:43:
>>>>>> /home/john/src/Myth/Android/packaging/android/libs64/qt-
>>>>>> everywhere-src-
>>>>>>
>>> 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
>>>>>> 295:7:
>>>>>> error: ‘numeric_limits’ is not a class template
>>>>>>   295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)>
>>>>>> :
>>>>>> public
>>>>>> numeric_limits<float>
>>>>>>       |       ^~~~~~~~~~~~~~
>>>>>> /home/john/src/Myth/Android/packaging/android/libs64/qt-
>>>>>> everywhere-src-
>>>>>>
>>> 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
>>>>>> 295:77:
>>>>>> error: expected template-name before ‘<’ token
>>>>>>   295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)>
>>>>>> :
>>>>>> public
>>>>>> numeric_limits<float>
>>>>>>       |                         ^
>>>>>> /home/john/src/Myth/Android/packaging/android/libs64/qt-
>>>>>> everywhere-src-
>>>>>>
>>> 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
>>>>>> 295:77:
>>>>>> error: expected ‘{’ before ‘<’ token
>>>>>> ...
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> John
>>>>> This sounds like an unsupported ndk version, compiler too new.
>>>>> I
>>>>> had trouble
>>>>> with ndk 22.1.7171670 with similar results. The c++ headers are
>>>>> a
>>>>> bit
>>>>> different I think but havent chased it down.
>>>>>
>>>>> install one of the 21 ones. ~/Android/Sdk/ndk is where they
>>>>> live
>>>>> and you can
>>>>> see what is installed.
>>>>>
>>>>> I have 21.0.6113669 and 21.4.7075529 installed. both work for
>>>>> me.
>>>> I haven't rebuilt my libs in ages.  In that past, that part has
>>>> tended
>>>> to be fragile and best left alone for Mark to fix! :) It looks
>>>> like
>>> I
>>>> last did that a little over a year ago with ndk 21.0.6113669.
>>>>
>>>> David
>>> I'm compiling regularly with ndk 21.0.6113669.
>>>
>>> David H
>>>
>>
>> On Fedora?  It looks like I am having to add
>> include <limits>
>> to various Qt headers.  I am still figuring out all the headers where
>> that is necessary.
> Fedora 34, although I set it up under Fedora 33. I don't remember
> having to do anything like that. It was quite easy compared to the
> first time I set it up a two years ago. I just followed the
> instructions in the Readme file.
>
> Your missing clang executable sounds familiar. I think I started with a
> more recent version of the ndk and saw problems like that. (I vaguely
> remember trying to find the right executable for the compiler or
> linker.) I'm pretty sure it was switching to the older ndk 21.0.6113669
> that resolved all my problems.
>
>
I know what the problem is, your compiler clang or gc++ is too new for
the host build part.

Try with a slightly older gcc/clang host compiler. The cross compiler is
tightly constrained so that should not be the problem.

Mark



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 4/28/21 12:23 AM, Mark Spieth wrote:
> I know what the problem is, your compiler clang or gc++ is too new for
> the host build part.
>
> Try with a slightly older gcc/clang host compiler. The cross compiler
> is tightly constrained so that should not be the problem.
>
> Mark

I recently rebuilt it on a new computer.

I tried the newest ndk and I got to an error where building one of the
libs created a ".a" file but not a ".so" file in spite of being built
for dynamic linking.

I eventually succeeded with ndk 21.0.6113669

If you change ndk you have to rebuild everything. If you build the libs
with one ndk and the app with another, bad things happen.

If you switch from building v31 to building master you have to build the
libs again. I keep separate copies of the packaging directory for each
version to solve this.

Make sure you checkout the matching version (fixes/31 or master) from
packaging as well as from mythtv when building. This has caught me a few
times.

At one point my link android-sdk-linux -> Sdk disappeared (a gremlin
deleted it or I forgot to create it?) and strange error messages resulted.

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 28/04/2021 17:52, Peter Bennett wrote:
>
> At one point my link android-sdk-linux -> Sdk disappeared (a gremlin
> deleted it or I forgot to create it?) and strange error messages resulted.
>

Out of interest, why do we require random symlinks like this???

It is one of my pet hates, perhaps irrationally, to have a requirement
for such a link.


Regards
Stuart

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, Apr 27, 2021, 9:24 PM Mark Spieth <mark@digivation.com.au> wrote:

> On 28/04/2021 2:14 pm, David Hampton via mythtv-dev wrote:
> > On Tue, 2021-04-27 at 21:18 -0600, John P Poet wrote:
> >>
> >> On Tue, Apr 27, 2021 at 8:56 PM David Hampton via mythtv-dev <
> >> mythtv-dev@mythtv.org> wrote:
> >>> On Tue, 2021-04-27 at 21:10 -0500, David Engel wrote:
> >>>> On Wed, Apr 28, 2021 at 11:18:16AM +1000, Mark Spieth wrote:
> >>>>> On 28/04/2021 10:54 am, John P Poet wrote:
> >>>>>>
> >>>>>> On Tue, Apr 27, 2021 at 5:40 PM Mark Spieth <
> >>>>>> mark@digivation.com.au
> >>>>>> <mailto:mark@digivation.com.au>> wrote:
> >>>>>>
> >>>>>> On 28/04/2021 6:52 am, John P Poet wrote:
> >>>>>>> Are the instructions @
> >>>>>>>
> >>>>>>>
> >>> https://github.com/MythTV/packaging/blob/master/android/Readme.md
> >>>>>>> <
> >>>>>>>
> >>> https://github.com/MythTV/packaging/blob/master/android/Readme.md
> >>>>>>> up to date? I am trying to build latest master on a
> >>> Fedora
> >>>>>>> 34
> >>>>>>> machine.
> >>>>>>>
> >>>>>>> First error I got was that
> >>>>>>> Android/android-ndk/toolchains/llvm/prebuilt/linux-
> >>>>>>> x86_64/bin/aarch64-linux-android-clang
> >>>>>>> did not exist. To fix that I soft linked the version
> >>>>>>> specific file:
> >>>>>>> $ ln -s aarch64-linux-android29-clang aarch64-linux-
> >>>>>>> android-clang
> >>>>>>>
> >>>>>>> Then `make SDK=29 MODE=arm64 libs` produces:
> >>>>>> I have not used the command line variables in a long
> >>>>>> time.
> >>>>>> SDK=29
> >>>>>> should not be necessary.
> >>>>>>
> >>>>>> In fact the SDK=XX mode may be broken. Not sure.
> >>>>>>
> >>>>>> Not sure about the override. shouldnt need to use the
> >>> SDK=29
> >>>>>> it
> >>>>>> should be the default. see setenv.sh.
> >>>>>>
> >>>>>> The NDK is still on 28. The layout changed and caused
> >>>>>> problems
> >>>>>> when I tried it.
> >>>>>>
> >>>>>> I have recently been trying QT5.15.2 but had some
> >>>>>> problems
> >>>>>> but
> >>>>>> there are a couple of fixes to the setenv script for
> >>>>>> detecting
> >>>>>> tool paths which I will attach for you to test. This is
> >>> still
> >>>>>> on
> >>>>>> QT 5.14.1 but is sort of ready to go for qt 5.15.2 when I
> >>>>>> figure
> >>>>>> out the issue (some API change I think).
> >>>>>>
> >>>>>> Then all I do is run 'make libs' and then 'make' or 'make
> >>>>>> distclean everything'
> >>>>>>
> >>>>>> my buildrc will show you which NDK's Ive been trying. use
> >>>>>> android
> >>>>>> studio to install ndks with the correct version.
> >>>>>>
> >>>>>> Sorry Ive been lazy and havent commited some of these
> >>> updates
> >>>>>> yet.
> >>>>>> Not happy yet with them and I dont want to break things.
> >>>>>>
> >>>>>> See how you go. But it does work for me.
> >>>>>>
> >>>>>> Mark
> >>>>>>
> >>>>>>
> >>>>>> Hi Mark,
> >>>>>>
> >>>>>> That got me a lot further. Unfortunately it is now failing
> >>> trying
> >>>>>> to
> >>>>>> build Qt 5.14.1 using build tools 29.0.3. Should I be using a
> >>>>>> different
> >>>>>> version?
> >>>>>>
> >>>>>> Preparing build tree...
> >>>>>> Creating qmake...
> >>>>>> .....................................In file included from
> >>>>>> /home/john/src/Myth/Android/packaging/android/libs64/qt-
> >>>>>> everywhere-src-5.14.1/qtbase/include/QtCore/qfloat16.h:1,
> >>>>>> from
> >>>>>> /home/john/src/Myth/Android/packaging/android/libs64/qt-
> >>>>>> everywhere-src-
> >>>>>>
> >>> 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qendian.h:4
> >>>>>> 4,
> >>>>>> from
> >>>>>> /home/john/src/Myth/Android/packaging/android/libs64/qt-
> >>>>>> everywhere-src-5.14.1/qtbase/include/QtCore/qendian.h:1,
> >>>>>> from
> >>>>>> /home/john/src/Myth/Android/packaging/android/libs64/qt-
> >>>>>> everywhere-src-
> >>> 5.14.1/qtbase/src/corelib/codecs/qutfcodec.cpp:43:
> >>>>>> /home/john/src/Myth/Android/packaging/android/libs64/qt-
> >>>>>> everywhere-src-
> >>>>>>
> >>> 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
> >>>>>> 295:7:
> >>>>>> error: ‘numeric_limits’ is not a class template
> >>>>>> 295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)>
> >>>>>> :
> >>>>>> public
> >>>>>> numeric_limits<float>
> >>>>>> | ^~~~~~~~~~~~~~
> >>>>>> /home/john/src/Myth/Android/packaging/android/libs64/qt-
> >>>>>> everywhere-src-
> >>>>>>
> >>> 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
> >>>>>> 295:77:
> >>>>>> error: expected template-name before ‘<’ token
> >>>>>> 295 | class numeric_limits<QT_PREPEND_NAMESPACE(qfloat16)>
> >>>>>> :
> >>>>>> public
> >>>>>> numeric_limits<float>
> >>>>>> | ^
> >>>>>> /home/john/src/Myth/Android/packaging/android/libs64/qt-
> >>>>>> everywhere-src-
> >>>>>>
> >>> 5.14.1/qtbase/include/QtCore/../../src/corelib/global/qfloat16.h:
> >>>>>> 295:77:
> >>>>>> error: expected ‘{’ before ‘<’ token
> >>>>>> ...
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> John
> >>>>> This sounds like an unsupported ndk version, compiler too new.
> >>>>> I
> >>>>> had trouble
> >>>>> with ndk 22.1.7171670 with similar results. The c++ headers are
> >>>>> a
> >>>>> bit
> >>>>> different I think but havent chased it down.
> >>>>>
> >>>>> install one of the 21 ones. ~/Android/Sdk/ndk is where they
> >>>>> live
> >>>>> and you can
> >>>>> see what is installed.
> >>>>>
> >>>>> I have 21.0.6113669 and 21.4.7075529 installed. both work for
> >>>>> me.
> >>>> I haven't rebuilt my libs in ages. In that past, that part has
> >>>> tended
> >>>> to be fragile and best left alone for Mark to fix! :) It looks
> >>>> like
> >>> I
> >>>> last did that a little over a year ago with ndk 21.0.6113669.
> >>>>
> >>>> David
> >>> I'm compiling regularly with ndk 21.0.6113669.
> >>>
> >>> David H
> >>>
> >>
> >> On Fedora? It looks like I am having to add
> >> include <limits>
> >> to various Qt headers. I am still figuring out all the headers where
> >> that is necessary.
> > Fedora 34, although I set it up under Fedora 33. I don't remember
> > having to do anything like that. It was quite easy compared to the
> > first time I set it up a two years ago. I just followed the
> > instructions in the Readme file.
> >
> > Your missing clang executable sounds familiar. I think I started with a
> > more recent version of the ndk and saw problems like that. (I vaguely
> > remember trying to find the right executable for the compiler or
> > linker.) I'm pretty sure it was switching to the older ndk 21.0.6113669
> > that resolved all my problems.
> >
> >
> I know what the problem is, your compiler clang or gc++ is too new for
> the host build part.
>
> Try with a slightly older gcc/clang host compiler. The cross compiler is
> tightly constrained so that should not be the problem.
>
> Mark


I was able to get Qt built by adding
include <limits>
to qtbase/include/QtCore/qfloat16.h and
qtbase/src/corelib/text/qbytearraymatcher.h

mythfrontend seems to be running fine on my sister's nVidia Shield with
latest master.

Thanks for your help Mark.

John

On Wed, Apr 28, 2021 at 08:47:42PM +0100, Stuart Auchterlonie wrote:
> On 28/04/2021 17:52, Peter Bennett wrote:
> >
> > At one point my link android-sdk-linux -> Sdk disappeared (a gremlin
> > deleted it or I forgot to create it?) and strange error messages
> > resulted.
> >
>
> Out of interest, why do we require random symlinks like this???
>
> It is one of my pet hates, perhaps irrationally, to have a requirement
> for such a link.

Good question. I'm not sure if (old?) Android was setup that way at
one time and old habits die hard or that's simply how Mark Spieth was
used to doing things. At one time, I had a pet, side project to
create an overall Makefile that would bypass all that and use make
variables read read from config.mak files. The goal was to more
easily support multiple builds with different library versions, NDKs,
SDKs, etc. I didn't get very far and quickly lost interest.
Everything seemed so fragile and once a working configuration was
found, it was best to leave it as is.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 29/04/2021 12:11 pm, David Engel wrote:
> On Wed, Apr 28, 2021 at 08:47:42PM +0100, Stuart Auchterlonie wrote:
>> On 28/04/2021 17:52, Peter Bennett wrote:
>>> At one point my link android-sdk-linux -> Sdk disappeared (a gremlin
>>> deleted it or I forgot to create it?) and strange error messages
>>> resulted.
>>>
>> Out of interest, why do we require random symlinks like this???
>>
>> It is one of my pet hates, perhaps irrationally, to have a requirement
>> for such a link.
> Good question. I'm not sure if (old?) Android was setup that way at
> one time and old habits die hard or that's simply how Mark Spieth was
> used to doing things. At one time, I had a pet, side project to
> create an overall Makefile that would bypass all that and use make
> variables read read from config.mak files. The goal was to more
> easily support multiple builds with different library versions, NDKs,
> SDKs, etc. I didn't get very far and quickly lost interest.
> Everything seemed so fragile and once a working configuration was
> found, it was best to leave it as is.
>
Face it, I just don't know what I'm doing :-) so its all a hack job,
staring off with lawrence's windows builder.

And cleanup was never high on the priority list.

IIRC I started off with separate sdk and ndk and then they created studio
which made life easier but the rest stayed in case I had to go back.

I commend anyone that wants to clean it up. Peter has already had a go
and its better than it was.

At least there is a Makefile now.

Mark



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Thu, Apr 29, 2021 at 05:47:35PM +1000, Mark Spieth wrote:
> On 29/04/2021 12:11 pm, David Engel wrote:
> > On Wed, Apr 28, 2021 at 08:47:42PM +0100, Stuart Auchterlonie wrote:
> > > Out of interest, why do we require random symlinks like this???
> > >
> > > It is one of my pet hates, perhaps irrationally, to have a requirement
> > > for such a link.
> > Good question. I'm not sure if (old?) Android was setup that way at
> > one time and old habits die hard or that's simply how Mark Spieth was
> > used to doing things. At one time, I had a pet, side project to
> > create an overall Makefile that would bypass all that and use make
> > variables read read from config.mak files. The goal was to more
> > easily support multiple builds with different library versions, NDKs,
> > SDKs, etc. I didn't get very far and quickly lost interest.
> > Everything seemed so fragile and once a working configuration was
> > found, it was best to leave it as is.
> >
> Face it, I just don't know what I'm doing :-) so its all a hack job, staring
> off with lawrence's windows builder.

I had quite a bit of trepidation when adding that comment above. For
the record, I greatly admire all the work you did making the Android
port work. It's been my family's, main frontend for 2.5 (I think)
years now.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 4/30/23 19:34, John P Poet wrote:
> Hi Peter,
>
> When you have time can you please upload a new version of Android
> mythfrontend? It looks like the DB schema changed sometime in the last
> couple of months.
>
> I tried to build it myself, but had no luck. It fails to build
> libbluray. If I tell it to skip libbluray, then It seems to mostly
> build qt but then gives a nebulous error. I have a feeling the problem
> is based in the fact that I am a Fedora user instead of Ubuntu.
>
>     [javac] warning: [options] bootstrap class path not set in
> conjunction with -source 5
>     [javac] error: Source option 5 is no longer supported. Use 7 or later.
>     [javac] error: Target option 5 is no longer supported. Use 7 or later.
>
> I have limited experience with Docker, but that seems like it might be
> an interesting method to get the libs to build if it is indeed a
> problem with Fedora. Maybe I will look into that if I ever have the
> time to commit to it. I suppose I should try a VM to see if I can get
> it to build under ubuntu.
>
> Thanks,
>
> John
>
>
HI John

I have built the latest master for android 32bit and 64bit and added
them to the download area at https://dl.orangedox.com/pCBmBm

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 1/05/2023 10:18 am, Peter Bennett wrote:
>
> On 4/30/23 19:34, John P Poet wrote:
>> Hi Peter,
>>
>> When you have time can you please upload a new version of Android
>> mythfrontend? It looks like the DB schema changed sometime in the
>> last couple of months.
>>
>> I tried to build it myself, but had no luck. It fails to build
>> libbluray. If I tell it to skip libbluray, then It seems to mostly
>> build qt but then gives a nebulous error. I have a feeling the
>> problem is based in the fact that I am a Fedora user instead of Ubuntu.
>>
>>     [javac] warning: [options] bootstrap class path not set in
>> conjunction with -source 5
>>     [javac] error: Source option 5 is no longer supported. Use 7 or
>> later.
>>     [javac] error: Target option 5 is no longer supported. Use 7 or
>> later.
>>
>> I have limited experience with Docker, but that seems like it might
>> be an interesting method to get the libs to build if it is indeed a
>> problem with Fedora. Maybe I will look into that if I ever have the
>> time to commit to it. I suppose I should try a VM to see if I can get
>> it to build under ubuntu.
>>
>> Thanks,
>>
>> John
>>
>>
> HI John
>
> I have built the latest master for android 32bit and 64bit and added
> them to the download area at https://dl.orangedox.com/pCBmBm
>
> Peter

There should be no libraries that are not explicitly versioned for the
android build. Everything is pulled down explicitly. You only need the
toolchain with a supported NDK and SDK.

Should we consider building with DB check disabled. I've always done
this and it works perfectly. Eliminates backend update schema change
problems.

Mark

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Thank you Peter.

On Sun, Apr 30, 2023 at 5:19?PM Peter Bennett <pb.mythtv@gmail.com> wrote:

>
> On 4/30/23 19:34, John P Poet wrote:
> > Hi Peter,
> >
> > When you have time can you please upload a new version of Android
> > mythfrontend? It looks like the DB schema changed sometime in the last
> > couple of months.
> >
> > I tried to build it myself, but had no luck. It fails to build
> > libbluray. If I tell it to skip libbluray, then It seems to mostly
> > build qt but then gives a nebulous error. I have a feeling the problem
> > is based in the fact that I am a Fedora user instead of Ubuntu.
> >
> > [javac] warning: [options] bootstrap class path not set in
> > conjunction with -source 5
> > [javac] error: Source option 5 is no longer supported. Use 7 or
> later.
> > [javac] error: Target option 5 is no longer supported. Use 7 or
> later.
> >
> > I have limited experience with Docker, but that seems like it might be
> > an interesting method to get the libs to build if it is indeed a
> > problem with Fedora. Maybe I will look into that if I ever have the
> > time to commit to it. I suppose I should try a VM to see if I can get
> > it to build under ubuntu.
> >
> > Thanks,
> >
> > John
> >
> >
> HI John
>
> I have built the latest master for android 32bit and 64bit and added
> them to the download area at https://dl.orangedox.com/pCBmBm
>
> Peter
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

On 4/30/23 20:47, Mark Spieth wrote:
> Should we consider building with DB check disabled. I've always done
> this and it works perfectly. Eliminates backend update schema change
> problems.

https://lists.archive.carbon60.com/mythtv/dev/627818

Also, around January 2019 developed a change that would allow disabling
schema check or protocol version check from settings. I proposed it at
the time but it was not popular among the developers. I still have that
patch.

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, 1 May 2023 at 15:06, Peter Bennett <pb.mythtv@gmail.com> wrote:

>
> On 4/30/23 20:47, Mark Spieth wrote:
> > Should we consider building with DB check disabled. I've always done
> > this and it works perfectly. Eliminates backend update schema change
> > problems.
>
> https://lists.archive.carbon60.com/mythtv/dev/627818
>
> Also, around January 2019 developed a change that would allow disabling
> schema check or protocol version check from settings. I proposed it at
> the time but it was not popular among the developers. I still have that
> patch.
>
> Peter
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org


I was thinking about adding a command line option for mythfrontend to
disable database version checking.
Using a setting that is stored in the database does not really work if the
database has been updated already.

Klaas.

On 5/1/23 13:36, Klaas de Waal wrote:
> I was thinking about adding a command line option for mythfrontend to
> disable database version checking.
> Using a setting that is stored in the database does not really work if
> the database has been updated already.
>
These were my ideas:

- the setting could be applied as a command line option via the -O
option on startup of the frontend, or by updating the settings table
using a database tool.

- For android, it could be done using a database tool to update the
settings table, since it is not easy to supply command line options with
android.

I was really only for power users. They would have to be aware of the
risks. Normal users using the released versions of MythTV would not hit
the problem of schema mismatches.

Note you cannot override the database version with the -O option. There
is code to prevent that in MythTV.

Peter


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, 1 May 2023 at 20:26, Peter Bennett <pb.mythtv@gmail.com> wrote:

>
> On 5/1/23 13:36, Klaas de Waal wrote:
> > I was thinking about adding a command line option for mythfrontend to
> > disable database version checking.
> > Using a setting that is stored in the database does not really work if
> > the database has been updated already.
> >
> These were my ideas:
>
> - the setting could be applied as a command line option via the -O
> option on startup of the frontend, or by updating the settings table
> using a database tool.
>

Sounds good to me. We could even add a menu item just for convenience.
With a bit of warning in the help text of course.
One more step towards getting it to "just work".


>
> - For android, it could be done using a database tool to update the
> settings table, since it is not easy to supply command line options with
> android.
>
> I was really only for power users. They would have to be aware of the
> risks. Normal users using the released versions of MythTV would not hit
> the problem of schema mismatches.
>
> Note you cannot override the database version with the -O option. There
> is code to prevent that in MythTV.
>
> Peter
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org



Klaas.

On Mon, May 1, 2023 at 9:35?PM Klaas de Waal <klaas.de.waal@gmail.com> wrote:

> Sounds good to me. We could even add a menu item just for convenience.
> With a bit of warning in the help text of course.
> One more step towards getting it to "just work".

Or "just break without clue" if some
future schema changes turns out to
be significant enough (including,
possibly, resulting in "corruption",
as some of the past changes have
re-formatted existing data in the
tables, and if the frontend updates
those tables in the old way there is
no way that it will get fixed again
as part of the original schema
change, since that already happened).

If the database schema is wrong
and you want to allow things to
start up, you should put the
database into read-only mode
to insure no corruption.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 2/05/2023 7:49 am, Gary Buhrmaster wrote:
> On Mon, May 1, 2023 at 9:35?PM Klaas de Waal <klaas.de.waal@gmail.com> wrote:
>
>> Sounds good to me. We could even add a menu item just for convenience.
>> With a bit of warning in the help text of course.
>> One more step towards getting it to "just work".
> Or "just break without clue" if some
> future schema changes turns out to
> be significant enough (including,
> possibly, resulting in "corruption",
> as some of the past changes have
> re-formatted existing data in the
> tables, and if the frontend updates
> those tables in the old way there is
> no way that it will get fixed again
> as part of the original schema
> change, since that already happened).
>
> If the database schema is wrong
> and you want to allow things to
> start up, you should put the
> database into read-only mode
> to insure no corruption.

That can happen too. However I've never seen it in practice. It does
require that the backend and frontend are reasonably closely matched,
which is often the case.

Another way is in the config.xml (which is local) which is what I think
Peter was referring to.

Would it be worthwhile to try to get the app in to the store? With the
above feature, it wouldn't be  such an issue with DB version matching
and selection.

Mark


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, May 02, 2023 at 08:13:08AM +1000, Mark Spieth wrote:
> On 2/05/2023 7:49 am, Gary Buhrmaster wrote:
> > On Mon, May 1, 2023 at 9:35?PM Klaas de Waal <klaas.de.waal@gmail.com> wrote:
> >
> > > Sounds good to me. We could even add a menu item just for convenience.
> > > With a bit of warning in the help text of course.
> > > One more step towards getting it to "just work".
> > Or "just break without clue" if some
> > future schema changes turns out to
> > be significant enough (including,
> > possibly, resulting in "corruption",
> > as some of the past changes have
> > re-formatted existing data in the
> > tables, and if the frontend updates
> > those tables in the old way there is
> > no way that it will get fixed again
> > as part of the original schema
> > change, since that already happened).
> >
> > If the database schema is wrong
> > and you want to allow things to
> > start up, you should put the
> > database into read-only mode
> > to insure no corruption.
>
> That can happen too. However I've never seen it in practice. It does require
> that the backend and frontend are reasonably closely matched, which is often
> the case.

It can definitely happen but the severity of the ensuing carnage
greatly depends on the exact, schema changes. That's one reason we
should try to make the frontend use API calls exclusively or at least
as much as possible. It would hopefully force us to improve API
compatibility and shield it from schema changes.

> Another way is in the config.xml (which is local) which is what I think
> Peter was referring to.
>
> Would it be worthwhile to try to get the app in to the store? With the above
> feature, it wouldn't be  such an issue with DB version matching and
> selection.

Someone looked into getting into the play store a long time ago. It
might have been Peter but I'm certainly not sure. As I recall, it
would not be a quick and simple task.

I believe one stumbling block would be supporting multiple backend
versions. Until the frontend is API'ized, each backend version would
probably have to have its own, frontend app. I seem to recall that
being frowned upon by Google, but as infrequently as MythTV is
officially released, it might not be a deal breaker.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 5/1/23 19:19, David Engel wrote:
> On Tue, May 02, 2023 at 08:13:08AM +1000, Mark Spieth wrote:
>> On 2/05/2023 7:49 am, Gary Buhrmaster wrote:
>>> On Mon, May 1, 2023 at 9:35?PM Klaas de Waal <klaas.de.waal@gmail.com> wrote:
>>>
>>>> Sounds good to me. We could even add a menu item just for convenience.
>>>> With a bit of warning in the help text of course.
>>>> One more step towards getting it to "just work".
>>> Or "just break without clue" if some
>>> future schema changes turns out to
>>> be significant enough (including,
>>> possibly, resulting in "corruption",
>>> as some of the past changes have
>>> re-formatted existing data in the
>>> tables, and if the frontend updates
>>> those tables in the old way there is
>>> no way that it will get fixed again
>>> as part of the original schema
>>> change, since that already happened).
>>>
>>> If the database schema is wrong
>>> and you want to allow things to
>>> start up, you should put the
>>> database into read-only mode
>>> to insure no corruption.
>> That can happen too. However I've never seen it in practice. It does require
>> that the backend and frontend are reasonably closely matched, which is often
>> the case.
> It can definitely happen but the severity of the ensuing carnage
> greatly depends on the exact, schema changes. That's one reason we
> should try to make the frontend use API calls exclusively or at least
> as much as possible. It would hopefully force us to improve API
> compatibility and shield it from schema changes.
>
>> Another way is in the config.xml (which is local) which is what I think
>> Peter was referring to.
>>
>> Would it be worthwhile to try to get the app in to the store? With the above
>> feature, it wouldn't be  such an issue with DB version matching and
>> selection.
> Someone looked into getting into the play store a long time ago. It
> might have been Peter but I'm certainly not sure. As I recall, it
> would not be a quick and simple task.
>
> I believe one stumbling block would be supporting multiple backend
> versions. Until the frontend is API'ized, each backend version would
> probably have to have its own, frontend app. I seem to recall that
> being frowned upon by Google, but as infrequently as MythTV is
> officially released, it might not be a deal breaker.
>
> David

I looked into the play store, for mythbackend and also for leanfront.
From what I found, Android and Amazon are far more strict about the app
store for android TV than for regular android for phones and tablets.
They want to review and test each TV application before approving it.
This would be impossible without a working MythTV backend. Looking at
the list of requirements for adding it to the store, I became
discouraged with the number of difficult or impossible requirements.

One requirement is that all apps use exclusively SSL, for security
reasons. This would be impossible, every user would have to purchase a
domain, install DNS and purchase a certificate for their backend.

These things may have changed in the meantime, that was a couple of
years ago.

I did design leanfront to support any MythTV version. It only uses the
API. Every time there is an API that may be missing or different in
older MythTV versions, it checks and caters for it.

Peter
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, May 2, 2023 at 12:54?AM Peter Bennett <pb.mythtv@gmail.com> wrote:

> I looked into the play store, for mythbackend and also for leanfront.
> From what I found, Android and Amazon are far more strict about the app
> store for android TV than for regular android for phones and tablets.
> They want to review and test each TV application before approving it.
> This would be impossible without a working MythTV backend. Looking at
> the list of requirements for adding it to the store, I became
> discouraged with the number of difficult or impossible requirements.


In addition, any inclusion of any licensed technologies
included in the app will be expected (required) to
obtain the licenses to redistribute from the
appropriately licensing organizations (and pay
them their fees, which can end up being a lot of
money, so that usually means the app has to
charge something to be able to pay the license
fees (unless the individual is willing to pay
those fees for everyone, which can end up
being a lot of money)). Using only the
vendor supplied on-device solutions (i.e. not an
embedded FFmpeg) may be able to avoid those
licensing issues (check with your IP lawyer to be
sure), but also restricts presentation capabilities
to what the vendor provides to apps (and, of
course, you have to use those vendor interfaces).
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 5/1/23 22:32, Gary Buhrmaster wrote:
> On Tue, May 2, 2023 at 12:54?AM Peter Bennett <pb.mythtv@gmail.com> wrote:
>
>> I looked into the play store, for mythbackend and also for leanfront.
>> From what I found, Android and Amazon are far more strict about the app
>> store for android TV than for regular android for phones and tablets.
>> They want to review and test each TV application before approving it.
>> This would be impossible without a working MythTV backend. Looking at
>> the list of requirements for adding it to the store, I became
>> discouraged with the number of difficult or impossible requirements.
>
> In addition, any inclusion of any licensed technologies
> included in the app will be expected (required) to
> obtain the licenses to redistribute from the
> appropriately licensing organizations (and pay
> them their fees, which can end up being a lot of
> money, so that usually means the app has to
> charge something to be able to pay the license
> fees (unless the individual is willing to pay
> those fees for everyone, which can end up
> being a lot of money)). Using only the
> vendor supplied on-device solutions (i.e. not an
> embedded FFmpeg) may be able to avoid those
> licensing issues (check with your IP lawyer to be
> sure), but also restricts presentation capabilities
> to what the vendor provides to apps (and, of
> course, you have to use those vendor interfaces).
> _______________________________________________

This make me curious about how ubuntu handles the problem. ffmpeg, vlc,
mythtv, etc. are available for download from ubuntu. Does somebody pay
the mpeg license fees every time somebody downloads them? Perhaps ubuntu
has a special arrangement? Also many other places have video and audio
player software available for download (e.g. the vlc website). They must
have the same problem.

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 2023-05-01 18:53, Peter Bennett wrote:
>
> On 5/1/23 19:19, David Engel wrote:
>> On Tue, May 02, 2023 at 08:13:08AM +1000, Mark Spieth wrote:
>>> On 2/05/2023 7:49 am, Gary Buhrmaster wrote:
>>>> On Mon, May 1, 2023 at 9:35?PM Klaas de Waal
>>>> <klaas.de.waal@gmail.com> wrote:
>>>>
>>>>> Sounds good to me. We could even add a menu item just for convenience.
>>>>> With a bit of warning in the help text of course.
>>>>> One more step towards getting it to "just work".
>>>> Or "just break without clue" if some
>>>> future schema changes turns out to
>>>> be significant enough (including,
>>>> possibly, resulting in "corruption",
>>>> as some of the past changes have
>>>> re-formatted existing data in the
>>>> tables, and if the frontend updates
>>>> those tables in the old way there is
>>>> no way that it will get fixed again
>>>> as part of the original schema
>>>> change, since that already happened).
>>>>
>>>> If the database schema is wrong
>>>> and you want to allow things to
>>>> start up, you should put the
>>>> database into read-only mode
>>>> to insure no corruption.
>>> That can happen too. However I've never seen it in practice. It does
>>> require
>>> that the backend and frontend are reasonably closely matched, which
>>> is often
>>> the case.
>> It can definitely happen but the severity of the ensuing carnage
>> greatly depends on the exact, schema changes.  That's one reason we
>> should try to make the frontend use API calls exclusively or at least
>> as much as possible.  It would hopefully force us to improve API
>> compatibility and shield it from schema changes.
>>
>>> Another way is in the config.xml (which is local) which is what I think
>>> Peter was referring to.
>>>
>>> Would it be worthwhile to try to get the app in to the store? With
>>> the above
>>> feature, it wouldn't be  such an issue with DB version matching and
>>> selection.
>> Someone looked into getting into the play store a long time ago.  It
>> might have been Peter but I'm certainly not sure.  As I recall, it
>> would not be a quick and simple task.
>>
>> I believe one stumbling block would be supporting multiple backend
>> versions.  Until the frontend is API'ized, each backend version would
>> probably have to have its own, frontend app.  I seem to recall that
>> being frowned upon by Google, but as infrequently as MythTV is
>> officially released, it might not be a deal breaker.
>>
>> David
>
> I looked into the play store, for mythbackend and also for leanfront.
> From what I found, Android and Amazon are far more strict about the app
> store for android TV than for regular android for phones and tablets.
> They want to review and test each TV application before approving it.
> This would be impossible without a working MythTV backend. Looking at
> the list of requirements for adding it to the store, I became
> discouraged with the number of difficult or impossible requirements.
>
> One requirement is that all apps use exclusively SSL, for security
> reasons. This would be impossible, every user would have to purchase a
> domain, install DNS and purchase a certificate for their backend.
>
> These things may have changed in the meantime, that was a couple of
> years ago.
>
> I did design leanfront to support any MythTV version. It only uses the
> API. Every time there is an API that may be missing or different in
> older MythTV versions, it checks and caters for it.
>
> Peter


My personal experience with an app in the play store was not good.
Google can change the eligibility rules at any time and also place
specific demands on the developer for app builds, such as forcing API
levels.

My own app called SolitaireCG was suspended with Google citing
non-compliance with their "Repetitive Content Policy."

Curtis

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, May 02, 2023 at 09:18:38AM -0400, Peter Bennett wrote:
>
> On 5/1/23 22:32, Gary Buhrmaster wrote:
> > On Tue, May 2, 2023 at 12:54?AM Peter Bennett <pb.mythtv@gmail.com> wrote:
> >
> > > I looked into the play store, for mythbackend and also for leanfront.
> > > From what I found, Android and Amazon are far more strict about the app
> > > store for android TV than for regular android for phones and tablets.
> > > They want to review and test each TV application before approving it.
> > > This would be impossible without a working MythTV backend. Looking at
> > > the list of requirements for adding it to the store, I became
> > > discouraged with the number of difficult or impossible requirements.
> >
> > In addition, any inclusion of any licensed technologies
> > included in the app will be expected (required) to
> > obtain the licenses to redistribute from the
> > appropriately licensing organizations (and pay
> > them their fees, which can end up being a lot of
> > money, so that usually means the app has to
> > charge something to be able to pay the license
> > fees (unless the individual is willing to pay
> > those fees for everyone, which can end up
> > being a lot of money)). Using only the
> > vendor supplied on-device solutions (i.e. not an
> > embedded FFmpeg) may be able to avoid those
> > licensing issues (check with your IP lawyer to be
> > sure), but also restricts presentation capabilities
> > to what the vendor provides to apps (and, of
> > course, you have to use those vendor interfaces).
> > _______________________________________________
>
> This make me curious about how ubuntu handles the problem. ffmpeg, vlc,
> mythtv, etc. are available for download from ubuntu. Does somebody pay the
> mpeg license fees every time somebody downloads them? Perhaps ubuntu has a
> special arrangement? Also many other places have video and audio player
> software available for download (e.g. the vlc website). They must have the
> same problem.

Good question but an even more relevant one is this. Vlc and Mpv and
probably other, ffmpeg-based, media players are availalbe in hte play
store for free. How do they handle the licensing?

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, May 2, 2023 at 1:19?PM Peter Bennett <pb.mythtv@gmail.com> wrote:

> This make me curious about how ubuntu handles the problem. ffmpeg, vlc,
> mythtv, etc. are available for download from ubuntu. Does somebody pay
> the mpeg license fees every time somebody downloads them? Perhaps ubuntu
> has a special arrangement? Also many other places have video and audio
> player software available for download (e.g. the vlc website). They must
> have the same problem.

It is complicated. First, I am not your IP lawyer (and
only *your* IP lawyer should be trusted to provide you
with the complete details relevant for your specific
cases. Talk to her/him for their opinion). Also note
that this applies to all protected IP, although we almost
always focus on the codecs, they are not necessarily
the only things of concern (that requires *your* IP
lawyer to review every possible infringement). And
note that only binary distributions count (the software
codes themselves can not be infringing). Next, look
to where the organization is based for IP licensing
requirements and distribution responsibilities. In your
example, Canonical lawyers would appear to have
advised their org that the EU law(s) apply, which do
not recognize software patents (Canonical lawyers
have also advised them that they are allowed to
ship combined software with incompatible licenses,
which to this day is controversial in the OSS world).
There is a reason that VLC is "based" in France
(but note their android app reportedly uses the
android multimedia framework for presentation).

In the US (where you, and most app stores are based)
have different IP laws and requirements. Using
a different example of RedHat, which is based
in the US, they do not include any IP licensed content
in their distribution (they do ship a FFmpeg which
is stripped of any IP licensed code, but as FFmpeg
has a plugin architecture others can install
additional codecs if they have an appropriate
license). For some distributions there are 3rd party
apps that are user managed/controlled that may
build and offer IP licensed applications (which
the distros typically require the individuals to
take ownership/responsibility for in the CLA).
Many individuals (although not companies with
a competent legal staff and SBOM process) may
be unaware that they are using software for
which they do not have a license on Linux,
however, as the old saying goes, "ignorance of
the law is no excuse" in terms of any potential
violation. And then there is enforcement. Many
(but not all) of the licensing authorities often choose
to not enforce against individuals that provide free
apps (since the ability to collect any substantial
money is typically limited to the value of the
infringers home, being the asset with the highest
value, and the ROI is not always positive after
lawyer fees, except, possibly, for those living on
the coasts), but they have that right should they
choose to do so, and have done so in some cases
(and if you or a company benefits in any way from
the app (even just "mindshare") you are more
likely to receive their (or more specifically, their
lawyers) attention, and only a fool wishes to be
a "test" case). FWIW, at least one well known IP
owner has repeatedly had even "free" open source
projects removed from app stores when use of
their IP (without license) is determined because
they believe in the principles of following the
laws/regulations (and they want their money, of
course).

So, after talking with *your* IP lawyer, who is
expected to provide you with their best legal
advice, you (or others) are obviously free to
decide if you wish to move forward with any
app.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, May 2, 2023 at 4:06?PM David Engel <david@istwok.net> wrote:

> Good question but an even more relevant one is this. Vlc and Mpv and
> probably other, ffmpeg-based, media players are availalbe in hte play
> store for free. How do they handle the licensing?

It has been reported that they use the android multimedia
frameworks (where the manufacturer of the device is
paying the licensing for their implementation), which
is also why they may have different capabilities on
different devices (FFmpeg supports the android
multimedia frameworks if built/used accordingly, which
presumably minimized the changes that the apps had
to make, although it was apparently not zero, which
was probably why vlc was removed from various stores
at one point until they made those changes which
depended on FFmpeg changes too). In theory, as long
as MythTV just only the uses the multimedia frameworks
(via FFmpeg should it choose), those specific multimedia
licensing issues would presumably not be a concern
(other features/capabilities/technologies may have
other licensing issues, although the multimedia ones
tend to stand out, but a review would be needed by
*your* IP lawyer).

In the end, talk to *your* IP lawyer for a more complete
answer (IP law is complicated, and, as always, it is the
details that matter in the cases/decisions, and when I
talk to my friend who trained as an IP lawyer I can learn
some new interesting examples of new perturbations
in the interpretations of the law based on the slightly
different facts of the cases; the law is settled only
until some new detail is introduced).
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, 3 May 2023 at 02:06, David Engel <david@istwok.net> wrote:
>
> Good question but an even more relevant one is this. Vlc and Mpv and
> probably other, ffmpeg-based, media players are availalbe in hte play
> store for free. How do they handle the licensing?

They use a FFmpeg with patent encumbered codec not compiled in (so
exclude H264, H265, AAC), for those they use Android's MediaCodec
instead,
That's what Linux distribution such as Suse are also doing.

While I worked at Mozilla, legal deemed that so long that you didn't
ship code with patent encumbered, you'll be fine. So using the
*system*'s ffmpeg was okay.
Firefox ships its own copy of FFmpeg but only for VP9, VP8 and FLAC codecs

That's also why there's a difference between the OpenSource chromium
and Google's Chrome.
One ships with patent encumbered codecs opted-out
The other ships with it all, as Google pays the licensing fees. They
use the number of downloads to determine how much it will cost,
knowing that for H264 they have reached a cap and so it's a fixed-fee.

That's why OpenH264 is free too, there's a license to pay but Cisco
has reached the cap already.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, May 03, 2023 at 02:55:51AM +0000, Gary Buhrmaster wrote:
> On Tue, May 2, 2023 at 4:06?PM David Engel <david@istwok.net> wrote:
> > Good question but an even more relevant one is this. Vlc and Mpv and
> > probably other, ffmpeg-based, media players are availalbe in hte play
> > store for free. How do they handle the licensing?
>
> It has been reported that they use the android multimedia
> frameworks (where the manufacturer of the device is
> paying the licensing for their implementation), which
> is also why they may have different capabilities on
> different devices (FFmpeg supports the android
> multimedia frameworks if built/used accordingly, which

On Wed, May 03, 2023 at 04:35:48PM +1000, Jean-Yves Avenard wrote:
> They use a FFmpeg with patent encumbered codec not compiled in (so
> exclude H264, H265, AAC), for those they use Android's MediaCodec
> instead,
> That's what Linux distribution such as Suse are also doing.

Thanks for the clarification, guys. I thought I'd seen an option to
use software decoding in one of them. I know the Channels DVR app
does that and it could have confused me.

Anyway, expcept the lack of support for closed captions, MythTV
support of MediaCodec is more than functional(*). If it weren't for
the infamous, nvidia, mpeg2 bug, I'd use it all the time on my shield.
I always have to switch back to software decoding when I watch
something on of my affected channels.

David

(*) It should be possible to make it even better, and hopefully
support closed captions too, when MythTV moves to FFMpeg 6 which has
direct, NDK support for MediaCodec.

--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, May 3, 2023 at 6:36?AM Jean-Yves Avenard <jyavenard@gmail.com> wrote:

> That's why OpenH264 is free too, there's a license to pay but Cisco
> has reached the cap already.

For those still playing along at home, note that
you must use the binary library that Cisco has
signed/distributed to be covered under the Cisco
license terms (and I seem to recall Firefox
would download the library as needed if not
otherwise disabled). Many Linux distributions
make pulling in the Cisco libraries easy (if
not automatic).

The yearly fee cap for H.264 (I think it is around
$10M/yr) is a minor cost to a tech giant, and in
the case of Cisco, they were most interested in
video conferencing, where H.264 was more or
less the standard, so it was in their business
self interest to get it out there everywhere. It
should also be noted that not all IP has license
caps (and license caps were removed in later
MPEG-LA licenses (the more cynical might
suspect that the IP holders learned a lesson
about how tech companies can use such
license terms to the tech companies
advantage)).

But to add complexity to the issue, GPU
hardware support of H.264 (or H.265 for that
matter) is generally not licensed on Linux, so
distros that respect IP holders rights must
disable GPU hardware decode[0]. Annoyingly,
there is (essentially) no way for an individual to
license the inherent hardware capability of
many modern graphics cards (and an
enterprise license is "complicated").





[0] As before, the legal details are complicated,
but the summary is only the final combination
(software and hardware and distribution)
requires a license, but it does require one, and
typically there is no way to acquire one (at
least for individual end-users). And this is one
more reason why Linux users can't have nice
things OOTB. I do wish I could use GPU
hardware accelerated H.264 (as my older
desktop otherwise can be challenged by some
more complex H.264 content), but such is
life[1].

[1] "We seem to be made to suffer. It's our
lot in life." applies to those who use Linux
on their desktop, too.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Thu, 4 May 2023 at 13:37, Gary Buhrmaster <gary.buhrmaster@gmail.com> wrote:
> For those still playing along at home, note that
> you must use the binary library that Cisco has
> signed/distributed to be covered under the Cisco
> license terms (and I seem to recall Firefox
> would download the library as needed if not
> otherwise disabled). Many Linux distributions
> make pulling in the Cisco libraries easy (if
> not automatic).

That's something the Google Play store wanted to forbid, they added in
their T&Cs that an application isn't allowed to download a binary
executable, similar to Apple's T&Cs.
And Firefox was downloading OpenH264 directly from Cisco due to the
licensing terms as you mentioned.

I don't know what happened there, I had been working on using the
system framework decoders for H264 but I've since left.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 3/05/2023 12:52 pm, Gary Buhrmaster wrote:
> On Tue, May 2, 2023 at 1:19?PM Peter Bennett <pb.mythtv@gmail.com> wrote:
>
>> This make me curious about how ubuntu handles the problem. ffmpeg, vlc,
>> mythtv, etc. are available for download from ubuntu. Does somebody pay
>> the mpeg license fees every time somebody downloads them? Perhaps ubuntu
>> has a special arrangement? Also many other places have video and audio
>> player software available for download (e.g. the vlc website). They must
>> have the same problem.
> It is complicated. First, I am not your IP lawyer (and
> only *your* IP lawyer should be trusted to provide you
> with the complete details relevant for your specific
> cases. Talk to her/him for their opinion). Also note
> that this applies to all protected IP, although we almost
> always focus on the codecs, they are not necessarily
> the only things of concern (that requires *your* IP
> lawyer to review every possible infringement). And
> note that only binary distributions count (the software
> codes themselves can not be infringing). Next, look
> to where the organization is based for IP licensing
> requirements and distribution responsibilities. In your
> example, Canonical lawyers would appear to have
> advised their org that the EU law(s) apply, which do
> not recognize software patents (Canonical lawyers
> have also advised them that they are allowed to
> ship combined software with incompatible licenses,
> which to this day is controversial in the OSS world).
> There is a reason that VLC is "based" in France
> (but note their android app reportedly uses the
> android multimedia framework for presentation).
>
> In the US (where you, and most app stores are based)
> have different IP laws and requirements. Using
> a different example of RedHat, which is based
> in the US, they do not include any IP licensed content
> in their distribution (they do ship a FFmpeg which
> is stripped of any IP licensed code, but as FFmpeg
> has a plugin architecture others can install
> additional codecs if they have an appropriate
> license). For some distributions there are 3rd party
> apps that are user managed/controlled that may
> build and offer IP licensed applications (which
> the distros typically require the individuals to
> take ownership/responsibility for in the CLA).
> Many individuals (although not companies with
> a competent legal staff and SBOM process) may
> be unaware that they are using software for
> which they do not have a license on Linux,
> however, as the old saying goes, "ignorance of
> the law is no excuse" in terms of any potential
> violation. And then there is enforcement. Many
> (but not all) of the licensing authorities often choose
> to not enforce against individuals that provide free
> apps (since the ability to collect any substantial
> money is typically limited to the value of the
> infringers home, being the asset with the highest
> value, and the ROI is not always positive after
> lawyer fees, except, possibly, for those living on
> the coasts), but they have that right should they
> choose to do so, and have done so in some cases
> (and if you or a company benefits in any way from
> the app (even just "mindshare") you are more
> likely to receive their (or more specifically, their
> lawyers) attention, and only a fool wishes to be
> a "test" case). FWIW, at least one well known IP
> owner has repeatedly had even "free" open source
> projects removed from app stores when use of
> their IP (without license) is determined because
> they believe in the principles of following the
> laws/regulations (and they want their money, of
> course).
>
> So, after talking with *your* IP lawyer, who is
> expected to provide you with their best legal
> advice, you (or others) are obviously free to
> decide if you wish to move forward with any
> app.

This sounds very complicated and now regret mentioning it again.

This would seem to preclude using a 3rd party store like apkpure or
whatever due to the risk. But then again even supplying binaries may be
a risk.

Cheers

Mark


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sun, Apr 30, 2023 at 5:51?PM John P Poet <jppoet@gmail.com> wrote:

> Thank you Peter.
>
> On Sun, Apr 30, 2023 at 5:19?PM Peter Bennett <pb.mythtv@gmail.com> wrote:
>
>>
>> On 4/30/23 19:34, John P Poet wrote:
>> > Hi Peter,
>> >
>> > When you have time can you please upload a new version of Android
>> > mythfrontend? It looks like the DB schema changed sometime in the last
>> > couple of months.
>> >
>> > I tried to build it myself, but had no luck. It fails to build
>> > libbluray. If I tell it to skip libbluray, then It seems to mostly
>> > build qt but then gives a nebulous error. I have a feeling the problem
>> > is based in the fact that I am a Fedora user instead of Ubuntu.
>> >
>> > [javac] warning: [options] bootstrap class path not set in
>> > conjunction with -source 5
>> > [javac] error: Source option 5 is no longer supported. Use 7 or
>> later.
>> > [javac] error: Target option 5 is no longer supported. Use 7 or
>> later.
>> >
>> > I have limited experience with Docker, but that seems like it might be
>> > an interesting method to get the libs to build if it is indeed a
>> > problem with Fedora. Maybe I will look into that if I ever have the
>> > time to commit to it. I suppose I should try a VM to see if I can get
>> > it to build under ubuntu.
>> >
>> > Thanks,
>> >
>> > John
>> >
>> >
>> HI John
>>
>> I have built the latest master for android 32bit and 64bit and added
>> them to the download area at https://dl.orangedox.com/pCBmBm
>>
>
I just crafted an Ubuntu VM and tried to build the libs for Android.
Unfortunately I get the same failure there that I get with Fedora. Either
the instructions are out of date or I am not following them correctly ????

John