smbd compiled with support for avahi crashes on startup when used with uClibc. Without avahi support, it works nicely. I've tracked this down to missing linker flags and I am attaching a patch that fixes the problem.
Created attachment 6036 [details] patch to fix linker flags for smbd
Isn't the patch a bit simplistic? It works fine on glibc systems, maybe because pthreads is linked implicitly. Isn't it possible to get this with some autoconf test? Volker
LIBS contains PTHREAD_LDFLAGS if smbd needs them. That is only the case if we use the enable_pthreadpool configure option which is mostly deprecated. (from configure.in:) if test x"$enable_pthreadpool" = x"yes" -a x"$samba_cv_HAVE_PTHREAD" = x"yes"; then LIBS="$LIBS $PTHREAD_LDFLAGS" ... On your system, your avahi library needs to be fixed and be linked against libpthread - that is my guess.
I don't mind if you just close this report. I only just spent several hours tracking down this problem and though it might help someone if the solution ended up in a related bug-tracker.
Well, we'd like to build Samba on as many platforms as possible. But your patch does not really help in the general case. What libs does your libavahi.so depend on? If it needs pthreads, but does not provide that dependency according to ldd, then we'd need a special case like the RHEL5 readline one. Did you compile libavahi yourself, or is this an off-the-shelf platform you're running on? Volker
This is buildroot using uClibc (see http://buildroot.uclibc.org/). The buildroot folks are shipping a similar patch for samba 3.3.x. Now after updating to samba 3.5.6 and seeing that a similar patch is still needed, I thought it would be best to submit this upstream. libavahi-client.so has a dependency on libpthread.so.0 according to ldd.
Ok, I don't get that. I thought that if a library explicitly depends on another library, the main program does not have to do the same. This is really weird. Can you give me an URL to read why this is necessary? I would like to understand the reason behind it. Thanks, Volker
(In reply to comment #7) > Ok, I don't get that. I thought that if a library explicitly depends on another > library, the main program does not have to do the same. This is really weird. > As far as I understand this is only true for glibc on Linux. On other platforms, such as Win32, or uCLibc on Linux, all libraries have to be specified explicitly on the linker command-line, even if they are pulled in implicitly by other libraries. Unfortunately I can't point you to a good reference on this subject.
Wow, ok. If that's true, it will be *VERY* hairy to get the linker line right for all platforms. krb5 might depend on com_err without us knowing for example. cups depends on openssl which itself might depend on some asn1 stuff. Just making up wild examples, but this can become arbitrarily complex. I wonder if there is an automated way to test this. Volker
Well, the usual way to solve this is to use pkg-config to ask the libraries for their required linker flags. pkg-config will also merge the linker flags for all libraries you specify on its command-line. Not sure though if there is also a way to test the result. Anyway, before you break samba for other people, I can also submit my patch to buildroot instead.
also on uCLibc binaries are in ELF format. This is the output of my OpenWRT's libstd++ when I run readelf -a on it: Dynamic section at offset 0xec contains 29 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libm.so.0] 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x00000001 (NEEDED) Shared library: [libc.so.0] 0x0000000e (SONAME) Library soname: [libstdc++.so.6] 0x0000000c (INIT) 0x25ae4 this looks pretty much like even on uCLibc based distros this is the way binaries (including libraries) contain the information where to look for the symbols they use.
closing as this looks like a dependency issue if that avahi lib or a resolver issue of uCLibc