checking avahi-common/watch.h usability... yes checking avahi-common/watch.h presence... yes checking for avahi-common/watch.h... yes checking avahi-client/client.h usability... yes checking avahi-client/client.h presence... yes checking for avahi-client/client.h... yes checking for avahi_client_new in -lavahi-client... yes checking for avahi_strerror in -lavahi-common... no configure: error: avahi support not available Reproducible: Always
net-dns/avahi-0.6.25-r1 USE="autoipd dbus gdbm gtk howl-compat ipv6 mdnsresponder-compat python qt4 -bookmarks -doc -mono -test"
Attach your config.log and check if the lib provides the symbol.
Created attachment 236649 [details] config log too big to attach without compression
Created attachment 236655 [details] Symbol Table
First, avahi-client!=avahi-common Well, as the errors clearly show, the problem lies with avahi - it doesn't link avahi-common with pthread. Do you have its build log ?
ah, sorry. I misunderstood what you wanted. I assumed you were referring to avahi-common symbol table since that's where the configure check failed. Anyway, I know what the problem is. I don't know why I didn't recognize it earlier. Your comment about pthreads clued me in. I had been experimenting a few weeks back with openmp and seeing if any kind of benefits could be gained on SMP machines when building a system with openmp. I don't know what the problem is, but apparently this is a nasty bug somewhere; not really sure if it's with the compiler, linker, openmp, or even perhaps even something else. But apparently quite a few packages don't link against pthreads like they should when built with the -fopenmp build flag set. They DO work when you set BOTH -fopenmp and -lpthreads explicitly. I thought I had gone back and rebuilt everything that I originally compiled with -fopenmp, but apparently I missed avahi. Recompiled avahi, and now samba doesn't have any issues configuring. You will probably want to mark this as a duplicate of 323505 where I originally figured out what was going on and where other maintainers are still trying to figure out how to deal with this issue.
And I just realized you were the one who initially responded to that one too... :P
silly openmp :)
