Re: [SOLVED] Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Christopher Faylor wrote: I've rewritten speclib (for the third or fourth time). It should use a more foolproof method to create the .a files. The output from objdump -p still shows separate DLL Name sections whenever one of these special libraries is used but hopefully this is no longer an issue since the import libraries should now be well-formed. 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. Can you confirm if this fixes the problem Dave? Works like a charm! Thanks. 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/
Re: [SOLVED] Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
On Wed, Mar 25, 2009 at 10:29:28AM -0400, Christopher Faylor wrote: On Wed, Mar 25, 2009 at 12:49:36PM +, Dave Korn wrote: So the linker is DTRT, the problem has always existed but been masked by the fact that nothing between -lm and -lcygwin used to import anything, the problem has arisen now because now that does happen, and the solution is to mung the symbols in the import top/tail sections in libm so that libm and libcygwin both each add a complete import table entry of their own (there's no problem having two import tables against the same DLL). Once I've figured out how that perl script works, I'll be able to suggest a patch. Don't bother. I'll look into it. I've rewritten speclib (for the third or fourth time). It should use a more foolproof method to create the .a files. The output from objdump -p still shows separate DLL Name sections whenever one of these special libraries is used but hopefully this is no longer an issue since the import libraries should now be well-formed. Can you confirm if this fixes the problem Dave? cgf -- 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/
[SOLVED] Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
[SOLVED, yes, but no patch just yet, only the full explanation.] Corinna Vinschen wrote: What I'm wondering is, why did it work all these years before? Is it a bug in the new binutils? Or was it a bug in the old binutils to create working results? I installed Cygwin-1.5 from the Time Machine, circa 2006/07/25/023017, and rebuilt zsh from source. Big thanks to Peter A. Castro for the CTM. It all came out valid, despite showing the same behaviour with -lm. Here's the diff between the verbose linker output caused by linking the libzsh DLL without or with '-lm': GNU ld version 2.17.50 20060709 GNU ld version 2.17.50 20060709 Supported emulations: @@ -295,6 +295,11 @@ attempt to open /usr/lib/libcurses.dll.a (/usr/lib/libcurses.dll.a)d000404.o (/usr/lib/libcurses.dll.a)d00.o (/usr/lib/libcurses.dll.a)d000479.o +attempt to open /usr/lib/libm.dll.a failed +attempt to open /usr/lib/m.dll.a failed +attempt to open /usr/lib/libm.a succeeded +(/usr/lib/libm.a)d001177.o +(/usr/lib/libm.a)d00.o attempt to open /usr/lib/libgcc.dll.a failed attempt to open /usr/lib/gcc.dll.a failed attempt to open /usr/lib/libgcc.a failed @@ -420,7 +425,6 @@ attempt to open /usr/lib/libcygwin.a suc (/usr/lib/libcygwin.a)d001399.o (/usr/lib/libcygwin.a)d001401.o (/usr/lib/libcygwin.a)d000959.o -(/usr/lib/libcygwin.a)d001177.o (/usr/lib/libcygwin.a)d001477.o (/usr/lib/libcygwin.a)setgid.o (/usr/lib/libcygwin.a)setuid.o As you see, it's showing the same behaviour as the latest version does: it pulls in partial import table entries from libm, leaving an uncapped IAT. But it works in this case, because looking at the overall linker output: attempt to open /usr/lib/libm.dll.a failed attempt to open /usr/lib/m.dll.a failed attempt to open /usr/lib/libm.a succeeded (/usr/lib/libm.a)d001177.o (/usr/lib/libm.a)d00.o attempt to open /usr/lib/libgcc.dll.a failed attempt to open /usr/lib/gcc.dll.a failed attempt to open /usr/lib/libgcc.a failed attempt to open /usr/lib/gcc.lib failed attempt to open /usr/lib/cyggcc.dll failed attempt to open /usr/lib/libgcc.dll failed attempt to open /usr/lib/gcc.dll failed attempt to open /usr/lib/libgcc.a failed attempt to open /usr/lib/gcc/i686-pc-cygwin/3.4.4/libgcc.dll.a failed attempt to open /usr/lib/gcc/i686-pc-cygwin/3.4.4/gcc.dll.a failed attempt to open /usr/lib/gcc/i686-pc-cygwin/3.4.4/libgcc.a succeeded (/usr/lib/gcc/i686-pc-cygwin/3.4.4/libgcc.a)_chkstk.o (/usr/lib/gcc/i686-pc-cygwin/3.4.4/libgcc.a)_divdi3.o (/usr/lib/gcc/i686-pc-cygwin/3.4.4/libgcc.a)_moddi3.o (/usr/lib/gcc/i686-pc-cygwin/3.4.4/libgcc.a)_udivdi3.o (/usr/lib/gcc/i686-pc-cygwin/3.4.4/libgcc.a)_umoddi3.o attempt to open /usr/lib/libcygwin.dll.a failed attempt to open /usr/lib/cygwin.dll.a failed attempt to open /usr/lib/libcygwin.a succeeded (/usr/lib/libcygwin.a)dll_entry.o ... the next thing that adds any entries into the import sections is libcygwin itself, so the two tables simply merge into one correctly topped-and-tailed one. The entries linked in from static libgcc only add to the text and data sections, and so the import section entries from libm and libcygwin concatenate perfectly. On newer systems with gcc-4 and shared libgcc, that all changes: attempt to open /usr/lib/libm.dll.a failed attempt to open /usr/lib/m.dll.a failed attempt to open /usr/lib/libm.a succeeded (/usr/lib/libm.a)d001286.o (/usr/lib/libm.a)d00.o attempt to open /usr/lib/libgcc_s.dll.a failed attempt to open /usr/lib/gcc_s.dll.a failed attempt to open /usr/lib/libgcc_s.a failed attempt to open /usr/lib/gcc_s.lib failed attempt to open /usr/lib/cyggcc_s.dll failed attempt to open /usr/lib/libgcc_s.dll failed attempt to open /usr/lib/gcc_s.dll failed attempt to open /usr/lib/libgcc_s.a failed attempt to open /usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a succeeded (/usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a)d38.o (/usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a)_chkstk.o (/usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a)d72.o (/usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a)d000100.o (/usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a)d000102.o (/usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a)d00.o (/usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a)d000104.o attempt to open /usr/lib/libcygwin.dll.a failed attempt to open /usr/lib/cygwin.dll.a failed attempt to open /usr/lib/libcygwin.a succeeded (/usr/lib/libcygwin.a)dll_entry.o (/usr/lib/libcygwin.a)d000731.o Now that libgcc is a DLL, it *does* add import section entries (as well as code/data), and so we end up with the libgcc import table in between the libm entries carrying the head of the cygwin1.dll import table and the libcygwin entries containing the tail; it's effectively embedded in the middle of it. This has all the expected bad results. So the linker is DTRT, the problem has always existed but been masked by the fact that nothing between -lm and -lcygwin used to import anything, the problem has arisen now because
Re: [SOLVED] Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
On Wed, Mar 25, 2009 at 12:49:36PM +, Dave Korn wrote: So the linker is DTRT, the problem has always existed but been masked by the fact that nothing between -lm and -lcygwin used to import anything, the problem has arisen now because now that does happen, and the solution is to mung the symbols in the import top/tail sections in libm so that libm and libcygwin both each add a complete import table entry of their own (there's no problem having two import tables against the same DLL). Once I've figured out how that perl script works, I'll be able to suggest a patch. Don't bother. I'll look into it. -- 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/
Re: [SOLVED] Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Christopher Faylor wrote: On Wed, Mar 25, 2009 at 12:49:36PM +, Dave Korn wrote: So the linker is DTRT, the problem has always existed but been masked by the fact that nothing between -lm and -lcygwin used to import anything, the problem has arisen now because now that does happen, and the solution is to mung the symbols in the import top/tail sections in libm so that libm and libcygwin both each add a complete import table entry of their own (there's no problem having two import tables against the same DLL). Once I've figured out how that perl script works, I'll be able to suggest a patch. Don't bother. I'll look into it. Thanks. As an experiment I tried adding (just after the line 0 while s/$libdllname/$libname/sog;) my $orig_iname=_cygwin1_dll_iname; my $new_iname=_libm_dll_iname; my $inamepad = length($orig_iname) - length($new_iname); die $0: library name too long ( . length($new_iname) . )\n if $inamepad 0; $new_iname .= \0 x $inamepad; 0 while s/$orig_iname/$new_iname/sog; ... and although it produced a libm.a with the symbols I was hoping to see, there's something wrong as the reference to _pow in zsh's math.o that was previously pulling in libm.a(d0001286.o) fails to pull in anything from a libm built with the above. Didn't get as far as figuring out what I did wrong yet, but if you're looking after it I'll get on with GCC stuff. 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Peter A. Castro wrote: True, the name does not fit the current naming convention for cygwin DLLs, but it doesn't really matter too much, since this particular DLL is private to zsh (it's really the core of zsh, which zsh.exe loads implicitly). Since its an internal (to zsh) DLL and not useable by any other program I felt it was exempt from the naming rules. Is there a strong technical reason to rename it? If so, I will do so. I think the issue is, since zsh is built using libtool (right?) libtool ought to DTRT. Since it is not, it seems something is going wrong in the build process; libtool doesn't know that it's supposed to be building cygwin libraries. So, what *else* is libtool doing wrong, as it happily runs through its (linux? sun? sgi?)-specific code... BTW, good catch on the import libs being bad. It's nice to know it's *not my fault, man!* :-) Heh. -- Chuck -- 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Charles Wilson wrote: I think the issue is, since zsh is built using libtool (right?) Nope! 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
On Mon, 16 Mar 2009, A.R. Burgers wrote:
Any special reason for specifying -lm and -lc when building d3.dll?
Umm...because math functions historically come from libm and the normal
C runtime historically comes from libc. And, anyways, this has always
worked, up 'til now, and there was no notice that these libs should not
be used anymore?
Without them, pow is mentioned only once in the objdump output. However on
1.5 pow is mentioned only once, even if -lm and -lc
are specified.
Yes, which means something is likely wrong with the import libs, but what
I'm not sure.
And, from followup email from DaveK it seems he's discovered the import
libs are incorrect in some strange fashion.
The exact same problem as with zsh, I also run into with fltk's fluid.exe
(from current 1.3 svn) on cygwin 1.7 and gcc 3.4.4.
fltk btw does not link to curses libraries.
Hmm...well, misery loves company :-)
Teun
Peter A. Castro schreef:
On Sun, 15 Mar 2009, Dave Korn wrote:
Hi Dave!
Peter A. Castro wrote:
Using the Dependency Walker tool that Chuck pointed out (thanks
Chuck!)
No problem, Basil!
Basil! I love it! (you know I was just kidding! :-)
Could this really be a linker problem?
If it's not a linker problem, it has to be a faulty import library. I
can't
think of any other option that would explain how that import table got
munged
like that. I'll see if I can reproduce it.
I've been extracting modules from the import libs and dumping
import/export symbols from the two libncurses DLLs, but I can't seem to
find anything that looks wrong.
However... this I find strange:
file d3.c:
#include math.h
double my_pow( double d1, double d2 )
{
double d;
d = pow(d1,d2);
return d;
}
$ gcc -g -shared -o d3.dll d3.c -lm -lc
$ objdump -x d3.dll
...
There is an import table in .idata at 0x10004000
The Import Tables (interpreted .idata section contents)
vma:HintTime Forward DLL First
Table Stamp ChainName Thunk
4000 4050 416c 4084
DLL Name: cygwin1.dll
vma: Hint/Ord Member-Name Bound-To
40b8 351 _impure_ptr
40c8 720 calloc
40d4 779 cygwin_detach_dll
40e8 781 cygwin_internal
40fc 802 dll_dllcrt0
410c 917 free
4114 1186 malloc
4120 1395 realloc
412c 1285 pow
4014 4070 416c 40a4
DLL Name: cygwin1.dll
vma: Hint/Ord Member-Name Bound-To
412c 1285 pow
4028 407c 417c 40b0
DLL Name: KERNEL32.dll
vma: Hint/Ord Member-Name Bound-To
4134 337 GetModuleHandleA
403c
...
Why is 'pow' being pulled in twice? Maybe it's really the math lib stuff
that's tickling the linker? This is kinda looking more like some linker
bug. Again, I'm not sure where to go next. It's been a while since I
dug into gcc...
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/
--
Peter A. Castro doc...@fruitbat.org or peter.cas...@oracle.com
Cats are just autistic Dogs -- Dr. Tony Attwood
--
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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
On Mar 18 07:13, Dave Korn wrote: Ah, gottit. The bug happens because the libraries are not quite correctly constructed. When you add -lm to the link line, you see this in the map file, in the imports section: /usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a(d000104.o) /usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a(d00.o) (cyggcc_s_1_dll_iname) /usr/lib/libm.a(d001286.o)math.o (pow) /usr/lib/libm.a(d00.o)/usr/lib/libm.a(d001286.o) (_head_libm) /usr/lib/libcygwin.a(dll_entry.o) (_cygwin_dll_en...@12) There's no import name chunk for libm (_libm_dll_iname), instead the head chunk of the import table in libm.a refers to _cygwin1_dll_iname: dkad...@ubik /usr/src/zsh2/zsh-4.3.9/.build/Src/libm $ nm ./d00.o i .idata$2 i .idata$4 i .idata$5 I __head_libm U _cygwin1_dll_iname which means at link time it is resolved by the definition of that symbol supplied by libcygwin.a and so the tail chunk from libm is not pulled in to correctly 'cap off' the end of the import table. Then all the name entries and IAT table pointers get out of sync and we get confused and overlapping import name tables. Constructing import tables is tricky, and we can't optimise away or share any of the .idata$x blocks. There are a number of ways to solve this, either by changing the undefined symbol in the head and tail archive members, or maybe by using dlltool or ld to generate a fresh import library rather than munging an existing one, but I'm going AFK now to get a few hours sleep. What I'm wondering is, why did it work all these years before? Is it a bug in the new binutils? Or was it a bug in the old binutils to create working results? 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Christopher Faylor wrote: Your reading of the Makefile is not right. Well hey! Maybe there's a simple explanation that doesn't assume malice on my part after all. You're being hypersensitive and I never kicked your puppy anyway. 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Christopher Faylor wrote: Your reading of the Makefile is not right. libc.a and libm.a from newlib do get used in creating cygwin1.dll (obviously?). There are different libc.a, libm.a, libpthread.a, libutil.a, libdl.a, and libresolv.a libraries which are all produced intentionally and have nothing to do with the creation of the dll itself. The initial discussion of the reason for these libraries started here: http://cygwin.com/ml/cygwin/2001-12/msg00705.html Ah, gottit. The bug happens because the libraries are not quite correctly constructed. When you add -lm to the link line, you see this in the map file, in the imports section: /usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a(d000104.o) /usr/lib/gcc/i686-pc-cygwin/4.3.2/libgcc_s.dll.a(d00.o) (cyggcc_s_1_dll_iname) /usr/lib/libm.a(d001286.o)math.o (pow) /usr/lib/libm.a(d00.o)/usr/lib/libm.a(d001286.o) (_head_libm) /usr/lib/libcygwin.a(dll_entry.o) (_cygwin_dll_en...@12) There's no import name chunk for libm (_libm_dll_iname), instead the head chunk of the import table in libm.a refers to _cygwin1_dll_iname: dkad...@ubik /usr/src/zsh2/zsh-4.3.9/.build/Src/libm $ nm ./d00.o i .idata$2 i .idata$4 i .idata$5 I __head_libm U _cygwin1_dll_iname which means at link time it is resolved by the definition of that symbol supplied by libcygwin.a and so the tail chunk from libm is not pulled in to correctly 'cap off' the end of the import table. Then all the name entries and IAT table pointers get out of sync and we get confused and overlapping import name tables. Constructing import tables is tricky, and we can't optimise away or share any of the .idata$x blocks. There are a number of ways to solve this, either by changing the undefined symbol in the head and tail archive members, or maybe by using dlltool or ld to generate a fresh import library rather than munging an existing one, but I'm going AFK now to get a few hours sleep. 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Dave Korn wrote: Anyway, I found that removing -lm -lc from the options fixes the build problem, and that it makes no difference what version of ld you use. Have looked at this a little further. First off: the Cygwin C runtime library is basically the Cygwin DLL, and what we want in normal use is to link against the Cygwin DLL's import library, (which is /usr/lib/libcygwin.a). The libraries /usr/lib/libm.a and /usr/lib/libc.a are helper libraries, used to bundle up objects as part of the winsup build. They are passed to the final link that builds the Cygwin DLL. They appear to be some kind of import library that has been processed by a perl script called speclib that does some kind of low-level binary munging on them to change symbol names: -libcygwin/d78.o: file format pe-i386 +libc/d78.o: file format pe-i386 -[ 7](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x __head_cygwin1_dll +[ 7](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x __head_libc I don't know what it's all about yet, but as far as I can tell, they aren't suitable for use outside the actual build system itself and should probably not need to be installed. It would probably be better if they were replaced by symlinks to libcygwin.a, as is done for libg.a. 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
On Tue, Mar 17, 2009 at 08:43:47PM +, Dave Korn wrote: Dave Korn wrote: Anyway, I found that removing -lm -lc from the options fixes the build problem, and that it makes no difference what version of ld you use. Have looked at this a little further. First off: the Cygwin C runtime library is basically the Cygwin DLL, and what we want in normal use is to link against the Cygwin DLL's import library, (which is /usr/lib/libcygwin.a). The libraries /usr/lib/libm.a and /usr/lib/libc.a are helper libraries, used to bundle up objects as part of the winsup build. They are passed to the final link that builds the Cygwin DLL. They appear to be some kind of import library that has been processed by a perl script called speclib that does some kind of low-level binary munging on them to change symbol names: -libcygwin/d78.o: file format pe-i386 +libc/d78.o: file format pe-i386 -[ 7](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x __head_cygwin1_dll +[ 7](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x __head_libc I don't know what it's all about yet, but as far as I can tell, they aren't suitable for use outside the actual build system itself and should probably not need to be installed. It would probably be better if they were replaced by symlinks to libcygwin.a, as is done for libg.a. Sheesh. Do you honestly think I would have gone to the effort of creating these libraries when a simple symlink would suffice? Do you really think I don't know about symlinks? cgf -- 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Christopher Faylor wrote: I don't know what it's all about yet, but as far as I can tell, they aren't suitable for use outside the actual build system itself and should probably not need to be installed. It would probably be better if they were replaced by symlinks to libcygwin.a, as is done for libg.a. Sheesh. Do you honestly think I would have gone to the effort of creating these libraries when a simple symlink would suffice? Do you really think I don't know about symlinks? Uh, why do you think I have any idea who wrote what code or how much historical cruft there might or might not be in the makefile? When I'm looking at stuff with a lot of legacy behind it I try not to make assumptions about what is deliberate and what accidental except in the most blindingly obvious cases. I assume it's deliberate that the Makefile builds libc and libm and uses them in linking the DLL. I don't assume it's necessarily deliberate that they get installed. I have seen examples in the past of auto* based makefiles that installed more than they should have done solely by accident of history and evolution. So what are libc.a and libm.a for? 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
On Wed, Mar 18, 2009 at 04:24:33AM +, Dave Korn wrote: Christopher Faylor wrote: I don't know what it's all about yet, but as far as I can tell, they aren't suitable for use outside the actual build system itself and should probably not need to be installed. It would probably be better if they were replaced by symlinks to libcygwin.a, as is done for libg.a. Sheesh. Do you honestly think I would have gone to the effort of creating these libraries when a simple symlink would suffice? Do you really think I don't know about symlinks? Uh, why do you think I have any idea who wrote what code or how much historical cruft there might or might not be in the makefile? I did think that you understood how to use CVS to research things like this, but, ok, so there was some historical ignoramus who worked on the cygwin project and didn't understand how symlinks worked. When I'm looking at stuff with a lot of legacy behind it I try not to make assumptions about what is deliberate and what accidental except in the most blindingly obvious cases. You made assumptions with your it sould probably be better suggestion. The point is that it isn't usually profitable to automatically assume that a problem would be trivially solved by an obvious solution. I assume it's deliberate that the Makefile builds libc and libm and uses them in linking the DLL. I don't assume it's necessarily deliberate that they get installed. I have seen examples in the past of auto* based makefiles that installed more than they should have done solely by accident of history and evolution. Your reading of the Makefile is not right. libc.a and libm.a from newlib do get used in creating cygwin1.dll (obviously?). There are different libc.a, libm.a, libpthread.a, libutil.a, libdl.a, and libresolv.a libraries which are all produced intentionally and have nothing to do with the creation of the dll itself. The initial discussion of the reason for these libraries started here: http://cygwin.com/ml/cygwin/2001-12/msg00705.html cgf -- 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Any special reason for specifying -lm and -lc when building d3.dll?
Without them, pow is mentioned only once in the objdump output. However
on 1.5 pow is mentioned only once, even if -lm and -lc
are specified.
The exact same problem as with zsh, I also run into with fltk's
fluid.exe (from current 1.3 svn) on cygwin 1.7 and gcc 3.4.4.
fltk btw does not link to curses libraries.
Teun
Peter A. Castro schreef:
On Sun, 15 Mar 2009, Dave Korn wrote:
Hi Dave!
Peter A. Castro wrote:
Using the Dependency Walker tool that Chuck pointed out (thanks
Chuck!)
No problem, Basil!
Basil! I love it! (you know I was just kidding! :-)
Could this really be a linker problem?
If it's not a linker problem, it has to be a faulty import library.
I can't
think of any other option that would explain how that import table got
munged
like that. I'll see if I can reproduce it.
I've been extracting modules from the import libs and dumping
import/export symbols from the two libncurses DLLs, but I can't seem to
find anything that looks wrong.
However... this I find strange:
file d3.c:
#include math.h
double my_pow( double d1, double d2 )
{
double d;
d = pow(d1,d2);
return d;
}
$ gcc -g -shared -o d3.dll d3.c -lm -lc
$ objdump -x d3.dll
...
There is an import table in .idata at 0x10004000
The Import Tables (interpreted .idata section contents)
vma:HintTime Forward DLL First
Table Stamp ChainName Thunk
4000 4050 416c 4084
DLL Name: cygwin1.dll
vma: Hint/Ord Member-Name Bound-To
40b8 351 _impure_ptr
40c8 720 calloc
40d4 779 cygwin_detach_dll
40e8 781 cygwin_internal
40fc 802 dll_dllcrt0
410c 917 free
4114 1186 malloc
4120 1395 realloc
412c 1285 pow
4014 4070 416c 40a4
DLL Name: cygwin1.dll
vma: Hint/Ord Member-Name Bound-To
412c 1285 pow
4028 407c 417c 40b0
DLL Name: KERNEL32.dll
vma: Hint/Ord Member-Name Bound-To
4134 337 GetModuleHandleA
403c
...
Why is 'pow' being pulled in twice? Maybe it's really the math lib stuff
that's tickling the linker? This is kinda looking more like some linker
bug. Again, I'm not sure where to go next. It's been a while since I
dug into gcc...
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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
A.R. Burgers schreef: The exact same problem as with zsh, I also run into with fltk's fluid.exe (from current 1.3 svn) on cygwin 1.7 and gcc 3.4.4. fltk btw does not link to curses libraries. fltk's fluid depends on libpng and libjpeg. If I move back to from jpeg 6b-20 to 6b-12 and from png 1.2.35-10 to 1.2.12-1, the built fluid.exe will launch successfully. Teun -- 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
A.R. Burgers wrote: Any special reason for specifying -lm and -lc when building d3.dll? Without them, pow is mentioned only once in the objdump output. However on 1.5 pow is mentioned only once, even if -lm and -lc are specified. The exact same problem as with zsh, I also run into with fltk's fluid.exe (from current 1.3 svn) on cygwin 1.7 and gcc 3.4.4. fltk btw does not link to curses libraries. Hmm. All of these packages are mine (libpng, jpeg, ncurses), and all have been rebuilt recently after a long fallow period. However, I didn't do anything really tricky when building these libraries, so they oughta Just Work. They were more-or-less just ./configure; make; make install in each case, with a few local patches that were constant between old (working) and new (not working?). What they all have in common is, that the older (working) versions were built using gcc-3.4.4-3 and binutils-20060817-1. The new (not working) versions were built using gcc-3.4.4-999 and binutils-20080624-2. Now, binutils-20080624-2 has been in use for over six months. I *suppose* it's possible that it has a bug that is only now being tickled. But (a) the internal apps in each package, which use the DLLs and import libs and were built using the new binutils, all work, and (b) folks have been using the new linker for quite some time now without these sorts of reports. gcc is different, but it's pretty much out of the loop by the time the things that could cause the reported symptoms could occur; it's all ld at that point. Looking at the DLLs and import libs, I don't see anything odd. I'd really like to figure out if the problem is on the library creation end (either in gcc, ld, or something stupid I may have done/am still doing wile creating them) -- which means I have to rebuild all of my newly updated packages. AGAIN. Or if the problem is on the client end: either something silly is happening in both Vin Shelton's AND Teun Burger's build process, or their ld is having trouble. Both seem unlikely. I'm going to try the following: (1) make sure I can reproduce the OP's troubles with zsh and new ncurses. (2) downgrade binutils to 20060817 and see if that fixes it. Not really sure what that shows, since library linked with old ld, linked into app using new ld -- works library linked with new ld, linked into app using new ld -- broken ? library linked with old ld, linked into app using old ld -- ?? ? library linked with new ld, linked into app using old ld -- ?? If both of the last two work, then we have a case where for some reason new ld can't eat its own dog food -- but it's been happily doing so for six months until just now (with other maintainer's released libs). Well, it'll be another data point... -- Chuck -- 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Peter A. Castro wrote:
file d3.c:
#include math.h
double my_pow( double d1, double d2 )
{
double d;
d = pow(d1,d2);
return d;
}
$ gcc -g -shared -o d3.dll d3.c -lm -lc
$ objdump -x d3.dll
DLL Name: cygwin1.dll
vma: Hint/Ord Member-Name Bound-To
412c 1285 pow
4014 4070 416c 40a4
DLL Name: cygwin1.dll
vma: Hint/Ord Member-Name Bound-To
412c 1285 pow
Why is 'pow' being pulled in twice?
Dunno. I can't reproduce it. There must be some environment difference
between your system and mine. You didn't specify whether you were using gcc3
or gcc4 for that example, so I tried them both, and neither reproduced:
$ cat d3.c
#include math.h
double my_pow( double d1, double d2 )
{
double d;
d = pow(d1,d2);
return d;
}
$ gcc-3 -g -shared -o d3.dll d3.c -lm -lc
$ objdump -x d3.dll with-3.txt
$ gcc-4 -g -shared -o d3.dll d3.c -lm -lc
$ objdump -x d3.dll with-4.txt
$ diff -pu with-3.txt with-4.txt
--- with-3.txt 2009-03-17 02:34:40.46875 +
+++ with-4.txt 2009-03-17 02:34:56.515625000 +
@@ -3,7 +3,7 @@ d3.dll: file format pei-i386
d3.dll
architecture: i386, flags 0x013b:
HAS_RELOC, EXEC_P, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, D_PAGED
-start address 0x10001050
+start address 0x69b41120
Note this change, it could be relevant. GCC-4 passes the
'--enable-auto-image-base' option to the linker, which is supposed to help us
avoid fork errors in future. Here are the import tables:
@@ -61,52 +61,53 @@ Entry d Delay Import D
Entry e CLR Runtime Header
Entry f Reserved
-There is an import table in .idata at 0x10004000
+There is an import table in .idata at 0x69b46000
The Import Tables (interpreted .idata section contents)
vma:HintTime Forward DLL First
Table Stamp ChainName Thunk
- 4000 4040 4160 4078
+ 6000 6040 617c 607c
DLL Name: cygwin1.dll
vma: Hint/Ord Member-Name Bound-To
- 40ac 351 _impure_ptr
- 40bc 720 calloc
- 40c8 779 cygwin_detach_dll
- 40dc 781 cygwin_internal
- 40f0 802 dll_dllcrt0
- 4100 917 free
- 4108 1183 malloc
- 4114 1282 pow
- 411c 1392 realloc
+ 60b4 351 _impure_ptr
+ 60c4 720 calloc
+ 60d0 779 cygwin_detach_dll
+ 60e4 781 cygwin_internal
+ 60f8 802 dll_dllcrt0
+ 6108 917 free
+ 6110 1183 malloc
+ 611c 1282 pow
+ 6124 1392 realloc
- 4014 406c 4170 40a4
+ 6014 606c 6190 60a8
DLL Name: KERNEL32.dll
vma: Hint/Ord Member-Name Bound-To
- 4128 337 GetModuleHandleA
+ 6130 337 GetModuleHandleA
+ 6144 364 GetProcAddress
- 4028
+ 6028
As you see, they have sane-looking differences in the VMAs, and neither of
them imports cygwin1.dll twice.
Again, I'm not sure where to go next.
Might be worth trying a fresh build of binutils from CVS. I've just
completed a build of zsh and it exhibits the problem, so I'll see if I can
figure out what's gone wrong.
BTW to avoid confusion can everyone in this thread please remember to take
care and specify explicit version number suffixes on any examples they show
using gcc!
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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Peter A. Castro wrote: The offending symbol entries are the following (functions) tgetent tgetflag tgetnum tgetstr tgoto tputs pow (but this is not an unresolve symbol, see below) 'pow' is not an unresolve symbol in this mess, but it is lumped into the chunk with the bad symbols. libzsh-4.3.9.dll is ... peculiarly named with no 'cyg' prefix. I suspect something may have gone bad in the libtoolification or whatever other procedure zsh uses to build this dll. the one who needs these symbols, but the import list is wrong: And, here's the imports from compiling/linking with libncurses-9 (bad): 0009e03c 0009e398 0009f374 0009e6d0 DLL Name: cygwin1.dll vma: Hint/Ord Member-Name Bound-To 9f0101285 pow 9f018 468 tgetent 9f024 469 tgetflag 9f030 470 tgetnum 9f03c 471 tgetstr 9f048 472 tgoto 9f050 480 tputs 0009e050 0009e39c 0009f39c 0009e6d4 DLL Name: cygncurses-9.dll vma: Hint/Ord Member-Name Bound-To 9f018 468 tgetent 9f024 469 tgetflag 9f030 470 tgetnum 9f03c 471 tgetstr 9f048 472 tgoto 9f050 480 tputs It appears to trying to import the symbols twice. While it is not unusual to see multiple imports for the same symbols (auto-import works by generating loads of mini-pseudo-IATs scattered through the .text section at addresses coinciding with instruction operand fields that need relocating), it's very wrong to see them listed under the wrong DLL name. BTW, I've now tried this with both old and latest CVS binutils, and it makes no difference. I've checked the import libs for both 5.5-3 (good) 5.7-13 (bad) and they don't appear to have anything funny about them. libncurses.a and libncurses.dll.a both appear to have the correct exports. There's no difference in how zsh is compiled between ncurses 8 9. Could this really be a linker problem? I don't know why exactly it's the problem yet, but I know a solution: Here's the command from my build log that links libzsh dll: i686-pc-cygwin-gcc -s -shared -Wl,--export-all-symbols -o libzsh-4.3.9.dll `cat stamp-modobjs` -lgdbm -L/usr/lib -lpcre -liconv -ldl -lncurses -lm -lc I re-ran it with -v and got the following actual commandline passed to the linker: /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld --shared -Bdynamic -e __cygwin_dll_en...@12 --enable-auto-image-base --dll-search-prefix=cyg -o libzsh-4.3.9.dll -s /usr/lib/gcc/i686-pc-cygwin/4.3.2/crtbegin.o -L/usr/lib -L/usr/lib/gcc/i686-pc-cygwin/4.3.2 -L/usr/lib/gcc/i686-pc-cygwin/4.3.2 -L/usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/lib -L/usr/lib/gcc/i686-pc-cygwin/4.3.2/../../.. --export-all-symbols builtin.o compat.o cond.o exec.o glob.o hashtable.o hist.o init.o input.o jobs.o lex.o linklist.o loop.o math.o mem.o module.o options.o params.o parse.o pattern.o prompt.o signals.o signames.o sort.o string.o subst.o text.o utils.o watch.o -lgdbm -lpcre -liconv -ldl -lncurses -lm -lc -v -lgcc_s -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc_s /usr/lib/gcc/i686-pc-cygwin/4.3.2/crtend.o Anyway, I found that removing -lm -lc from the options fixes the build problem, and that it makes no difference what version of ld you use. Remove those two -l options and you get a good DLL, leave them in and you get a bad one. I don't know yet what effect these options have that does the damage, but will look later. I then ran make install which went smoothly, and invoked zsh: This is the Z Shell configuration function for new users, zsh-newuser-install. You are seeing this message because you have no zsh startup files (the files .zshenv, .zprofile, .zshrc, .zlogin in the directory ~). This function can help you with a few settings that should make your use of the shell easier. You can: (q) Quit and do nothing. The function will be run again next time. (0) Exit, creating the file ~/.zshrc containing just a comment. That will prevent this function being run again. (1) Continue to the main menu. --- Type one of the keys in parentheses --- So I conclude it's more or less working. I do however get this warning: $ zsh zsh: failed to load module `zsh/zle': No such process $P$G Also I tried a test suite run. It got some way before one of the testcases appeared to hang and I killed it: cd Test ; make check make[1]: Entering directory `/usr/src/zsh2/zsh-4.3.9/.build/Test' if test -n i686-pc-cygwin-gcc; then \ cd .. DESTDIR= \ make MODDIR=`pwd`/Test/Modules install.modules /dev/null; \ fi /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Dave Korn wrote:
I'm now going to try building it again, from scratch, but with the LDFLAGS
edited to a) remove -lm -lc and b) add -Wl,--enable-auto-import. Let's
see if that improves things any.
Right, works nicely. Also I discovered about make install.modules in the
meantime, which helps, and now it just works:
$ zsh --login
(ad...@ubik)[1] ~
$ echo Hello world from ZSH
Hello world from ZSH
(ad...@ubik)[2] ~
$ exit
$ echo $?
0
So, what I did was not suitable for upstream, but I'll leave you to work
that one out with them. I ...
a) Deleted these lines from configure.ac and regnerated configure:
$ diff -pu zsh/zsh-4.3.9/configure.ac zsh3/zsh-4.3.9/configure.ac
--- zsh/zsh-4.3.9/configure.ac 2008-10-30 13:04:44.0 +
+++ zsh3/zsh-4.3.9/configure.ac 2009-03-17 03:39:19.21875 +
@@ -642,9 +642,10 @@ dnl in case they require objects that ex
dnl and might not be compiled into the zsh executable.
dnl On ReliantUNIX -lc better be the last library, else funny things
dnl may happen.
-AC_CHECK_LIB(c, printf, [LIBS=$LIBS -lc])
-
-AC_CHECK_LIB(m, pow)
+dnl On cygwin this is a no-no
+dnl AC_CHECK_LIB(c, printf, [LIBS=$LIBS -lc])
+dnl
+dnl AC_CHECK_LIB(m, pow)
dnl Various features of ncurses depend on having the right header
dnl (the system's own curses.h may well not be good enough).
$
b) Modified the build script to enable auto import.
$ diff -pu zsh/zsh-4.3.9-1.sh zsh3/zsh-4.3.9-1.sh
--- zsh/zsh-4.3.9-1.sh 2009-03-17 02:22:13.87500 +
+++ zsh3/zsh-4.3.9-1.sh 2009-03-17 03:45:06.828125000 +
@@ -105,6 +105,7 @@ conf() {
--enable-multibyte \
--with-curses-terminfo \
--with-install-prefix=${instdir} \
+ --enable-ldflags=-Wl,--enable-auto-import \
${ZSHCONFDEBUG} )
}
build() {
$
Everything built and runs ok, and the testsuite reports:
/usr/src/zsh3/zsh-4.3.9/Test/C02cond.ztst: starting.
Warning: Not testing [[ -b blockdevice ]] (no devices found)
Warning: Not testing [[ -f blockdevice ]] (no devices found)
Warning: Not testing [[ -p pipe ]] (FIFOs not supported)
Test /usr/src/zsh/zsh-4.3.9/Test/C02cond.ztst failed: bad status 1, expected 0
from:
if (( EUID == 0 )); then
print -u$ZTST_fd 'Warning: Not testing [[ ! -r file ]] (root reads anything)
'
[[ -r zerolength -r unmodish ]]
else
[[ -r zerolength ! -r unmodish ]]
fi
Was testing: -r cond
/usr/src/zsh3/zsh-4.3.9/Test/C02cond.ztst: test failed.
/usr/src/zsh3/zsh-4.3.9/Test/V01zmodload.ztst: starting.
*** /tmp/zsh.ztst.err.1400 Tue Mar 17 04:01:22 2009
--- /tmp/zsh.ztst.terr.1400 Tue Mar 17 04:01:23 2009
***
*** 0
--- 1,2
+ (eval):3: failed to load module `zsh/net/tcp': No such process
+ (eval):3: failed to load module `zsh/net/tcp': No such process
Test /usr/src/zsh3/zsh-4.3.9/Test/V01zmodload.ztst failed: error output differs
from expected as shown above for:
for m in $mods
do
zmodload -i $m || mods[(r)$m]=()
done
Was testing: Test loading of all compiled modules
/usr/src/zsh3/zsh-4.3.9/Test/V01zmodload.ztst: test failed.
**
34 successful test scripts, 2 failures, 1 skipped
**
--
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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Peter A. Castro wrote: Using the Dependency Walker tool that Chuck pointed out (thanks Chuck!) No problem, Basil! Could this really be a linker problem? If it's not a linker problem, it has to be a faulty import library. I can't think of any other option that would explain how that import table got munged like that. I'll see if I can reproduce it. 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
On Sun, 15 Mar 2009, Dave Korn wrote:
Hi Dave!
Peter A. Castro wrote:
Using the Dependency Walker tool that Chuck pointed out (thanks
Chuck!)
No problem, Basil!
Basil! I love it! (you know I was just kidding! :-)
Could this really be a linker problem?
If it's not a linker problem, it has to be a faulty import library. I can't
think of any other option that would explain how that import table got munged
like that. I'll see if I can reproduce it.
I've been extracting modules from the import libs and dumping
import/export symbols from the two libncurses DLLs, but I can't seem to
find anything that looks wrong.
However... this I find strange:
file d3.c:
#include math.h
double my_pow( double d1, double d2 )
{
double d;
d = pow(d1,d2);
return d;
}
$ gcc -g -shared -o d3.dll d3.c -lm -lc
$ objdump -x d3.dll
...
There is an import table in .idata at 0x10004000
The Import Tables (interpreted .idata section contents)
vma:HintTime Forward DLL First
Table Stamp ChainName Thunk
4000 4050 416c 4084
DLL Name: cygwin1.dll
vma: Hint/Ord Member-Name Bound-To
40b8 351 _impure_ptr
40c8 720 calloc
40d4 779 cygwin_detach_dll
40e8 781 cygwin_internal
40fc 802 dll_dllcrt0
410c 917 free
4114 1186 malloc
4120 1395 realloc
412c 1285 pow
4014 4070 416c 40a4
DLL Name: cygwin1.dll
vma: Hint/Ord Member-Name Bound-To
412c 1285 pow
4028 407c 417c 40b0
DLL Name: KERNEL32.dll
vma: Hint/Ord Member-Name Bound-To
4134 337 GetModuleHandleA
403c
...
Why is 'pow' being pulled in twice? Maybe it's really the math lib stuff
that's tickling the linker? This is kinda looking more like some linker
bug. Again, I'm not sure where to go next. It's been a while since I
dug into gcc...
cheers,
DaveK
--
Peter A. Castro doc...@fruitbat.org or peter.cas...@oracle.com
Cats are just autistic Dogs -- Dr. Tony Attwood
--
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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
René Berber wrote: Vin Shelton wrote: Charles Wilson wrote: Just for grins, could you rebuild zsh against libncurses9 -- but this time use gcc3? cygiconv-2 and cygncurses-9 use the static gcc-3.4.4 libgcc.a, but you are apparently using the gcc-4.3.2 shared libgcc. I just wonder if that presents an incompatibility that could explain what you are seeing. Thanks for replying, Chuck. As I mentioned in the initial email, I had already done just that. Just to be sure, I did it again, with the same result: No you didn't, the point was: use gcc3, in other words: mixing libraries built with gcc3 and gcc4 doesn't work. I think my initial post contains this line: The referenced builds used gcc-4, but the same problem occurred using gcc-3. If I'm wrong, or I'm misunderstanding you, I apologize. In any case, I have now supplied the information requested, no? Building with gcc-4 and the old ncurses produces a working zsh, in case that wasn't clear from my earlier emails. - Vin -- 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
On Sat, 14 Mar 2009, Dave Korn wrote: Vin Shelton wrote: How can I ascertain what entry point is not being found? You need depends.exe. http://www.dependencywalker.com/ Thanks, Dave! That's a kool tool! cheers, DaveK -- Peter A. Castro doc...@fruitbat.org or peter.cas...@oracle.com Cats are just autistic Dogs -- Dr. Tony Attwood -- 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
On Sat, 14 Mar 2009, Vin Shelton wrote: Greetings, All, As the zsh maintainer I guess I get to try and figure out what's going on. :-) Using the Dependency Walker tool that Chuck pointed out (thanks Chuck!), I've found some rather interesting things. The offending symbol entries are the following (functions) tgetent tgetflag tgetnum tgetstr tgoto tputs pow (but this is not an unresolve symbol, see below) 'pow' is not an unresolve symbol in this mess, but it is lumped into the chunk with the bad symbols. libzsh-4.3.9.dll is the one who needs these symbols, but the import list is wrong: Here's the imports from compiling/linking with libncurses-8 (good): 0009e03c 0009e398 0009f37c 0009e6d4 DLL Name: cygwin1.dll vma: Hint/Ord Member-Name Bound-To 9f0181285 pow 0009e050 0009e3a0 0009f3a4 0009e6dc DLL Name: cygncurses-8.dll vma: Hint/Ord Member-Name Bound-To 9f020 405 tgetent 9f02c 406 tgetflag 9f038 407 tgetnum 9f044 408 tgetstr 9f050 409 tgoto 9f058 417 tputs And, here's the imports from compiling/linking with libncurses-9 (bad): 0009e03c 0009e398 0009f374 0009e6d0 DLL Name: cygwin1.dll vma: Hint/Ord Member-Name Bound-To 9f0101285 pow 9f018 468 tgetent 9f024 469 tgetflag 9f030 470 tgetnum 9f03c 471 tgetstr 9f048 472 tgoto 9f050 480 tputs 0009e050 0009e39c 0009f39c 0009e6d4 DLL Name: cygncurses-9.dll vma: Hint/Ord Member-Name Bound-To 9f018 468 tgetent 9f024 469 tgetflag 9f030 470 tgetnum 9f03c 471 tgetstr 9f048 472 tgoto 9f050 480 tputs It appears to trying to import the symbols twice. I've checked the import libs for both 5.5-3 (good) 5.7-13 (bad) and they don't appear to have anything funny about them. libncurses.a and libncurses.dll.a both appear to have the correct exports. There's no difference in how zsh is compiled between ncurses 8 9. Could this really be a linker problem? My build was done using gcc3, and Vin stated he'd tested with both gcc3 and gcc4, so perhaps there's a common element between them? Or, perhaps, is something not quite right with libncurses9 ? I'm a but stuck now as I'm not sure where to look next. Any educated guesses to point me in the right direction? Anyone? Anyone? Bueller? René Berber wrote: Vin Shelton wrote: Charles Wilson wrote: Just for grins, could you rebuild zsh against libncurses9 -- but this time use gcc3? cygiconv-2 and cygncurses-9 use the static gcc-3.4.4 libgcc.a, but you are apparently using the gcc-4.3.2 shared libgcc. I just wonder if that presents an incompatibility that could explain what you are seeing. Thanks for replying, Chuck. As I mentioned in the initial email, I had already done just that. Just to be sure, I did it again, with the same result: No you didn't, the point was: use gcc3, in other words: mixing libraries built with gcc3 and gcc4 doesn't work. I think my initial post contains this line: The referenced builds used gcc-4, but the same problem occurred using gcc-3. If I'm wrong, or I'm misunderstanding you, I apologize. In any case, I have now supplied the information requested, no? Building with gcc-4 and the old ncurses produces a working zsh, in case that wasn't clear from my earlier emails. - Vin -- 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/ -- Peter A. Castro doc...@fruitbat.org or peter.cas...@oracle.com Cats are just autistic Dogs -- Dr. Tony Attwood -- 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/
under cygwin, zsh cannot run when built against ncurses9-5.7-13
Greetings - When I build the latest zsh sources on Cygwin 1.7 using ncurses8-5.5.3, I get a working zsh. When I build the same zsh sources against ncurses9-5.7-13, although the build completes successfully, the executable will not run: $ /usr/local/zsh-2009-03-11/bin/zsh -f $ echo $? 127 My guess is that some kind of runtime dependency is missing, but: $ cygcheck /usr/local/zsh-2009-03-11/bin/zsh.exe C:\cygwin\usr\local\zsh-2009-03-11\bin\zsh.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\usr\local\zsh-2009-03-11\bin\libzsh-4.3.9-dev-1.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygncurses-9.dll C:\cygwin\bin\cyggcc_s-1.dll $ cygcheck /usr/local/zsh-2009-03-11/bin/libzsh-4.3.9-dev-1.dll C:\cygwin\usr\local\zsh-2009-03-11\bin\libzsh-4.3.9-dev-1.dll C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygncurses-9.dll C:\cygwin\bin\cyggcc_s-1.dll so I don't see an obviously missing DLL. By the way, ldd returns a different set of runtime dependencies: $ ldd /usr/local/zsh-2009-03-11/bin/zsh.exe /c/WINDOWS/system32/ntdll.dll (0x7c90) /c/WINDOWS/system32/kernel32.dll (0x7c80) /usr/bin/cygwin1.dll (0x6100) /c/WINDOWS/system32/ADVAPI32.DLL (0x77dd) /c/WINDOWS/system32/RPCRT4.dll (0x77e7) /c/WINDOWS/system32/Secur32.dll (0x77fe) /usr/local/zsh-2009-03-11/bin/libzsh-4.3.9-dev-1.dll (0x6ba0) /usr/bin/cygiconv-2.dll (0x6dd5) notably missing ncurses. When configuring against ncurses8 and ncurses9, there are no differences between the generated config.h or config.status files. There are only minor and insignificant differences (regarding naming of temporary files like /c/DOCUME~1/s360339.aoa/LOCALS~1/Temp/cc8nrdfh.o) between the config.log files. For reference, I have attached the config.log file. config.status, configure.ac and configure available upon request. The referenced builds used gcc-4, but the same problem occurred using gcc-3. When I attempted to debug the failing executable using gdb, here's what happened: $ gdb /usr/local/zsh-2009-03-11/bin/zsh.exe GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-cygwin... (no debugging symbols found) (gdb) run Starting program: /usr/local/zsh-2009-03-11/bin/zsh.exe [New thread 2092.0xd38] gdb: unknown target exception 0xc139 at 0x7c96478e Program exited with code 03000471. You can't do that without a process to debug. (gdb) This lends further credence to my hypothesis that some runtime dependency is missing. Googling that exit code seems to indicate that this error code corresponds to: 0xc139 Entry Point Not Found Thoughts? Please let me know what additional info I can provide. Regards, Vin config.log.gz Description: GNU Zip compressed data -- 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Vin Shelton wrote: When I build the latest zsh sources on Cygwin 1.7 using ncurses8-5.5.3, I get a working zsh. When I build the same zsh sources against ncurses9-5.7-13, although the build completes successfully, the executable will not run: $ /usr/local/zsh-2009-03-11/bin/zsh -f $ echo $? 127 My guess is that some kind of runtime dependency is missing, but: $ cygcheck /usr/local/zsh-2009-03-11/bin/zsh.exe C:\cygwin\usr\local\zsh-2009-03-11\bin\zsh.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\usr\local\zsh-2009-03-11\bin\libzsh-4.3.9-dev-1.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygncurses-9.dll C:\cygwin\bin\cyggcc_s-1.dll Just for grins, could you rebuild zsh against libncurses9 -- but this time use gcc3? cygiconv-2 and cygncurses-9 use the static gcc-3.4.4 libgcc.a, but you are apparently using the gcc-4.3.2 shared libgcc. I just wonder if that presents an incompatibility that could explain what you are seeing. -- Chuck -- 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Charles Wilson wrote: Vin Shelton wrote: When I build the latest zsh sources on Cygwin 1.7 using ncurses8-5.5.3, I get a working zsh. When I build the same zsh sources against ncurses9-5.7-13, although the build completes successfully, the executable will not run: $ /usr/local/zsh-2009-03-11/bin/zsh -f $ echo $? 127 My guess is that some kind of runtime dependency is missing, but: $ cygcheck /usr/local/zsh-2009-03-11/bin/zsh.exe C:\cygwin\usr\local\zsh-2009-03-11\bin\zsh.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\usr\local\zsh-2009-03-11\bin\libzsh-4.3.9-dev-1.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygncurses-9.dll C:\cygwin\bin\cyggcc_s-1.dll Just for grins, could you rebuild zsh against libncurses9 -- but this time use gcc3? cygiconv-2 and cygncurses-9 use the static gcc-3.4.4 libgcc.a, but you are apparently using the gcc-4.3.2 shared libgcc. I just wonder if that presents an incompatibility that could explain what you are seeing. Thanks for replying, Chuck. As I mentioned in the initial email, I had already done just that. Just to be sure, I did it again, with the same result: $ cygcheck ./zsh.exe C:\cygwin\usr\local\zsh-2009-03-11\bin\zsh.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\usr\local\zsh-2009-03-11\bin\libzsh-4.3.9-dev-1.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygncurses-9.dll $ cygcheck ./libzsh-4.3.9-dev-1.dll C:\cygwin\usr\local\zsh-2009-03-11\bin\libzsh-4.3.9-dev-1.dll C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygncurses-9.dll How can I ascertain what entry point is not being found? - Vin -- 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Vin Shelton wrote: How can I ascertain what entry point is not being found? You need depends.exe. http://www.dependencywalker.com/ 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/
Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13
Vin Shelton wrote: Charles Wilson wrote: Just for grins, could you rebuild zsh against libncurses9 -- but this time use gcc3? cygiconv-2 and cygncurses-9 use the static gcc-3.4.4 libgcc.a, but you are apparently using the gcc-4.3.2 shared libgcc. I just wonder if that presents an incompatibility that could explain what you are seeing. Thanks for replying, Chuck. As I mentioned in the initial email, I had already done just that. Just to be sure, I did it again, with the same result: No you didn't, the point was: use gcc3, in other words: mixing libraries built with gcc3 and gcc4 doesn't work. -- R.Berber -- 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/
