...

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

...

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.

I guess the solution closest to the gnu conventions would be to install the dll (and the dll.a?) in the "system path".

That might be, but I know of no project doing that (you'd run into all sorts of security issues).

It might make some sense to install it in the same directory as the few nettle executables, but that won't solve everything. E.g., with regards to gnutls, you'd need the nettle dll located in the same directory as the gnutls executable, which nettle doesn't know about; it may or may not be the same directory as nettle's $bindir. So you'd probably need to copy it around anyway.

Perhaps it'd be useful to ping other projects and get their take? It couldn't know about it, that's right, b/c you'd need to build and install nettle before gnutls. But gnutls could know about nettle and install to the same location (pkg-config really helps here). But really it's the person doing the build that should have the discretion to place the files where they want. The --sharedlibdir idea would work for me. By default it could point to --libdir.

A related question is how to run the testsuite using the4 shared libraries; do you need to copy the dlls into the subdirectories with executables which are run by the testsuite, or is there anything analogous to LD_LIBRARY_PATH (which is used for running the testsuite with ELF shared libraries).

On Windows, you can either copy the dlls into the exe's directory or put the dll's directory in the front of the "PATH" env var. The easiest thing to do is to copy it (windows doesn't do soft links) and then use relative paths for everything so you don't run into issues with unix-style paths vs. windows-style paths (/bin/ vs C:\msys\bin).

When I tried it, autoconf seemed to not be included in the msys installation. But I don't remember much of the details.

You have to put together your own msys system -- using their old installer didn't provide you with all the tools that you can get directly from the sourceforge page. The msys/mingw folks are working on a solution through their "mingw-get" application. I personally use a batch file I wrote to download and setup my environment. I'd be happy to point you to a place where you can download it for your own use.