LDNS on Windows, take 2

After many attempts, and just recently finding posts on Google groups from someone else trying to do the same thing (use ldns from XPCOM) it’s become obvious that linking the VC++ built XPCOM libraries with Cygwin built ldns just won’t work. The library formats simply aren’t compatible.

Since my extension obviously needs to run within VC++ built Firefox / Thunderbird, I have a couple of choices. One would be to go back to the MS DNS library and work around the bugs. That would basically mean having to parse out the raw DNS record data according to the record type – very tedious. The other way is to modify ldns to build under VC++. Since I want to be able to build and run on Linux as well, I’m taking the latter approach.

So far I’ve been able to get ldns and the associated “drill” utility to build on Windows. It’s taken a bit of modification to get to that point of course. I may have overdone it a bit. There was some evidence in ldns of support for Windows, specifically some defines related to using winsock. But this seemed far from complete and there were many other changes that were needed. I’m sure I’ve probably broken the Linux build though, so getting both platforms supported with the same source is going to need more work. But for now I’m please to have been able to get this far fairly quickly.

This entry was posted in General, LDNS, Windows. Bookmark the permalink.

4 Responses to LDNS on Windows, take 2

  1. kdoran says:

    Eddie,

    Hello. It seems you are making excellent progress. I stumbled across your blog 2 days ago, and find your last 3 posts very interested an very related to some work I am doing. I am working on a project that soon to go open source. It combines several parts, one of which is an XPCOM component, and all of which need to be cross-platform. I am currently working on a DNS resolver to look up NAPTR records to be integrated with my code. I haven’t found a lot of resources relating to work in this areas, so you can see why your project interests me.

    LDNS is at the top of my list as a base library to build upon for NAPTR record look-up. I like it for many reasons. However, while I have a working example in Linux based on LDNS (successful look-up of NAPTR records), I have not had much luck with it on Windows. In fact, I’m not even sure it is being compiled correctly (have tried MinGW and Cygwin). Do you think you could provide me with the steps you took to compile it? I want to make sure it it fairly robust as a cross-platform solution before I integrate it into my project.

    The DNS resolver is going to be part of my core library, so it will be called from my XPCOm component ultimately. I was hoping LDNS would work in this fashion, but judging from your experience, it may not. Here are my thoughts though:

    1. Have you tried linking LDNS to a non-XPCOM library to create a .lib or a .dll that will then be linked by XPCOM. In other words, wrapping your ldns library in a traditional MS library that can be compiled with VC++. I wonder if that would play more nicely with XPCOM, or if the component will still crash once it reaches LDNS code. A very easy way to get started with this would be to look at the DotTelUtils (which is C/C++) project from Telnic. I noticed that Telnic was mentioned in a reply to your August 7 post. I was able to use their DotTelUtils library to have NAPTR look-ups running on a Linux machine with very little work. Check out this link: http://dev.telnic.org/trac/wiki/DotTelUtils I think that it would be very easy to modify the DotTelUtils library, which uses LDNS, to provide exactly what I need (right now it only looks up NAPTR records storing telephone numbers and TXT records, but that is just a filter) It also claims to be cross platform, but requires LDNS to be compiled (so I have not gotten it running successfully on Windows). My line of thinking though is that DotTelUtils.dll might work with XPCOM, even though it relies on LDNS.

    2. If (1) is not an option, I agree the best approach is to port LDNS to VC++ compatible code. Congratulations on your initial success in this area! As far as keeping it working on LINUX, the quick and easy solution would be to keep the orignal code, and use #ifdef statements to switch between the orignal coade and your modifications. So if compiling on Linux, it uses the original code, if compiling in VC++, it uses the Windows code. If you are having to make major changes, you could just make a windows version of all the C files that are changed (ie, resolve.h and Winresolve.h), and pick the one you want with #ifdef [OS].

    All that being said, I am interested in your progress, and would like to share our findings moving forward.

    Best of luck!
    -Kevin

  2. kdoran says:

    3. I forgot to mention this because I haven’t investigated it much, but Andreas Haberstroh of iBusy.com has a DNS library advertised to be cross platform and asynchronous, build on the Boost C++ library. Check out his 2 articles about it here:

    http://www.ibusy.com/articles/software-development/
    (see 17 July 2007 and 23 August 2007)

    The code is available through the site’s SVN server (you have to register to view it – check your spam folder after registering as that’s where my confirmation link ended up) I contacted Andreas who replied with some help getting started, so there may even be some active support taking that route.

    Don’t know how familiar you are with the Boost library, but it is cross platform and already a dependency for my project so I was excited that I could get more use out of it (if I do go this route). It has a lot to offer and is easy to use, so you may find other use for it as well.

    -Kevin

  3. Eddie says:

    Kevin,

    Thanks for the info! I haven’t tried number 1. My gut feeling is that it probably won’t work. I don’t think the problem is specific to the XPCOM libs, but just a general problem between MinGW / Cygwin generated libs and VC generated ones. But I’m nowhere near an expert on that so I may give it a whirl.

    Actually, that does give me another idea. What I was doing previously was building ldns separately via Cygwin, then attempting to build and link my extension via Cygwin as well. I wonder if I would have better luck using Cygwin for ldns and VC for the extension. I sort of expect to have a similar problem, just in the other direction (VC not being able to link to a Cygwin lib) but it might be worth a shot.

    I also started out looking at the DotTelUtils. Gave me the general idea for what I wanted, but at least when I looked at it it only paid attention to phone entries in the NAPTR. I modified it a little to pull out some other types of data (e.g. email).

    As for my progress in porting ldns, the mods I’ve made so far are rather messy, but as you mention they’re mostly playing around with #ifdefs and #defines to tweak some data types and function names. I did have to find replacements for gettimeofday() and getopt() (needed by the ldns ‘drill’ app), but there some open source replacements that I was able to integrate. One change I still need to make though before anything will work is modifying the initialization code. ldns normally pulls the DNS servers from the Linux config files, but of course Windows doesn’t use that and has to get the servers from the registry. I made that mod earlier to my Cygwin code but need to bring the same mod to my current port since I started over with fresh ldns source. I hope to be able to get that working this weekend or early next week. Once I have it doing something useful I’ll gladly share it around. It would be great to have someone more familiar with cross-platform issues take a look at it and help clean it up. I’m sure I’ve completely broken the autoconf based stuff on Linux.

    – Eddie

  4. kdoran says:

    Eddie,

    Good to hear from you. I will get back to look at my project tomorrow. I think my course of action will be to go forwards LDNS as the base resolver library for the Linux build of my overall project (since as far as I have found, it appears to be the winner for C/C++ Linux DNS queries), which should take very little effort to get up and running. Once I have that working properly, I will begin looking at getting it running on Windows (hopefully using LDNS as well).

    I noticed the same thing with DotTelUtils. Luckily its source code is easily modifiable. I think I will be able to modify it to suit my needs. In addition to the limitations you noticed, I think it will need to be modified to properly do recursive NAPTR lookups and regex handling for U-NAPTR lookups. (see RFCs 3401 – 3404, and RFC 4848).

    Thinking more about cross-platform LDNS… while it would be nice to have VC++ compatible code and Linux compatible code in the same source, it might be more simple/practical to just focus on the VC++ version without worrying about getting it to run on Linux, since we already have a working version for that. In the end it is just a matter of linking against ldns.lib in one environment and ldns.a in the other.

    On a related note, my team and I have been using cmake to manage our project. http://www.cmake.org/
    Given source code and a few rules, it is capable of generating Visual Studio projects in a Windows environment, and makefiles in a Linux/Unix environment. It has a bit of a learning curve, but simplifies developmnent / testing immensely.

Leave a Reply