[Ecls-list] Build system on Cygwin

[Jean-Pierre Flori]

2012/8/17 Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com>:
> On Fri, Aug 17, 2012 at 12:13 PM, Jean-Pierre Flori <jpflori at gmail.com>
> wrote:
>>
>> 2012/8/15 Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com>:
>> > Feel free to do so, but you will have to make sure you fix the fact that
>> > ECL
>> > is currently NOT using import libraries in any of the ports (cygwin,
>> > mingw,
>> > msvc)
>>
>> ECL build system does not produce import libraries on Cygwin, MinGW
>> and MSVC (although I have not and will not test this last target).
>> What I would propose is to let the build system follow the naming
>> scheme proposed by Cygwin (renaming lib/ecl.dll to bin/cygecl-xxx.dll)
>> and MinGW (renaming lib/ecl.dll to bin/libecl.dll).
>
>
> What I meant is precisely this:
>
> Currently ECL only creates one file (*.dll or *.fas) per compiled file. When
> it has to link them together with an executable, it uses the fact that both
> cygwin and mingw handle DLLs directly, providing the files and the -lecl
> flag. I am just worried that if you change the name to cygecl.dll or
> whatever convention is used, the -lecl would stop to work, as cygwin might
> look for a file libecl.dll.a (explained in the webpage you linked).
>
> That's all. I am not demanding that you remain silent :-) I just want to
> make sure that the change in the name convention does not break building ECL
> or its tools.
I see your point.
On Cygwin at least, when the linker is given the -lecl flag, it will
look for files in PATH in a certain order.
First libecl.dll.a, then ..., then cygecl.dll, then ... then ecl.dll
IIRC (unfortunately the nice webpage here
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/win32.html
seems down now)
So if we only have cygecl.dll every thing should be fine, provided
xxx/bin is in PATH (or wherever it was installed).
If we have both libecl.dll.a and cygecl.dll, then ld will first find
the import library and use it to link to the real library file
(cygecl.dll).
>From what I understand, the linking process will be somehow slower,
but I'm not even sure there will be any difference in the produced
executable/library using the share version of the ECL library.
You could even delete the dll.a file after linking and it should work fine.
And if you really want to link directly without the import file
detour, you could give explicitly the cygecl.dll path to ld, rather
than -lecl.

I presume the situation on MinGW will be the same.

With MSVC (which I assume to be the Microsoft compiler suite), and
from what I read about this import library hell, I'm quite surprised
it was possible to link to ecl.dll if only such a file was produced!
Potentially MSVC does its own magic.
But as I mentoned earlier, I never used MSVC.
As there seems to be a free version floating around, I think I'll give
it a try...
What pieces of the ECL suite do actually link to ecl.dll?

Oh, and a final remark, on Cygwin at least, the dllimport magic is broken.
The dllexport stuff gets defined in the headers at build time because
"cygwin" is defined by the build system.
But when included from another project (let's say Sage :), the
dllimport is included only if "cygwin" is defined... which has no
reason to be.
The easiest fix I found was to define "cygwin" when "__CYGWIN__" is
(and that gcc does define on Cygwin).

Best,

-- 
Jean-Pierre Flori