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

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Ralf Habacker wrote:

> > > 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.
> Chris, please remeber, that this is an additional feature, not a hard rule. You
> can, but you aren't bound to it.

But that's not the impression your previous emails conveyed.  See 
libtool discussion below.  And this is a cygwin policy discussion that 
doesn't belong on binutils.  Geez.


> Second ld on platforms with only shared libraries and static libs does give you
> another choice, so on them the programmers have to live with this and I assume
> that there are more platforms where ld uses this case as otherwise.
>
> Anyway, that isn't what I have tried so say. The main meaning is "You can skip
> import libraries for mostly cases by a symbolic link to the respective dll" and
> second "Where are the reasons that this splitting should not be possible for the
> cygwin dll"

All well and good, Ralf, but Chris' comment grew out of your policy 
recommendations about *removing* the existing import lib support that 
libtool currently provides.   I know, you probably don't think you did 
that -- but you said your new change would simplify libtool.  This 
clearly means you assume that newlibtool would only support your schema, 
since supporting both current-schema and ralf-schema is OBVIOUSLY more 
complicated that the existing libtool code, and you wouldn't make the 
mistake of thinking that supporting both would somehow simplify libtool.

Then Chris pointed out that libtool MUST continue to support existing 
schema, which means that your proposal could only be supported by making 
libtool more complicated.  You argued that old schema no longer 
necessary, therefore it could be dropped (thus simplifying libtool). 
cgf said no, what about cygwin1.dll's import library (and others like it).

Everybody agrees that your new change -- if it works in all cases and 
doesn't break existing stuff -- is a good contribution, and should be 
added to ld.  Chill.

The only question is, Shall the cygwin community enforce this new usage: 
import libs are (in general) merely symbolic links to the runtime dll.

I think the answer is no -- cygwin shouldn't *enforce* anything of the 
sort.  But, it deserves a mention on the "How do I build a DLL" page.  I 
should probably put an example of that method in my dllhelpers package. 
 Maybe down the road, libtool could make "import libs" that way, 
provided a certain switch is given.   Even further down the road, maybe 
that could become the libtool default.

But no coercion.  No enforcement.  Just, "here's a nifty feature that'll 
speed things up and cut down on memory usage when linking."  If it's a 
marked improvement over current state of the art, it will (eventually) 
win.  There's no need to change any policies, IMO.

But first step is to just get the **** feature into binutils.  I know 
you're waiting on my testing, but I can't do that until the Thxgvng 
holidays.

--Chuck



--
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/