libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libltdl exports no symbols (cygwin)


From: Ralf Wildenhues
Subject: Re: libltdl exports no symbols (cygwin)
Date: Wed, 31 Jan 2007 20:19:10 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

[ apologies for the resend ]

Hello Charles, all,

* Charles Wilson wrote on Wed, Jan 31, 2007 at 06:10:13AM CET:
> Ralf Wildenhues wrote:
> >* Eric Blake wrote on Tue, Jan 30, 2007 at 06:00:00PM CET:
> >>Should we also mention the side effect that you must now mark
> >>explicit exports, since you can no longer rely on auto-imports?
> >
> >This whole issue seems not good for branch-1-5.  I'm pondering backing
> >out all related changes from branch-1-5; that is, the NEWS update and
> >the LT_GLOBAL_DATA/LT_SCOPE change of 2007-01-28, as well as the
> >DLL_EXPORT change of 2006-06-01.  We cannot do such a big change for
> >1.5.24, that will affect all users of --with-included-ltdl. 
[...]

> And if you try to switch MinGW libtool to not define DLL_EXPORT...hoo 
> boy. A *LOT* of MinGW ports rely on that behavior...

I didn't say that I intended to change anything wrt. MinGW.
I merely suggested a somewhat radical change to allow me to
exclude a possible regression.

> So, on one side we have (a) a bunch of MinGW ports, (b) every cygwin 
> port *I* know of except *CVS* m4, plus *released* versions of gettext.

Good.  That's what I need to know: that the changes have been tested and
seem to work well in practice.  Thank you.

> On the other...*CVS* m4.

> >The patches
> >were not introduced to fix a regression, rather something that we can
> >see as an improvement,[...]

> Wait, you're contradicting yourself.  The 2006-06-01 changes were there 
> to fix a regression that popped up with gettext

That's not true.  Just because Gettext's needs changed, that isn't a
Libtool regression.

Charles, I need someone to take responsible care of Libtool on Cygwin;
I don't have enough time nor experience to do this myself.  And I simply
feel that I need to be disruptive in email at times in order to wake
people up and elicit their response.

> By reverting the change 
> (e.g. because it causes regressions for *CVS* M4) to "fix" *CVS* M4[*], 
> you cause a regression with *released* gettext.  Why is THAT ok?  Why 
> can't we say that *CVS* M4 should require CVS libtool, and "fix" this 
> issue there?

If the issue *is* with CVS M4 only, then I certainly don't have a case.
But I did not know that when writing the last email.

> Do what you want, but I am strongly inclined to continue future official 
> cygwin releases of libtool RETAINING the 2006-06-01 and 2007-01-28 
> changes. I do not look favorably on releasing yet ANOTHER 
> backwards-incompatible version of libtool/libltdl on the cygwin 
> platform, while pretending that it is still compatible.

Do you have more changes in Cygwin's Libtool that aren't in branch-1-5?

> >For HEAD, guys, if you want this really fixed then may I suggest to take
> >another look at Bruno's suggestions:
> ><http://lists.gnu.org/archive/html/bug-gnu-utils/2006-05/msg00026.html>
> 
> For 2.2, I tentatively agree (but...[**]). For 2.0 -- GOOD GREIF, 
> PEOPLE,

Yes.  I'm fine with postponing things to after 2.0, certainly.

> can't we just release the G-D thing and be done?  I remember in 
> Jan 2005 we were gonna release 2.0 "real soon now".  This is freakin' 
> ridiculous.

Letting off steam is one thing, but I don't buy into the criticism here.
If you want 2.0 released ASAP, then you're welcome to help, just as
everyone else is.  If I continue to be the only one looking at
regressions, most of which I did not introduce into the code, then it
will simply take as long as it will take; I cannot and will not invest
more work into Libtool than my available free time and motivation allow
me to.

That said, I do hope there aren't very many more changes needed; but
of the few that are, some are a bit tricky.

> >And certainly we should
> >document user-level-required changes in NEWS.
> 
> Well, yeah -- but make sure the proposed documentation is ACCURATE, first.

I'd appreciate any assistance here that you or others can give.  It
certainly won't be much more accurate than you (or others) explain
it to me.  Your other response (to Eric) sure looks very helpful here.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]