AArch64 tflite_runtime manylinux2014 prebuilt wheels distributed on PYPI are not manylinux2014 compliant
Hi @mshawcroft ,

There is problem with many_linux wheels because of capping of `glib` at 2.17 version.

The similar issue being discussed at #60608 . Please refer to the attached issue and users has to built their own wheels for this downgrading to glib 2.17 and referring to the comments/workarounds mentioned in attached ticket.

Thanks!

 Hi! Thanks for responding. Understood that is is possible (and straight forward) to build a correct manylinux2014_aarch64 labelled wheel, ie a wheel that depends on glibc<=2.17.

But that is not the issue here.

The issue here is that a wheel is being built and distributed on pypi that is not manylinux2014_aarch64 compliant but is being labelled and distributed as such.

Incorrect labelling of these wheels breaks the users install tool ability to reason about whether a wheel is valid on their platform.

Please re-label the .whls to comply with the naming standards defined pep599 and pep600.  The auditwheel tool provided by manylinux can do this. I believe the correct naming of the wheels currently distributed is manylinux_2_34_aarch64 not manylinux2014_aarch64

 Hi @terryheo, can you please take a look? Thanks. Getting similar results on a 'standard' raspbery pi (bullseye 64bit aarch64) build.  Wrote image to disk, apt update && apt upgrade, clone into the repo, import tflite_support and the problems start.

ImportError: /lib/aarch64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ~/.local/lib/python3.9/site-packages/tensorflow_lite_support/metadata/cc/python/_pywrap_metadata_version.so) Tag is updated for `tflite-runtime-nightly`. `tflite-runtime` will be updated from the next release. @terryheo could you elaborate a little on what "will be updated from the next release" means in practice please? I meant https://pypi.org/project/tflite-runtime/2.14.0/ Are you satisfied with the resolution of your issue?
<a href="https://docs.google.com/forms/d/e/1FAIpQLSfaP12TRhd9xSxjXZjcZFNXPGk4kc1-qMdv3gc6bEP90vY1ew/viewform?entry.85265664=Yes&entry.2137816233=https://github.com/tensorflow/tensorflow/issues/60738">Yes</a>
<a href="https://docs.google.com/forms/d/e/1FAIpQLSfaP12TRhd9xSxjXZjcZFNXPGk4kc1-qMdv3gc6bEP90vY1ew/viewform?entry.85265664=No&entry.2137816233=https://github.com/tensorflow/tensorflow/issues/60738">No</a>
 Looks like the 2.14 wheels for aarch64 are conservatively correct, great, thank you!

Perhaps worth noting that they are conservatively correct in that they depend on 2.27 but are labelled manylinux_2_34_aarch64, the label manylinux_2_27_aarch64 would be more appropriate.

Looks like the x86_64 wheel is broken, I didn't originally report that, I just happened to notice just now while looking at what has changed to address this ticket on aarch64. 

Here is the prefix of the output from auditwheel on one of the 2.14 x86_64 wheels:

`$ auditwheel show tflite_runtime-2.14.0-cp311-cp311-manylinux2014_x86_64.whl

tflite_runtime-2.14.0-cp311-cp311-manylinux2014_x86_64.whl is
consistent with the following platform tag: "manylinux_2_31_x86_64".
`

In this case the filename uses the platform tag "manylinux2014_x86_64",  PEP600 https://peps.python.org/pep-0600 defines that:

`
manylinux2014_x86_64 is now an alias for manylinux_2_17_x86_64
`

The wheel being distributed depends on glibc-2.31 hence is not compatible with the tag manylinux2014_x86_64.  

The solution to this is either to relabel it with the label indicated by auditwheel, or rebuild it an environment compatible with manylinux2014_x86_64 (for example the docker environment provided by the manylinux project).

Clearly this issue, while related to the originally reported issue, is not actually the original issue reported, Im happy to move this x86_64 issue to a separate GitHub issue if that is more appropriate. Hi @mshawcroft, go ahead and create a new issue with the details you stated here, that way we account for things most properly. Thanks for your help.
### Describe the problem

The manylinux2014 AArch64 tflite_runtime wheels distributed on PYPI are not manylinux2014 compliant.

manylinux2014 is specified by https://peps.python.org/pep-0599/ which is superseded by https://peps.python.org/pep-0600/

pep599 States that:

```
3 If the wheel contains binary executables or shared objects linked against any allowed libraries that also export versioned symbols, they may only depend on the following maximum versions:
GLIBC_2.17
CXXABI_1.3.7, CXXABI_TM_1 is also allowed
GLIBCXX_3.4.19
GCC_4.8.0
As an example, manylinux2014 wheels may include binary artifacts that require glibc symbols at version GLIBC_2.12, because this an earlier version than the maximum of GLIBC_2.17.

```
pep600 states that:

`manylinux2014_aarch64 is now an alias for manylinux_2_17_aarch64`

The auditwheel tool provided by manylinux, run on https://files.pythonhosted.org/packages/f7/52/db3a91277e4c171b65665731d622e7ed9a0ef7a601782403f90d43a080d8/tflite_runtime-2.12.0-cp38-cp38-manylinux2014_aarch64.whl reports the following:

```
tflite_runtime-2.12.0-cp38-cp38-manylinux2014_aarch64.whl is
consistent with the following platform tag: "manylinux_2_34_aarch64".

The wheel references external versioned symbols in these
system-provided shared libraries: libgcc_s.so.1 with versions
{'GCC_3.0'}, libm.so.6 with versions {'GLIBC_2.27', 'GLIBC_2.17',
'GLIBC_2.29'}, libc.so.6 with versions {'GLIBC_2.32', 'GLIBC_2.17',
'GLIBC_2.34', 'GLIBC_2.33'}, libstdc++.so.6 with versions
{'CXXABI_1.3.3', 'GLIBCXX_3.4.29', 'CXXABI_1.3', 'GLIBCXX_3.4.11',
'GLIBCXX_3.4.21', 'CXXABI_1.3.5', 'GLIBCXX_3.4', 'CXXABI_1.3.2',
'GLIBCXX_3.4.20', 'GLIBCXX_3.4.14', 'CXXABI_1.3.9', 'CXXABI_1.3.11',
'GLIBCXX_3.4.9', 'CXXABI_1.3.13', 'GLIBCXX_3.4.19', 'GLIBCXX_3.4.22',
'GLIBCXX_3.4.18'}

This constrains the platform tag to "manylinux_2_34_aarch64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.
```

The distributed wheel contains references to GLIBC_2.33 and GLIBC_2.34 which conflicts with clause 3 of pep0599. 

This issue came to light on the tflite_runtime-2.12.0-cp38-cp38-manylinux2014_aarch64.whl pre-built wheels hosted on pypi, but it looks like at least the following wheels have similar issues:

https://files.pythonhosted.org/packages/3f/1d/253fd16d01ec245f54f57d00674f836347931590af6b6e8c5ab76c8d4478/tflite_runtime-2.12.0-cp39-cp39-manylinux2014_aarch64.whl https://files.pythonhosted.org/packages/f7/52/db3a91277e4c171b65665731d622e7ed9a0ef7a601782403f90d43a080d8/tflite_runtime-2.12.0-cp38-cp38-manylinux2014_aarch64.whl
https://files.pythonhosted.org/packages/bf/75/c49f676ad2de36fa174b74d52bf6b2a199a54168ee550bbf85053578eb5c/tflite_runtime-2.11.0-cp39-cp39-manylinux2014_aarch64.whl
https://files.pythonhosted.org/packages/6e/c0/d131ffe53990fe10c158b856bc76fd71e294c3da5d13a58802e9a7d4642b/tflite_runtime-2.11.0-cp38-cp38-manylinux2014_aarch64.whl
https://files.pythonhosted.org/packages/d3/04/ad399c2cf7b0f301b6a44704fa1e6b3f1f64e16b0cbbd01132e53dee1b95/tflite_runtime-2.11.0-cp37-cp37m-manylinux2014_aarch64.whl

### Source code / logs

The above analysis can be recreated by:
```
virtualenv -p python3.8 v
./v/bin/pip install auditwheel
wget https://files.pythonhosted.org/packages/f7/52/db3a91277e4c171b65665731d622e7ed9a0ef7a601782403f90d43a080d8/tflite_runtime-2.12.0-cp38-cp38-manylinux2014_aarch64.whl
./v/bin/auditwheel show tflite_runtime-2.12.0-cp38-cp38-manylinux2014_aarch64.whl
```

