Mail Archives: cygwin/2009/04/06/12:30:15
On Apr 6 16:48, Dave Korn wrote:
> Christopher Faylor wrote:
> > On Mon, Apr 06, 2009 at 03:21:26PM +0100, Dave Korn wrote:
> >> ...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.
I'm far from an expert in this area so this might be an idea somewhere
in the range between naive and braindead, but I'm daring today:
Wouldn't it help if libc.a, libm.a etc. wouldn't export any symbols at
all? I mean, eventually there's libcygwin.a linked in which satisfies
all of the requested symbols. What would break if the secondary libs
pointing to cygwin1.dll would be stubs?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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/
- Raw text -