This is the mail archive of the
mailing list for the GCC project.
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
- From: Dave Korn <dave dot korn dot cygwin at gmail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: Christian Joensson <christian dot joensson at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Pascal Obry <obry at adacore dot com>
- Date: Wed, 22 Feb 2012 15:30:34 +0000
- Subject: Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
- Authentication-results: mr.google.com; spf=pass (google.com: domain of email@example.com designates 10.180.104.4 as permitted sender) firstname.lastname@example.org; dkim=pass email@example.com
- References: <CABxpwDmKSH89wd5-e8kriU5q24sirjmJqCZY2JE9W81kMChejQ@mail.gmail.com> <firstname.lastname@example.org> <4F0AC888.email@example.com> <firstname.lastname@example.org>
On 09/01/2012 11:56, Eric Botcazou wrote:
>> 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?