> Sorry for the delay guys, I got rather busy over the holidays. I see > we're now discussing a patch for next stage 1.
No, not necessarily, the patch is specific to Ada on Windows so the risk is quite low. > 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. This indeed sounds compelling enough. > 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. If all the other runtimes do it, I think we should do it too. Pacal, what do you think? -- Eric Botcazou
