[Ecls-list] Build system on Cygwin
Jean-Pierre Flori
jpflori at gmail.com
Fri Aug 17 10:13:25 UTC 2012
2012/8/15 Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com>:
> On Tue, Aug 7, 2012 at 7:22 PM, Jean-Pierre Flori <jpflori at gmail.com> wrote:
>>
>> Still working on building Sage on Cygwin, we realized that the
>> produced ECL shared library built on Cygwin is called ecl.dll.
>> While this should not be problematic, we also have another file called
>> ecl.dll in Sage which builds the interface between Sage and the former
>> ecl.dll, and which should be linked to the it.
>
>
> Hmm, how is this ECL's fault? I mean, Sage's use of ECL is second to the
> development of ECL itself :-)
Thats definitely not ECL fault and I'm aware of that, I just wanted to
provide some info on our problem there.
>
>>
>> My point here is that if ECL would follow the naming scheme proposed
>> by Cygwin (as libtool does for example):
>> http://cygwin.com/cygwin-ug-net/dll.html#dll-build
>> this would have the fortunate consequence to make the Sage problem
>> disappear.
>>
>> I've proposed such a patch on Sage Trac in ticket #9167
>> (http://trac.sagemath.org/sage_trac/ticket/9167) (it also tweaks the
>> build system on MinGW to follow http://www.mingw.org/wiki/sampleDLL).
>> If you think this makes sense, I can post a patch on ECL sourceforge page.
>
>
> 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)
I don't really understand your point about "NOT using import libraries".
You suggest that if I provide a patch it should produce import
libraries on the three platforms (or remain silent forever)?
By itself, ECL will not use import libraries, even though they get
generated, whence my confusion.
There will only be a small additional file produced, and a different
naming scheme used.
To make myself hopefully clearer, here is what I get from the current situation.
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).
I do not know if there is any convention in the real Windows world,
ecl.dll seems perfectly fine for me there.
And while we are at it we could also produce import libraries
(apparently necessary to link to xxxecl-xxx.dll with the Microsoft
linker, but you still have the possibility (and it's advised to do so)
to directly link to the dll with the Cygwin and MinGW linkers).
As a side effect such changes would also solve the Sage problem.
A final remark is that the main ECL executable ecl.exe won't be
affected by all these changes (if it statically links to the object
files as I think).
>
> Juanjo
>
> --
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)
> http://juanjose.garciaripoll.googlepages.com
--
Jean-Pierre Flori
More information about the ecl-devel
mailing list