"Hoyt, David" hoyt6@llnl.gov writes:
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?
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.
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.
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.
Regards, /Niels