Fix compilation on OSX

[saghul]

Compilation fails on OSX with the following error:

duplicate symbol _getdns_error in:
    build/temp.macosx-10.9-intel-2.7/getdns.o
    build/temp.macosx-10.9-intel-2.7/pygetdns_util.o
duplicate symbol _getdns_error in:
    build/temp.macosx-10.9-intel-2.7/getdns.o
    build/temp.macosx-10.9-intel-2.7/fd_poller.o
duplicate symbol _getdns_error in:
    build/temp.macosx-10.9-intel-2.7/getdns.o
    build/temp.macosx-10.9-intel-2.7/context.o
ld: 3 duplicate symbols for architecture x86_64

This PR fixes it by making getdns.c the only compilation target.

[MelindaShore]

Hi, Saúl: I am not seeing the same error when I build either branch on MacOS 10.9.2 or 10.7.5, using either gcc or clang. I'm using Apple's Xcode in both environments. Can you provide more background on your build environment? Does it happen when you do a clean build (clone into a new directory and build that)?

As a matter of style I prefer not to #include c files in other c files, but either way if this really is a problem we'll get it fixed.

[saghul]

Hi Melinda,

I'm using OSX 10.9.4, using the following clang version:

$ cc -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix

That's the one corresponding to Xcode 5.1. I'm compiling it as follows:

export ARCHFLAGS="-arch x86_64"
python setup.py build_ext --inplace

Thanks for the quick response!

[saghul]

Ah, I just found a simpler fix: declare getdns_error as extern in the include file. I still left the commit with the guards there since it's good practice anyway.

Can you have another look?

[MelindaShore]

Hi, Saúl: Looks like you're running an old version of the code. That one was fixed awhile ago, as part of fixing a problem in the way exceptions were being "bubbled up". You'll probably want to pick up a new version of the module, since the newer version has bugfixes plus support for asynchronous lookups. I'm going to take the liberty of closing this, since it's already fixed.

[saghul]

Well, FWIW the problem does indeed not show up on master, but it does on the develop branch, which is "newer".

[MelindaShore]

If you take a look at the current version of the code, you'll find that there's no longer a declaration for getdns_error in getdns.c.

[saghul]

Sure, I do see that. I'm a bit confused, however: the async support is only
on the develop brach on GitHub, which is 11 commits ahead of master. I am
able to compile master, but not develop.

On Sunday, August 24, 2014, Melinda Shore [email protected] wrote:

If you take a look at the current version of the code, you'll find that
there's no longer a declaration for getdns_error in getdns.c.

—
Reply to this email directly or view it on GitHub
#20 (comment)
.

/Saúl
bettercallsaghul.com

[MelindaShore]

Hi, Saúl: this really wasn't ringing any bells, so I went through the code, back to the beginning, and while there was a declaration of getdns_error in initgetdns that should not have been there (and which has since been long gone), there was never a global declaration of getdns_error in getdns.c that I can find, browsing the repo. Are you sure that you're working with a clean clone of the source?

[ngoyal]

There seems to be confusion. What's the latest branch that users should build out of? Master was last written to on 6/16. Dev 4 hours ago.

[MelindaShore]

On 8/24/14 4:36 PM, ngoyal wrote:

There seems to be confusion. What's the latest branch that users should
build out of? Master was last written to on 6/16. Dev 4 hours ago.

Right - develop is the one containing the code that's about to be
released. I think this one is pretty straightforward - my guess is
that he's got local changes and is merging from the repo. I need to
make sure he's good now.

I'll be releasing the new stuff tonight.

Melinda Shore
No Mountain Software
[email protected]

"Software longa, hardware brevis."

[saghul]

Sorry for the delay, timezones!

Now that I'm fully awake, I tried this again. And it continues to fail. Moreover, master now also fails, since develop was merged into it.

Maybe this clang version is very picky (it is), but the error seems quite legit to me:

• getdns_error is declared in pygetdns.h https://github.com/getdnsapi/getdns-python-bindings/blob/master/pygetdns.h#L40
• pygetdns.h has no include guards, so it will be included with every source file which itcludes it thus leading to multiple declarations
• getdns.c needs to define it, as it initializes it here: https://github.com/getdnsapi/getdns-python-bindings/blob/master/getdns.c#L1496

I can confirm this problem doesn't happen when compiling with GCC on a Linux system, however.

[ioc32]

FWIW compiling from @saghul's fix-compilation branch works for me [0] under [1].
Trying to compile getdnsapi/getdns-python-bindings/master fails [2].

Thanks!

[0] https://gist.github.com/ioc32/4f0bab24c01d982e6cc8
[1] Darwin rigel 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014; root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
[2] https://gist.github.com/ioc32/4310ebf14abfca3d40c6

[MelindaShore]

Someone was complaining yesterday about differences in Python installations with the same version numbers, and I realized that I'd been using a locally-built copy compiled from source. When I switched back to the default MacOS installation I began seeing the problems that Paul reported. I'm reopening this, and also creating an issue tracker issue.

[saghul]

Thanks, Melinda!