[syslog-ng] [Bug 194] Can't open libsyslog-ng-crypto.so during module loading on Fedora

[bugzilla at bugzilla.balabit.com]

https://bugzilla.balabit.com/show_bug.cgi?id=194





--- Comment #3 from Gergely Nagy <algernon at balabit.hu>  2012-09-07 14:18:05 ---
> $ objdump -p syslog-ng-3.3.7-0.1.fc17.x86_64/usr/lib64/syslog-ng/libafsocket-tls.so | grep RPATH
> (no output)

The problem appears to be these lines:

+ sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
+ sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool

These pretty much tell libtool never to add an rpath, which can be observed later, when linking libafsocket-tls, for example:

/bin/sh ../../libtool --tag=CC   --mode=link gcc -std=gnu99  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4  -m64 -mtune=generic -Wall -pthread -avoid-version -module -no-undefined -Wl,-z,relro  -o libafsocket-tls.la -rpath
//usr/lib64/syslog-ng libafsocket_tls_la-afsocket.lo libafsocket_tls_la-afunix.lo libafsocket_tls_la-afinet.lo libafsocket_tls_la-afsocket-grammar.lo
libafsocket_tls_la-afsocket-parser.lo libafsocket_tls_la-afsocket-plugin.lo libafsocket_tls_la-sd-daemon.lo ../../lib/libsyslog-ng.la
../../lib/libsyslog-ng-crypto.la -lssl -lcrypto    -lnet -lwrap  

Notice that this correctly has "-rpath //usr/lib64/syslog-ng", while the command libtool ends up running, does not:

libtool: link: gcc -std=gnu99 -shared  .libs/libafsocket_tls_la-afsocket.o .libs/libafsocket_tls_la-afunix.o .libs/libafsocket_tls_la-afinet.o
.libs/libafsocket_tls_la-afsocket-grammar.o .libs/libafsocket_tls_la-afsocket-parser.o .libs/libafsocket_tls_la-afsocket-plugin.o
.libs/libafsocket_tls_la-sd-daemon.o   ../../lib/.libs/libsyslog-ng.so ../../lib/.libs/libsyslog-ng-crypto.so -lssl -lcrypto -lnet -lwrap  -m64 -mtune=generic
-pthread -Wl,-z -Wl,relro   -pthread -Wl,-soname -Wl,libafsocket-tls.so -o .libs/libafsocket-tls.so

Having looked at the spec file, the rpath-murdering is in the build target, just after configure. I believe that should be removed, so that shared objects that
do need an RPATH, will end up with one, the rest can be stripped of rpath later (chrpath -d does a marvellous job at that). Though, I'd think that libtool is
clever enough to not add rpath when not necessary.

This is a problem in the redhat packaging, I'd say, syslog-ng's build system does the right thing and adds the rpath to the private modules.


-- 
Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.