From: cgf AT bbc DOT com (Christopher Faylor) Subject: Re: LL.dll or is it ii.dll 8 Mar 1998 17:35:22 -0800 Message-ID: References: <01BD4856 DOT A48D8F90 DOT zow AT mdbs DOT com> Reply-To: cgf AT bbc DOT com To: gnu-win32 AT cygnus DOT com [trying this again since my last article was truncated] In article <01BD4856 DOT A48D8F90 DOT zow AT mdbs DOT com>, \"Zow\" Terry Brugger 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".