Remove conda-build overdepending warnings

[jdblischak]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

---

libaio (linux) and libiconv (osx) appear to be build-only requirements. By removing them from the host requirements, I removed the following conda-build warnings about overdepending:

# linux
WARNING (libtiledb-sql): run-exports library package conda-forge/linux-64::zlib==1.2.13=hd590300_5 in requirements/run but it is not used (i.e. it is overdepending or perhaps statically linked? If that is what you want then add it to `build/ignore_run_exports`)

# osx
WARNING (libtiledb-sql): run-exports library package conda-forge/osx-64::libiconv==1.17=hd75f5a5_2 in requirements/run but it is not used (i.e. it is overdepending or perhaps statically linked? If that is what you want then add it to `build/ignore_run_exports`)

Note that this means libaio and libiconv will no longer be installed at runtime. The current tests only check for the presence of installed files, and don't actually confirm the installed code is functional. Does it make sense that libaio and libiconv would only be needed at build time?

xref: #160 (comment)

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[jdblischak]

Does it make sense that libaio and libiconv would only be needed at build time?

I investigated this question more.

libaio

I am pretty confident that libaio only needs to be installed at build time.

For Debian/Ubuntu, libaio is split into a development only package (libaio-dev) and a shared library package (libaio1).

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.4 LTS
Release:        22.04
Codename:       jammy

$ apt search libaio
Sorting... Done
Full Text Search... Done
libaio-dev/jammy 0.3.112-13build1 amd64
  Linux kernel AIO access library - development files

libaio1/jammy 0.3.112-13build1 amd64
  Linux kernel AIO access library - shared library

The TileDB-MariaDB Dockerfile installs libaio-dev and not libaio1. Similarly, the Debian Control file for the MariaDB server lists libaio-dev in the section Build-Depends.

Lastly, I confirmed that the conda-forge recipe produces the required header file libaio.h.

libiconv

I am less certain about libiconv:

The library mode. This works on all systems, and uses a library libiconv.so
and a header file <iconv.h>. (Both are installed through "make install".)

To use it, simply #include <iconv.h> and use the functions.

The string "iconv" doesn't appear anywhere in TileDB-MariaDB.

From the discussion in MariaDB/server#1743, it is clear that libiconv is required at build time on macOS.

However, searching for "iconv" in MariaDB server, I can't find any explicit evidence that they are using the header file via iconv.h. I did find the following LINK_LIBRARIES call in storage/connect/CMakeLists.tx, but it is unclear to me from the CMake docs if this is static or dynamic linking.

MYSQL_ADD_PLUGIN(connect ${CONNECT_SOURCES}
  STORAGE_ENGINE
  COMPONENT connect-engine
  RECOMPILE_FOR_EMBEDDED
  LINK_LIBRARIES ${ZLIB_LIBRARY} ${XML_LIBRARY} ${ICONV_LIBRARY}
    ${ODBC_LIBRARY} ${MONGOC_LIBRARY} ${IPHLPAPI_LIBRARY} ${REST_LIBRARY})

[DimitrisStaratzis]

Thanks John. Thanks for the additional info. I am happy to merge.