Dave Korn wrote:
> Hi all,
>
> [ re: ... don't update! ]
>
> Or at least, not without taking a backup of your Cygwin installation
> first
Right, panic over. If you do need to revert, it is possible, as long as you
remember to take m4 and alternatives along for the ride. (Also any other
package that shows up when you run " grep ctype_ptr /bin/*"; I spotted gvim
and ddx among others). And when you do update, I have a workaround if you run
into this problem.
> Immediately after that, I tried to build binutils CVS from clean HEAD
> sources. When I tested the new tools, the ld 'bootstrap' tests had all
> regressed; I get error messages (in $objdir/ld/ld.log) that read:
>
> tmpdir/ld1:../bfd/.libs/libbfd.a: file format not recognized; treating as
> linker script
> tmpdir/ld1:../bfd/.libs/libbfd.a:1: syntax error
And I've figured out at least the cause of this one; it's a new end result,
but somehow it's related to those static link libraries again. Once I got my
system up and running with a reverted set of packages, I could re-run the
tests and get a single failure. Running the commands at the command-line to
repeat the test, I discovered that:
- with -lc on the command-line, and the old version of libc.a in /usr/lib, we
get the old buggy behaviour of a mangled import table
- with -lc removed from the command line, the test passes
- with -lc on the command-line, and a libc.a generated by the new version of
speclib in /usr/lib, I get the new error message shown above.
So, that's why only some applications manifest this problem; it's only the
ones that explicitly pass -lc in their LDFLAGS. And the same workaround as
before will fix it; remove -lc. Haven't figured out what exactly the problem
is this time, but the only obvious difference between the excutables generated
with and without -lc is that the idata table is 0xcbc bytes in the working (no
-lc) executable but only 0xaf0 bytes in the -lc executable. Which is
immediately suspicious, as it seems to have one more separate import table
than the -no-lc version, and logically must have to import the same set of
dependencies from the DLL; I'd expect it to be slightly larger. Perhaps some
kind of overlap is still happening.
Right, I counted. 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.
The 10 entries are for __getreent, _dll_c...@0, _impure_ptr,
cygwin_internal, pthread_mutex_{lock,unlock} and
pthread_rwlock_{init,rdlock,unlock,wrlock}. There doesn't appear to be any
overlap in the tables. That's as far as I've got with analysing it so far.
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/
