linker can't find -liconv or -lintl on FreeBSD

[PaddyMac]

I'm trying to build on FreeBSD 12.2-RELEASE. I did install all the dependencies, and the libraries are located in /usr/local/lib. But for some reason cmake must not be properly handling things because when trying to compile, I get output like this:

patrick@xps400:/usr/home/patrick/work/TSC/tsc/build $ make
[ 1%] Built target podparser
[ 2%] Built target scrdg
[ 2%] Built target scriptdocumentation
[ 6%] Built target mruby
[ 7%] Built target tinyclipboard
[ 8%] Linking CXX executable tsc
ld: error: unable to find library -liconv
ld: error: unable to find library -lintl
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

[xet7]

@PaddyMac

So you did install iconv etc? Does FreeBSD find those libraries, or do they need to be added to path?

For example on Ubuntu, when I like to use commands and libraries from Snap package, I do this to get mongodump and it's libraries to path:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/snap/wekan/current/lib/x86_64-linux-gnu
export PATH="$PATH:/snap/wekan/current/bin"

Is there something similar for FreeBSD ?

[Quintus]

Am Montag, dem 02. November 2020 schrieb PaddyMac:

I'm trying to build on FreeBSD 12.2-RELEASE.

Our FreeBSD build support is only experimental as we have nobody who maintains it. iconv and intl are core libraries present on any Linux system, but it may be they're missing the BSDs. We welcome anyone who wants to maintain the FreeBSD builds, but as of now we cannot give much help with it. If you find out where the problems arise from, please contribute a patch. You might want to take a look at the changes that were introduced with PR #678. This PR contributed the BSD build support in the first place. -quintus

…

-- Dipl.-Jur. M. Gülker | https://mg.guelker.eu | For security: Passau, Germany | kontakt@guelker.eu | () Avoid HTML e-mail European Union | PGP: see homepage | /\ http://asciiribbon.org

[PaddyMac]

I tried "export LD_LIBRARY_PATH=/usr/local/lib" and then running make again. The value was added to the environment, but it had no effect. I also examined the ../TSC/tsc/build/CMakeCache.txt to see what I could find. Frankly it looks like it should work unless maybe these aren't relevant to what is being linked when it fails. I'm attaching CMakeCache.txt in case you find it helpful to examine it.
CMakeCache.txt

[PaddyMac]

I enabled verbose mode and tried to build again. I see what the problem is, and I believe I know what needs to change to fix it, but I'm not familiar enough with cmake to know how to implement that fix.

The linker command line reveals that almost all of the libraries being linked are referred to by absolute pathnames (e.g. /usr/local/lib/libXext.so). Only four libraries are called with the -l flag: -lz, -lpthread, -liconv, and -lintl. The parameter -L/usr/local/lib is nowhere to be found on the command line. There's no error with -lz or -lpthread because they're in /lib or /usr/lib. -liconv and -lintl fail because they're in /usr/local/lib.

So this should easily be remedied by either 1) adding these libraries to the linker command line by an absolute path just like most of the other libraries, or 2) adding -L/usr/local/lib to the linker command line should work.
tsc_build_failure.txt

[Quintus]

Am Montag, dem 02. November 2020 schrieb PaddyMac:

I enabled verbose mode and tried to build again. I see what the problem is, and I believe I know what needs to change to fix it, but I'm not familiar enough with cmake to know how to implement that fix. The linker command line reveals that almost all of the libraries being linked are referred to by absolute pathnames (e.g. /usr/local/lib/libXext.so). Only four libraries are called with the -l flag: -lz, -lpthread, -liconv, and -lintl. The parameter -L/usr/local/lib is nowhere to be found on the command line. There's no error with -lz or -lpthread because they're in /lib or /usr/lib. -liconv and -lintl fail because they're in /usr/local/lib.

Thanks for investigating. It turns out that this is not CMake's fault. In CMakeLists.txt, lines 222-224 we have this: if (CMAKE_SYSTEM_NAME MATCHES "BSD") target_link_libraries(tsc iconv intl) endif() So this "cheats" cmake by specifying the libraries' names directly instead of using cmake's find_library() mechanism, which would look into /usr/local. By specifiying the library names directly, the linker's default search path is used instead as these names go out to the shellout to the linker as-is (via the -l option, as you have observed). To overcome this, you have two options. Either you need to rewrite this part of CMakeLists.txt to use CMake's find_package() and/or find_library() functions when BSD is activated. This would be the best solution and we certainly accept a patch for this. Or, you set the LDFLAGS environment variable before you invoke cmake(1) for the first time, like this: $ export LDFLAGS="-L/usr/local/lib" cmake will write this value into CMAKE_EXE_LINKER_FLAGS, see cmake-env-variables(7). From there it should find its way until the invocation of the linker. Please note that this will only work in a clean build directory. -quintus

…

-- Dipl.-Jur. M. Gülker | https://mg.guelker.eu | For security: Passau, Germany | kontakt@guelker.eu | () Avoid HTML e-mail European Union | PGP: see homepage | /\ http://asciiribbon.org

[Quintus]

This issue is actually low-hanging fruit for newcomers to the code. I'll properly tag it now and let's see what happens. It should be pretty easy to resolve.