[ZBX-23873] Document a workaround to fix possible build issues when library is in non-standard path Created: 2023 Dec 20  Updated: 2024 Jan 23  Resolved: 2024 Jan 23

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: None
Affects Version/s: None
Fix Version/s: 7.0 (plan)

Type: Documentation task Priority: Trivial
Reporter: dimir Assignee: dimir
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Story Points: 2

 Description   

Coming from ZBX-23838

Currently when building Zabbix with a component in a non-standard path there is no guarantee it will be "picked up" when another version of it resides in standard path.

E. g.

  • I have an older system and its curl library is installed in /usr/lib
  • I have compiled and installed a newer curl library in /usr/local/lib
  • I would like to build Zabbix on this system using newer library

This might not be possible without a workaround. The problem is in the way the binary is compiled or linked (the order of compilation flags). This might not be possible to control by us but some tricks might be possible. Lets try to document them.



 Comments   
Comment by dimir [ 2023 Dec 20 ]

Suggestion is to add another page, e. g. "Compilation issues" under:

  • Appendixes
    • Installation and setup
      • Compilation issues

that will contain different cases of compilation issues. This one could be called "Library in non-standard location". Here's the proposed contents of the new page:

Compilation issues

Library in non-standard location

Overview

Zabbix allows you to specify a library located in a non-standard location, e. g.:

$ ./configure --enable-server --with-mysql --with-libcurl=/usr/local/bin/curl-config 

In this case Zabbix will run the curl-config from specified location and will use its output to determine the correct libcurl to use.

While this will work if that's the only libcurl installed in your system it might not if you have another libcurl installed in a standard location (e. g. by package manager). Usually it's the case when you need a newer version of the library for Zabbix and the older one for other applications.

Specifying a component in a non-standard location will not always work when the same component exists also in a standard location. For example, you would like to use a newer libcurl installed in /usr/local while you still have libcurl package installed.

It might happen so that Zabbix will "pick up" the wrong one and compilation will fail, e. g.:

usr/bin/ld: ../../src/libs/zbxhttp/libzbxhttp.a(http.o): in function `zbx_http_convert_to_utf8':
/tmp/zabbix-master/src/libs/zbxhttp/http.c:957: undefined reference to `curl_easy_header'
collect2: error: ld returned 1 exit status

In this case the function curl_easy_header() is not available in the older /usr/lib/x86_64-linux-gnu/libcurl.so but is available in the newer /usr/local/lib/libcurl.so .

The problem is the order of linker flags and one solution in this case is to specify the full path to the library you want to be used in a LDFLAGS variable, like this:

$ LDFLAGS="-Wl,--no-as-needed /usr/local/lib/libcurl.so" ./configure --enable-server --with-mysql --with-libcurl=/usr/local/bin/curl-config

Note the -Wl,--no-as-needed option, this might be needed on some systems.

See also: default linking options on Debian-based systems.

Comment by Marianna Zvaigzne [ 2024 Jan 11 ]

Documentation updated: 

  • Known issues > Compilation issues (5.0, 6.0, 6.4, 7.0) (new page)
  • Known issues (5.0, 6.0, 6.4, 7.0) (sentence added at the top)
  • Installation > Installation from sources (5.0, 6.0, 6.4, 7.0) (URL updated under See also)
Generated at Wed Apr 02 21:43:40 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.