2012/8/17 Juan Jose Garcia-Ripoll <juanjose.garciarip...@gmail.com>: > On Fri, Aug 17, 2012 at 12:13 PM, Jean-Pierre Flori <jpfl...@gmail.com> > wrote: >> >> 2012/8/15 Juan Jose Garcia-Ripoll <juanjose.garciarip...@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 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
