On 17/12/2011 11:07, Eric Botcazou wrote: >> I am happily using this patch and await this to be committed. > > Only after the import library issue is addressed. What do the other > libraries > bundled with GCC do here?
Sorry for the delay guys, I got rather busy over the holidays. I see we're now discussing a patch for next stage 1. Well, to the point: I thinko'd slightly when I said that import libraries are "preferred"; it's the platform convention, and it's the way the MS toolchain works because it can't link directly against DLLs, but it's not (as I mistakenly assumed at the time, although did not explicitly state) any more correct or valid. It does however solve the problem of wanting the DLL to be in the /bin directory, while still needing something to stand in its place in the /lib directory so that the linker can find it without the compiler having to put -L$prefix/bin in the specs. It's also used on Cygwin and MinGW to address library versioning: the actual DLL has a numbered suffix to indicate version, but the import library is unnumbered, so you can just say -lblah as usual and automatically link against whatever the installed version of the DLL is without having to know the version suffix and specify it in the -l option. Ada doesn't need that, as it happens, because it always generates the specfile to explicitly include the version number of libgnat/libgnarl in the -l option, and doesn't try to keep the shared library compatible across point releases of the compiler, but it's how all the other runtimes work on Windows; they all put an import library in /lib and the DLL itself into /bin. Ada should work the same way, because otherwise you either need to point your PATH into gcc's private dir at runtime, or point your linker into /bin at linktime, neither of which are entirely neat solutions. cheers, DaveK