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
