[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 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.
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:
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 issuesLibrary in non-standard locationOverviewZabbix 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: |