This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] skipping import libraries for performance reasons - direct auto-import of dll's


On Tue, Nov 26, 2002 at 08:30:01AM +0100, Ralf Habacker wrote:
>cgf wrote:
>> On Mon, Nov 25, 2002 at 01:46:50PM +0100, Ralf Habacker wrote:
>>>3.  ld works more like the linux version.  There are only static
>>>archives and shared libraries which could be linked directly without
>>>the indirection of using import libraries.  This simplifies for example
>>>libtool handling.
>>
>>I don't see how.  If anything it would complicate libtool handling
>>since libtool would have to know about both import libraries and dlls.
>>You can't just give up on import libraries, if for no other reason than
>>some libraries (like cygwin's for instance) contain a combination of
>>import data and static data.
>
>This and perhaps other libraries may be an exception, but couldn't this
>splitted like linux does ?  If I remember right, they uses a standard
>lib like glibc, which may be a shared lib and some kind of startupcode
>in an objectfile (static), which may be different for executable or
>dll's or other kinds of output.  Why does cygwin uses a specific way ?

It doesn't matter what cygwin uses.  Cygwin is an example.  Changing
cygwin doesn't solve the issue for some other DLL.  Telling anyone that
they have to reorganize their projects to accommodate 'ld' is pretty
obviously the wrong thing to do.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]