but it generates shared library names in the unix/linux style (e.g. libnettle.so.4) instead of Windows-style: libnettle-4.dll. I can simply rename the dll and it'll work, but it's a pain and not in line with most other open source projects.
I hope this problem is solved properly by your patch to configure.ac?
Yes, I sent this out before I came up with the patch.
Also, when I use --enabled-shared --disable-static, my configure options are not respected.
Nettle doesn't have any configure flag --disable-static. Maybe it should have. I have been thinking that building the static libraries shouldn't hurt, but I can see that one might not want to *install* them.
You're right, I didn't see the configure warning at the time. It doesn't hurt, except as you said, I didn't want them installed. I just added an extra line in my script to delete them. Not a big deal...
When I use typical configure options such as --prefix= --libexecdir= --bindir= --libdir= --includedir=, they're not honored. e.g. I specified a different bindir for the shared libs, yet they still ended up in the --libdir directory.
Libraries are supposed to be installed in $libdir (or by default, sometimes in $prefix/lib64 or the like depending on ABI). Are there any other files that have been installed in a different directory from what you expected? If so, please provide the configure command line, the file name in question, and the directories where you wanted the file and where it actually was installed.
Are windows dll files usually installed in bindir rather than libdir? I hesitate to change the default, but if you convince me that it's the right way, I'll consider it. A ---sharedlibdir or similar would make some sense to me, but I'd prefer to be consistent to what other GNU packages do. Anybody else doing this? You could of course set libdir to point to the same directory as bindir, but then you'd get the static libraries there as well, which I guess is undesirable.
I'm unsure what the general solution for Windows is. But executables that are built that rely on the shared libraries cannot run if the dll's aren't either in the system path or in the same directory as the executable. The only honest argument I can make in this regard is that from gnu.org, libdir is meant to designate "The directory for object files and libraries of object code." On posix/unix-ish OSes, gcc can link against the shared library itself and doesn't need object files such as libnettle.dll.a, so the shared library itself is the "library of object code." Under Windows, *.dll.a (e.g. libnettle.dll.a) is a separate "library of object code" from the shared library itself (libnettle-4-0.dll) needed for linking. However, my understanding is that it's a bit fuzzy these days b/c gcc can link directly against the .dll itself now.
In the end, however, it's not a big deal to add a few extra lines to my script to move the files around as needed.
This may result from the use of an older autotools/libtool setup, but I'm unsure.
I'm building natively using GCC 4.5.1 (x86, 32-bit) from the MinGW-w64 folks on Windows 7 64-bit.
Can you run autoconf natively? When I gave it a try a while ago, I couldn't build autoconf (under msys) using the windows port of perl (I think I used the "strawberry" flavor) due to conflicting file name conventions. Then I tried to compile my own perl under msys, but this didn't work out of the box because perl' s configure script didn't recognize the system.
Yeah, I can run it natively. I use activestate perl (for now). When the msys guys come out w/ a newer build of perl, I'll try that out, though. But I haven't ever tried to build autoconf itself w/ msys.
Thanks, - David