This is the mail archive of the cygwin 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: All clear [was Re: [1.7]: For the love of god, don't update!]


Christopher Faylor wrote:
> On Mon, Apr 06, 2009 at 03:21:26PM +0100, Dave Korn wrote:
>> So, that's why only some applications manifest this problem; it's only
>> the ones that explicitly pass -lc in their LDFLAGS.
> 
> So, given how limited the problem is, I don't think the alarmist Subject
> was really called for.  Anyone reading the subject would think that
> there was something seriously wrong with Cygwin 1.7 and that is not the
> case.

  Well, my apologies for the humorous subject line.  And it's not like I
stopped or went to sleep or anything else until I had sorted it out, and it is
a real bug that will make life difficult specifically for maintainers, who
might want to get on with porting their packages and not run into
complications that would cost them a lost day of time that could be better
spent by just hanging back overnight before upgrading.

>> ...Both exes have an IAT from kernel32 importing GetACP and Get
>> ModuleHandleA, and two single-entry IATs referencing _impure_ptr
>> (auto-import entries, pointing into the .text section) right at the end
>> of their .idata sections.  Where they differ is at the start of .idata;
>> the working exe has a single import table with 111 imports from
>> cygwin1.dll, where the failing exe has two import tables from
>> cygwin1.dll with 101 and 10 entries respectively.
> 
> I mentioned that things still work this way (as they have for the last
> eight years) when I announced the speclib rewrite and you said:

  The fact that they have worked for eight years is due to what appears only
to be a handy coincidence rather than an architectural design principle: that
every single library listed in between a user-specified -lc on the command
line and the compiler-spec-added -lcygwin /happens/ not to have an import
section.  As far as I can see it has always been incompatible with shared
compiler language runtime libraries, which would come after user-specified
libraries and before -lcygwin.

> "Yes, multiple import tables for the same DLL Name are definitely OK; if MS
> ever do anything to change this, we'll have real problems with auto-import."
> 
> Did you miss adding an "as expected" in the above paragraph?

  I didn't write it explicitly because it was, indeed, entirely as expected.
That paragraph (two) above is just a factual description of the observed
differences between the import tables.  It does not purport to be an
explanation of the bug, because it is, as you say, expected.  The *point* is,
that showing that they have almost the same contents differing only in the
presence of an extra import header and list tail entry underlines that it is
surprising that the one with /fewer/ headers should for some reason be
_bigger_, and this *suggests* that there is a problem in the construction of
the smaller idata section.

    cheers,
      DaveK


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.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]