[Pidgin] #16883: Building Bonjour broken on Mac OS X

Mon Feb 1 16:56:44 EST 2016

#16883: Building Bonjour broken on Mac OS X
---------------------+------------------------
 Reporter:  clokep   |      Owner:  datallah
     Type:  defect   |     Status:  new
Milestone:           |  Component:  Bonjour
  Version:  2.10.12  |   Keywords:  regression
---------------------+------------------------
 I found this while updating Instantbird to v2.10.12 of libpurple. It seems
 that #16507 broke building of bonjour since code is always forced down the
 Windows code path (LINK_DNS_SD_DIRECTLY was essentially the Mac OS X code
 path where you would statically link to the Bonjour libraryes available on
 Mac OS X).

 I'm not sure of the best fix for this, but there was some IRC conversation
 about this:


 {{{
 4:03:54 PM - clokep_work: flo-retina: If you have a couple of minutes...in
 the logs there's some discussion of bonjour DNS and upgrading libpurple:
 http://log.bezut.info/instantbird/160201/#m117
 4:03:57 PM - clokep_work: Could maybe use your expertise.
 4:30:17 PM - flo-retina: hmm, why is that LINK_DNS_SD_DIRECTLY variable
 removed? :-S
 4:32:05 PM - EionRobb: from memory, I think we decided to include the
 dns_sd file directly to make it easier to compile (not needing to grab
 sdks or something)
 4:35:16 PM - clokep_work: EionRobb, flo-retina: AFAIK we were using that
 only on Mac though?
 4:36:44 PM - flo-retina: EionRobb: does that mean you are now shipping the
 Bonjour SDK on Windows? Wasn't the license incompatible?
 4:37:42 PM - flo-retina: ah, the removed lines are actually "#ifndef
 LINK_DNS_SD_DIRECTLY"
 4:37:54 PM - flo-retina: so it's going unconditionally now through the
 Windows code path (dynamic linking)
 4:38:01 PM - flo-retina: so yeah, the Mac code path has been removed :-S.
 4:41:13 PM - EionRobb: clokep_work: the apple bonjour is used for windows
 and osx
 4:41:30 PM - clokep_work: EionRobb: I understand that, we only set
 LINK_DNS_SD_DIRECTLY on OS X though.
 4:41:52 PM - EionRobb: flo-retina: its just the header and its 3-clause
 bsd, so afaik its ok - but I don't remember the full story with what
 happened there
 4:42:01 PM - clokep_work: flo-retina: That was my thought too. :-S We can
 keep that as a patch locally only, I guess.
 4:42:09 PM - clokep_work: Or try to argue it should be added back
 upstream.
 4:42:25 PM - EionRobb: clokep_work: if there's a compiler error on osx in
 libpurple then yeah, definitely should be upstreamed :)
 4:43:04 PM - clokep_work: EionRobb: I'm not sure if it *can't* be compiled
 or it can't be compiled the way we were trying to compile it. ;)
 4:43:19 PM - clokep_work: flo-retina: So would maybe making it a dynamic
 prpl fix it? :-S
 4:43:47 PM - clokep_work: Or...no we're talking about how it links to the
 bonjour stuff, aren't we?
 4:44:10 PM - EionRobb: clokep_work: good point.  I might try building
 libpurple with macports/fink/whatever and see what happens
 4:45:05 PM - clokep_work: EionRobb: I suspect it will break, there's weird
 things in that code:
 https://bitbucket.org/pidgin/main/src/0fc4638f51ef4985b7778bba6a0d2b0bfd6b5d9f/libpurple/protocols/bonjour/dns_sd_proxy.c?at=default&fileviewer
 =file-view-default#dns_sd_proxy.c-59
 4:45:11 PM - clokep_work: I highly doubt that will work on Mac. :)
 4:45:46 PM - EionRobb: oh boy
 4:46:03 PM - clokep_work: I have a feeling that ifdef was removed without
 understanding why it was there, yeah.
 4:46:16 PM - EionRobb: :D
 4:47:11 PM - clokep_work: Are bugs still on pidgin.im or are they on
 BitBucket now? :S
 4:48:14 PM - EionRobb: still on trac on developer.pidgin.im
 4:49:13 PM - EionRobb: do you think its best to have a #ifdef _WIN32 check
 in there, or bring back the LINK_DNS_SD_DIRECTLY ?
 4:49:43 PM - EionRobb: or maybe have the LINK_DNS_SD_DRIECTLY be auto set
 if __APPLE__ is defined?
 4:49:56 PM - flo-retina: that would be nice
 4:50:15 PM - flo-retina: I think we just set that define from a makefile
 when building on mac right now.
 4:50:26 PM - gerard-majax has left the room (Quit: Ping timeout: 121
 seconds).
 4:50:37 PM - clokep_work: Yep we set it from a Makefile.
 4:52:46 PM - EionRobb: that function loading code is win32-specific though
 which is dumb... maybe I want to not link directly but have it work on osx
 - it probably should use gmodule instead of wpurple_* funcs
 4:54:36 PM - clokep_work: EionRobb: So we use mdns_win32.c on Mac also:
 http://hg.mozilla.org/users/florian_queze.net/purple/file/tip/libpurple/protocols/bonjour/moz.build
 4:55:02 PM - EionRobb: yeah, should be renamed to mdns_apple.c
 4:55:19 PM - flo-retina: EionRobb: we statically link on Mac, because the
 Apple libraries are guaranteed to exist on OS X.
 4:55:28 PM - flo-retina: that function loading code is really only needed
 on Windows.
 4:55:33 PM - EionRobb: fair enough
 }}}

--
Ticket URL: <https://developer.pidgin.im/ticket/16883>
Pidgin <https://pidgin.im>
Pidgin