[Bug 115] New: libsyslog-ng.so is not linked with glib/cap but uses glib/ cap symbols
https://bugzilla.balabit.com/show_bug.cgi?id=115 Summary: libsyslog-ng.so is not linked with glib/cap but uses glib/cap symbols Product: syslog-ng Version: 3.2.x Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi@balabit.hu ReportedBy: arekm@maven.pl Type of the Report: --- Estimated Hours: 0.0 [arekm@carme-pld ~/rpm/BUILD/syslog-ng-3.2.2/lib]$ ldd .libs/libsyslog-ng.so linux-vdso.so.1 => (0x00007fff46f80000) libc.so.6 => /lib64/libc.so.6 (0x00007fb64c4b8000) /lib64/ld-linux-x86-64.so.2 (0x0000003fba800000) but libsyslog-ng.so uses many glib and cap symbols: libtool: link: x86_64-pld-linux-gcc -std=gnu99 -I../../../lib -I../../../lib -I../../../modules/dbparser -I.. -Wno-pointer-sign -O2 -fno-strict-aliasing -fwrapv -march=x86-64 -gdwarf-3 -g2 -Wall .libs/test_patterndbS.o -Wl,--as-needed -Wl,--no-copy-dt-needed-entries -Wl,-z -Wl,relro -Wl,-z -Wl,combreloc -o .libs/test_patterndb test_patterndb.o ../.libs/patternize.o -Wl,-Bstatic -Wl,--whole-archive -Wl,--export-dynamic -pthread -Wl,--no-whole-archive -Wl,-Bdynamic ../../syslogformat/.libs/libsyslogformat.so ../../../lib/.libs/libsyslog-ng.so ../.libs/libsyslog-ng-patterndb.so /home/users/arekm/rpm/BUILD/syslog-ng-3.2.2/lib/.libs/libsyslog-ng.so -lssl -lcrypto -lresolv /usr/lib64/libgmodule-2.0.so /usr/lib64/libgthread-2.0.so -lpthread /usr/lib64/libglib-2.0.so /usr/lib64/libevtlog.so /usr/lib64/libpcre.so -lcap -ldl -lrt -pthread -Wl,-rpath -Wl,/lib64/syslog-ng ../../../lib/.libs/libsyslog-ng.so: undefined reference to `cap_set_proc' ../../../lib/.libs/libsyslog-ng.so: undefined reference to `cap_from_text' ../../../lib/.libs/libsyslog-ng.so: undefined reference to `g_module_build_path' ../../../lib/.libs/libsyslog-ng.so: undefined reference to `cap_free' ../../../lib/.libs/libsyslog-ng.so: undefined reference to `g_module_make_resident' ../../../lib/.libs/libsyslog-ng.so: undefined reference to `g_thread_init' ../../../lib/.libs/libsyslog-ng.so: undefined reference to `g_module_symbol' ../../../lib/.libs/libsyslog-ng.so: undefined reference to `g_module_open' ../../../lib/.libs/libsyslog-ng.so: undefined reference to `g_module_error' ../../../lib/.libs/libsyslog-ng.so: undefined reference to `cap_set_flag' ../../../lib/.libs/libsyslog-ng.so: undefined reference to `cap_to_text' ../../../lib/.libs/libsyslog-ng.so: undefined reference to `cap_get_proc' That's in mixed linking, CORE_DEPS_LIBS is then empty. CORE_DEPS_LIBS should contain static linking to glib and dynamic to cap then. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=115 --- Comment #1 from Balazs Scheidler <bazsi@balabit.hu> 2011-02-23 10:58:51 --- this is on purpose. all static libs are compiled into the main syslog-ng executable in this case and libsyslog-ng.so doesn't have them, but should refer to them through the main executable. It did work for me at least once for Linux (and I know it wouldn't work on other platforms), and as it seems you have trouble with linking the unit tests only. Does the main binary work in this case? Since libtool doesn't support multiple -Wl,-Bdynamic/-Wl,-Bstatic options I bypass it in this case for the main binary. But this causes problems with all programs during linking, such as the unit tests. (does the pdbtool binary work in this case?) My idea is not to use DEPS_LIBS in those cases, but rather the dependency libs, which means that programs will be linked dynamically regardless of the --enable-mixed-linking option. The only alternative is to bypass libtool even in these cases, but I think that's too fragile, and it shouldn't matter if those are linked dynamically. What do you think? -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=115 --- Comment #2 from Arkadiusz Miśkiewicz <arekm@maven.pl> 2011-02-23 11:11:46 --- It will fail if you use: -Wl,--as-needed -Wl,--no-copy-dt-needed-entries (which is more common, default for fedora and pld rpm builds for example) Also I don't understand what's point of such separate dynamic library if it cannot work without syslog-ng itself? Then maybe it should be statically linked into syslog-ng? Anyway I can drop above linker flags if this is "by design" and it will likely succeed (because usually this is "by bug"). -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=115 --- Comment #3 from Balazs Scheidler <bazsi@balabit.hu> 2011-02-23 11:35:24 --- well, libsyslog-ng.so is a private library, and the reason it needs to be dynamic, is that non-Linux platforms do not always allow sharing symbols back to modules from the main executable. I played a lot of this issue, and this was the solution that worked everywhere. The problematic platform was by the way AIX. So libsyslog-ng.so could and probably should be shoved in $prefix/lib/syslog-ng, at least in case mixed linking is used. In case mixed linking is not used, it is properly linked against all its dependencies. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
On Feb 23 11:35, bugzilla@wwwold.balabit.com wrote:
https://bugzilla.balabit.com/show_bug.cgi?id=115
--- Comment #3 from Balazs Scheidler <bazsi@balabit.hu> 2011-02-23 11:35:24 --- well, libsyslog-ng.so is a private library, and the reason it needs to be dynamic, is that non-Linux platforms do not always allow sharing symbols back to modules from the main executable.
I played a lot of this issue, and this was the solution that worked everywhere. The problematic platform was by the way AIX.
So libsyslog-ng.so could and probably should be shoved in $prefix/lib/syslog-ng, at least in case mixed linking is used.
Please don't do this if syslog-ng is linked against it. libsyslog-ng.so should stay where it's found for load-time linking by system default. libtool (at least the newer ones) will do the right thing in this case. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
https://bugzilla.balabit.com/show_bug.cgi?id=115 Balazs Scheidler <bazsi@balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution| |INVALID Status|NEW |RESOLVED --- Comment #4 from Balazs Scheidler <bazsi@balabit.hu> 2011-10-23 09:27:27 --- In 3.3 we've added -release <syslog-ng-version-number> to the libtool arguments when linking libsyslog-ng.so to indicate its close ties to the actual syslog-ng version. Its compatibility is not ensured even between minor releases. Unfortunately we can't easily put that lib into a private library folder, as that would require wrapper scripts for all of our binaries (setting LD_LIBRARY_PATH) or using -rpath which is not accepted by most distributions. So the current solution is the best I could come up with, closing this ticket (as INVALID lacking a better resolution). If linking syslog-ng fully dynamic on your distribution is ok (e.g. all the required libs are in /lib or syslog-ng is installed in /usr) then that's an alternative too. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (2)
-
bugzilla＠bugzilla.balabit.com
-
Corinna Vinschen