-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Linking issue on FreeBSD #2131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi @granalberto Thanks for the report. I will have a look. Just installed a FreeBSD machine here to run a couple of tests. |
Build bots are running on v3/dev/issue2131. A small change but may broken compilation for others, so let's see what the buildbots are going to tell us. |
I can't reproduce this issue.
additional info's:
Of course, libmaxmindb had been installed:
And finally, the build flow and all test passed. |
@airween the configure stage passes OK for me too. Then, I run gmake. Default make doesn't work (you need to install gmake, of course). After a few minutes, the stage fails with the reported error. |
@granalberto - as I wrote, the build flow and all test (gmake/make test) are successfully passed.
(Note, this time is not the correct value, the binaries are built now...)
The failed tests caused by SSL error (Github needs sslv3, and looks like this release doesn't support it) - I didn't investigate it... So, I think you forgot to install libmaxmindb, or built from source and linker doesn't found....? |
Could you share with us your configure summary (as you can see mine above)? |
The second attempt to the fix is on the go. |
@airween I don't think the configuration summary is going to help here. The configuration script shall not link (or use) the wrong library regardless of how broken (or not) is the environment of the user. The main reason for having a configuration script is to detect and avoid nuances such as this. That said, works for me is not applied in this scenario. Something that the configure does, for instance, is to compile o piece of code with the desired library being used. If the compilation fails, it marks the library as not supported. If I didn't have a suspicious I would ask for the Likely @granalberto has libmaxmind being detected by the files on the file system, not pkg-config (or alternatives), therefore he has the lib- prefix in the front of the library. Nevertheless, I would go for LLVM on FreeBSD not gcc. |
hi @zimmerle
yes, it doesn't help to detect the library,
but can helps to detect other parts of environment :). |
You meant: if it helps to identify if the library exists or not? If so, let me explain how it works - The build has a set of scripts at the build directory, here. The logging will help us to identify whenever there was a conflict of geoIP vs Maxmind or even garbage left for a not workable Maxmind. The summary on another hand will just present just a summary.
Yes, most certainly yes. As far as you go from what is considered standard as like you be to identify not tested scenarios, therefore possible issues. |
Just an update: the script is looking for the library in /usr/local and /opt which may or may not be on the library path. |
This is the summary of configure script: ModSecurity - for FreeBSD Mandatory dependencies + libInjection ....v3.9.2-30-gbf234eb + SecLang tests ....5d85f36 Optional dependencies + GeoIP/MaxMind ....found * (MaxMind) v /usr/local/lib//libmaxminddb.so, /usr/local/include, -DWITH_MAXMIND -I/usr/local/include + LibCURL ....found v7.65.1 -L/usr/local/lib -lcurl, -I/usr/local/include -DWITH_CURL_SSLVERSION_TLSv1_2 -DWITH_CURL + YAJL ....not found + LMDB ....not found + LibXML2 ....found v2.9.9 -L/usr/local/lib -lxml2 -lz -L/usr/lib -llzma -L/usr/lib -lm, -I/usr/local/include/libxml2 -I/usr/include -DWITH_LIBXML2 + SSDEEP ....not found + LUA ....not found Other Options + Test Utilities ....disabled + SecDebugLog ....enabled + afl fuzzer ....disabled + library examples ....enabled + Building parser ....disabled + Treating pm operations as critical section ....disabled These are the installed packages: # pkg info apache24-2.4.39_1 Version 2.4.x of Apache web server apr-1.6.5.1.6.1_1 Apache Portability Library autoconf-2.69_2 Automatically configure source code on many Un*x platforms autoconf-wrapper-20131203 Wrapper script for GNU autoconf automake-1.16.1_1 GNU Standards-compliant Makefile generator binutils-2.32_1,1 GNU binary tools ca_root_nss-3.44.1 Root certificate bundle from the Mozilla Project curl-7.65.1 Command line tool and library for transferring data with URLs db5-5.3.28_7 Oracle Berkeley DB, revision 5.3 expat-2.2.6_1 XML 1.0 parser written in C gcc8-8.3.0_2 GNU Compiler Collection 8 gdbm-1.18.1_1 GNU database manager gettext-runtime-0.20.1 GNU gettext runtime libraries and programs git-lite-2.22.0 Distributed source code management tool (lite package) gmake-4.2.1_3 GNU version of 'make' utility gmp-6.1.2_1 Free library for arbitrary precision arithmetic indexinfo-0.3.1 Utility to regenerate the GNU info page index libmaxminddb-1.3.2_1 Library for the MaxMind DB file format used for GeoIP2 libnghttp2-1.39.1 HTTP/2.0 C Library libtool-2.4.6_1 Generic shared library support script libxml2-2.9.9 XML parser library for GNOME m4-1.4.18_1,1 GNU M4 modsecurity3-3.0.3_2 Intrusion detection and prevention engine modsecurity3-apache-0.0.9.b1.19 Intrusion detection and prevention engine / Apache Wrapper mpc-1.1.0_2 Library of complex numbers with arbitrarily high precision mpfr-4.0.2 Library for multiple-precision floating-point computations pcre-8.43_1 Perl Compatible Regular Expressions library perl5-5.28.2 Practical Extraction and Report Language pkg-1.11.1 Package manager readline-8.0.0 Library for editing command lines as they are typed sudo-1.8.27_1 Allow others to run commands as root yajl-2.1.0 Portable JSON parsing and serialization library in ANSI C I need to go through the whole compilation process so eventually I can make the modsecurity3-nginx port and package for FreeBSD and perhaps Pkgsrc. Let me know if you need something else. I cannot respond fast these days but I'll do my best. |
@granalberto it doesn't visible how do you pass the arguments to the Here is how I did: I didn't pass any maxmindb info. It's interesting that your script detect it as without version, and shows full path instead if linker flag. Note, that you don't need to pass the Anyway, as you can see @zimmerle gave a possible solution - you can grab it from here. |
Thank you all very much. Branch v3/dev/issue/2131 works when you pass --prefix=/usr/local to ./configure. |
I don't understand why |
It's because MAXMIND_POSSIBLE_LIB_NAMES is used both for pkg-config and for matching the library name itself. I think the solution is not to use it for pkg-config, because it was never called anything other than libmaxminddb. So replace
with
|
Build with libmaxminddb is broken since bump to version 3.0.5 in commit 464d0be because of owasp-modsecurity/ModSecurity@785958f So revert this commit until upstream answer to comment to owasp-modsecurity/ModSecurity#2131 Reverting this commit requires autoreconfiguring, which itself causes lots of warnings as configure.ac queries git to know the version of various parts of libmodsecurity. However, it turns out that those versions are only used to be displayed in the output of the configure script, which is quite useless. The only one that is referenced elsewhere is LIBINJECTION_VERSION, but it's in fact a different thing: it is defined by others/libinjection/src/libinjection_sqli.c. The only variable that was AC_SUBST() and therefore visible elsewhere was MSC_GIT_VERSION, but it is not used anywhere in the code base, except in the configure script itself. Note that one patch is 0001 and the other 0003, because there was already a 0002 patch. Fixes: - http://autobuild.buildroot.org/results/4c639fd967faa06f8ae362bacd38f3409c47267c Signed-off-by: Fabrice Fontaine <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Build with libmaxminddb is broken since bump to version 3.0.5 in commit 464d0be because of owasp-modsecurity/ModSecurity@785958f So revert this commit until upstream answer to comment to owasp-modsecurity/ModSecurity#2131 Reverting this commit requires autoreconfiguring, which itself causes lots of warnings as configure.ac queries git to know the version of various parts of libmodsecurity. However, it turns out that those versions are only used to be displayed in the output of the configure script, which is quite useless. The only one that is referenced elsewhere is LIBINJECTION_VERSION, but it's in fact a different thing: it is defined by others/libinjection/src/libinjection_sqli.c. The only variable that was AC_SUBST() and therefore visible elsewhere was MSC_GIT_VERSION, but it is not used anywhere in the code base, except in the configure script itself. Note that one patch is 0001 and the other 0003, because there was already a 0002 patch. Fixes: - http://autobuild.buildroot.org/results/4c639fd967faa06f8ae362bacd38f3409c47267c Signed-off-by: Fabrice Fontaine <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]> (cherry picked from commit 94b6fbd) Signed-off-by: Peter Korsgaard <[email protected]>
Build with libmaxminddb is broken since bump to version 3.0.5 in commit 464d0be because of owasp-modsecurity/ModSecurity@785958f So revert this commit until upstream answer to comment to owasp-modsecurity/ModSecurity#2131 Reverting this commit requires autoreconfiguring, which itself causes lots of warnings as configure.ac queries git to know the version of various parts of libmodsecurity. However, it turns out that those versions are only used to be displayed in the output of the configure script, which is quite useless. The only one that is referenced elsewhere is LIBINJECTION_VERSION, but it's in fact a different thing: it is defined by others/libinjection/src/libinjection_sqli.c. The only variable that was AC_SUBST() and therefore visible elsewhere was MSC_GIT_VERSION, but it is not used anywhere in the code base, except in the configure script itself. Note that one patch is 0001 and the other 0003, because there was already a 0002 patch. Fixes: - http://autobuild.buildroot.org/results/4c639fd967faa06f8ae362bacd38f3409c47267c Signed-off-by: Fabrice Fontaine <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]> (cherry picked from commit 94b6fbd) Signed-off-by: Peter Korsgaard <[email protected]>
Describe the bug
When compiling from source on FreeBSD 11.2-RELEASE, the linker is called with -llibmaxminddb and it makes it fail. The correct option would be -lmaxminddb.
Logs and dumps
/usr/bin/ld: cannot find -llibmaxminddb
The text was updated successfully, but these errors were encountered: