# FindIconv doesn't seem to behave correctly

**URL:** <https://discourse.cmake.org/t/findiconv-doesnt-seem-to-behave-correctly/9606>\
**Category:** Code\
**Created:** [December 11, 2023, 3:09pm UTC](https://discourse.cmake.org/t/findiconv-doesnt-seem-to-behave-correctly/9606 "2023-12-11T15:09:10Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![dundargoc](https://discourse.cmake.org/user_avatar/discourse.cmake.org/dundargoc/32/1923_2.png) [@dundargoc](https://discourse.cmake.org/u/dundargoc)\
**Post date:** [December 11, 2023, 3:09pm UTC](https://discourse.cmake.org/t/findiconv-doesnt-seem-to-behave-correctly/9606/1 "2023-12-11T15:09:10Z")

</div>

Our project has our own `FindIconv.cmake` file as we’re using minimum version 3.10. I’m trying to upgrade to version 3.13 and in the process replace the `FindIconv.cmake` with the builtin `FindIconv` module. Our `FindIconv.cmake` looks like the following:

```auto
find_path(ICONV_INCLUDE_DIR NAMES iconv.h)
find_library(ICONV_LIBRARY NAMES iconv libiconv)
find_package_handle_standard_args(Iconv DEFAULT_MSG
  ICONV_INCLUDE_DIR)
mark_as_advanced(ICONV_INCLUDE_DIR ICONV_LIBRARY)

add_library(iconv INTERFACE)
target_include_directories(iconv SYSTEM BEFORE INTERFACE ${ICONV_INCLUDE_DIR})
if(ICONV_LIBRARY)
  target_link_libraries(iconv INTERFACE ${ICONV_LIBRARY})
endif()

```

However, when using the builtin module I get the following errors on freebsd:

```auto
ld: error: undefined symbol: libiconv_close
>>> referenced by bufwrite.c:1890 (/tmp/cirrus-ci-build/src/nvim/bufwrite.c:1890)
>>> src/nvim/CMakeFiles/nvim.dir/bufwrite.c.o:(buf_write)
>>> referenced by fileio.c:760 (/tmp/cirrus-ci-build/src/nvim/fileio.c:760)
>>> src/nvim/CMakeFiles/nvim.dir/fileio.c.o:(readfile)
>>> referenced by fileio.c:1037 (/tmp/cirrus-ci-build/src/nvim/fileio.c:1037)
>>> src/nvim/CMakeFiles/nvim.dir/fileio.c.o:(readfile)
>>> referenced 3 more times

ld: error: undefined symbol: libiconv
>>> referenced by bufwrite.c:189 (/tmp/cirrus-ci-build/src/nvim/bufwrite.c:189)
>>> src/nvim/CMakeFiles/nvim.dir/bufwrite.c.o:(buf_write_convert_with_iconv)
>>> referenced by bufwrite.c:201 (/tmp/cirrus-ci-build/src/nvim/bufwrite.c:201)
>>> src/nvim/CMakeFiles/nvim.dir/bufwrite.c.o:(buf_write_convert_with_iconv)
>>> referenced by fileio.c:1115 (/tmp/cirrus-ci-build/src/nvim/fileio.c:1115)
>>> src/nvim/CMakeFiles/nvim.dir/fileio.c.o:(readfile)
>>> referenced 2 more times

ld: error: undefined symbol: libiconv_open
>>> referenced by mbyte.c:2243 (/tmp/cirrus-ci-build/src/nvim/mbyte.c:2243)
>>> src/nvim/CMakeFiles/nvim.dir/mbyte.c.o:(my_iconv_open)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

```

I am unsure why cmake tries to find libiconv instead of iconv, which is what I’d expect. Is there an idiomatic way to resolve this? For example, is there a way to make it not search for libiconv and just search for iconv instead?

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [December 11, 2023, 3:50pm UTC](https://discourse.cmake.org/t/findiconv-doesnt-seem-to-behave-correctly/9606/2 "2023-12-11T15:50:29Z")

</div>

The builtin module provides an `Iconv::Iconv` target that you probably would be better off using when porting. Other than that, CMake’s builtin one uses variables starting with `Iconv_`, not `ICONV_`.

---

<div class="post-metadata">

**Author:** ![dundargoc](https://discourse.cmake.org/user_avatar/discourse.cmake.org/dundargoc/32/1923_2.png) [@dundargoc](https://discourse.cmake.org/u/dundargoc)\
**Post date:** [December 11, 2023, 5:33pm UTC](https://discourse.cmake.org/t/findiconv-doesnt-seem-to-behave-correctly/9606/3 "2023-12-11T17:33:08Z")

</div>

I know, I am using the `Iconv::Iconv` target and `Iconv_LIBRARIES`. This shows up despite that.

PR: [build: bump minimum cmake version to 3.13 by dundargoc · Pull Request #25638 · neovim/neovim · GitHub](https://github.com/neovim/neovim/pull/25638)  
CI results: [Cirrus CI](https://cirrus-ci.com/task/6646152808890368)

---

<div class="post-metadata">

**Author:** ![hsattler](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/h/59ef9b/32.png) [@hsattler](https://discourse.cmake.org/u/hsattler)\
**Post date:** [December 11, 2023, 7:39pm UTC](https://discourse.cmake.org/t/findiconv-doesnt-seem-to-behave-correctly/9606/4 "2023-12-11T19:39:11Z")

</div>

I assume that one of the pre-built libraries wants a libiconv that is not built in the libc, so one that uses iconv symbols prefixed with lib…

---

<div class="post-metadata">

**Author:** ![dundargoc](https://discourse.cmake.org/user_avatar/discourse.cmake.org/dundargoc/32/1923_2.png) [@dundargoc](https://discourse.cmake.org/u/dundargoc)\
**Post date:** [December 12, 2023, 10:14am UTC](https://discourse.cmake.org/t/findiconv-doesnt-seem-to-behave-correctly/9606/5 "2023-12-12T10:14:38Z")

</div>

Can you elaborate? What’s the correct solution to resolve this?

---

<div class="post-metadata">

**Author:** ![hsattler](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/h/59ef9b/32.png) [@hsattler](https://discourse.cmake.org/u/hsattler)\
**Post date:** [December 12, 2023, 10:36am UTC](https://discourse.cmake.org/t/findiconv-doesnt-seem-to-behave-correctly/9606/6 "2023-12-12T10:36:09Z")

</div>

See e.g. [iconv / libiconv 1.15 vs libc / libiconv\_open | common/isc\_file.cpp [CORE5989] · Issue #6239 · FirebirdSQL/firebird · GitHub](https://github.com/FirebirdSQL/firebird/issues/6239)

Just guessing here: you are using the wrong header file or FindIconv is not considering this.

---

<div class="post-metadata">

**Author:** ![dundargoc](https://discourse.cmake.org/user_avatar/discourse.cmake.org/dundargoc/32/1923_2.png) [@dundargoc](https://discourse.cmake.org/u/dundargoc)\
**Post date:** [December 12, 2023, 11:54am UTC](https://discourse.cmake.org/t/findiconv-doesnt-seem-to-behave-correctly/9606/7 "2023-12-12T11:54:43Z")

</div>

Unsure what to do with the link, they use autotools and the PR comments are just botspam. Thanks I guess.