[avahi] [PATCH] make building with --disable-static and DBUS work

Nix nix at esperi.org.uk
Thu Nov 24 06:58:04 PST 2005

On Thu, 24 Nov 2005, Lennart Poettering said:
> On Thu, 24.11.05 01:33, Nix (nix at esperi.org.uk) wrote:
>> Right now (well, as of Avahi 0.6), avahi's building two libraries for
>> libdbus-common; one with -fPIC enabled and one not. It's building both
>> of these with --all-static in an apparent attempt to force a convenience
>> library build.
>> However, that's not what --all-static does; you end up with a library
>> which when --disable-static is specified is *empty*, so avahi-daemon and
>> avahi-client fail to build.
> Mmm, I don't understand why the library is empty in that case. Please
> exlain. Honestly, I never tried to compile avahi statically, so I
> don't have much experience with this.

Because when you specify --disable-static, libtool assumes you want *no*
static objects; --all-static is for the case when you have a library whose
contents should only be populated for static builds.

The libtool docs don't say as much; they probably should :(

>> This patch fixes that, ditches the mostly useless no-fpic version (who
>> cares if a tiny bit of rarely-executed code in a root daemon is PIC?
>> Most distributors these days will build network-exposed daemons such as
>> Avahi as position-independent executables anyway) and renames the
>> libraries to something more obviously Avahiish. (You might not want the
>> latter; I did it out of paranoia in case my changes led to the library
>> somehow being installed ;) )
> Some minutes ago i commited r1028 to SVN which contains a different
> fix for this.

That's excellent: as long as it gets fixed I'm happy :)

>               Instead of building a static library of these two files
> i added them directly to the _SOURCES list of the binaries that need
> them. This is much simpler and doesn't build with -fPIC unless it is
> needed.

Yep, that works.

(One thing you might dislike is that putting subdirectory names
explicitly into SOURCES can break dependency analysis under some
Automake releases, leading to things not being rebuilt when they
actually need to be... alas I can't remember which releases these are.
I just tried to reproduce it, and, well, Automake 1.9.[56] are free of
this bug. It was probably sometime in the 1.8 series. Nobody will care
except for people doing development, anyway, so all you really need to
do is make sure *you*'re not being bitten by this bug.)

> Unless this doesn't work for your I will release this as Avahi 0.6.1
> tomorrow.

Release away! ... well, actually, I've got one more little build system
patch coming down the pipe first...

>> (as an aside, it would be nice if there were some way to email patches
>> like this without first having to subscribe to a mailing list. This is
>> the only piece of free software I've ever used that doesn't have *some*
>> non-subscription email contact address for patches and the like. Even
>> the rejection message is unfriendly, saying that I am `not allowed' to
>> send messages to the list, but not saying that this is because I'm not
>> subscribed...)
> You're welcome to do manual spam filtering for us! 

On a domestic ADSL line? Reliability problems, alas ;)

> fd.o doesn't run a spam filter (as it seems),

*boggle* shades of the FSF mailing lists of days of yore...

>                                               hence we disabled postings
> from non-members simply because the volume of bogus moderation requests
> exceeded what we could handle.

Run SpamAssassin over the mailing lists? :)

(and while you're here, thanks for polypaudio, too: lovely program. If
it eventually annihilates the dysfunctional ghosts of esd and arts,
I will be happy indeed...)

`Y'know, London's nice at this time of year. If you like your cities
 freezing cold and full of surly gits.' --- David Damerell

More information about the avahi mailing list