Mail Archives: cygwin/1998/03/08/17:35:22
[trying this again since my last article was truncated]
In article <01BD4856 DOT A48D8F90 DOT zow AT mdbs DOT com>,
\"Zow\" Terry Brugger <zow AT mdbs DOT com> wrote:
>I have concluded that this ll.dll is indeed from X11 . I just got the X11
>package compiled for B19 from one of the gentlemen working on Xemacs for
>NT, and the problem went away. I imagine that any of the other X11 libs
>that people have put together would work as well. In the interim, if anyone
>would like to put up the X11 package that I have on a public ftp site, let
>me know and I'll up it there (I can't afford to mail it or ftp to private
>servers as it's 4 Megs and we have a 56K connection).
Another possibility is that, although the B18 version of ld may no longer
be in your path, it is possible that the old B18 ld templates are still
in some path that ld is using. The way to check this is to use the -v
option on the ld line that produces the .dll. You will see a template
file being used in the output. There should be something that looks
like:
..idata BLOCK(__section_alignment__) :
{
/* This cannot current be handled with grouped sections.
See pe.em:sort_sections. */
*(.idata$2)
*(.idata$3)
LONG (0); LONG (0); LONG (0); LONG (0); LONG (0);
.
.
.
The LONG (0)'s above are what should be terminating the import section of
the .dll. If they are not present, then this is the problem. Check your
disk for any old ldscript directories and rename them to something else.
That should solve this problem.
--
http://www.bbc.com/ cgf AT bbc DOT com "Strange how unreal
VMS=>UNIX Solutions Boston Business Computing the real can be."
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -