Subject: SOLVED!! linking against MS .lib files in B18 (and possibly egcs/B19)
From: [email-masked] (Mikey)

18 Dec 1997 16:14:11 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Reply-To: [email-masked]
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="--=_349975924311027075358a9.MFSBCHJLHS"
To: [email-masked]

----=_349975924311027075358a9.MFSBCHJLHS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi All ;^)
	I have some good news.

  Attached are patches for producing a beta 18 compatible
(and possibly egcs/B19 compatible) ld.exe that will allow linking 
with MS .lib files, AND libcygwin.a type files.

I just posted copies of fixed ld.exe objdump.exe dlltool.exe
the specs file, and a couple of needed .o's to
ftp://ftp.deninc.com/incoming
as
B18-patched-link-compat-ld.tgz
for people who don't want to rebuild from source.

also posted SDK_4_ming_cygwin32.tar.gz
which has the header patches for using the
Platform SDK headers with ming & cygwin

The patch makes use of a couple of the routines
posted to the list by Marcus Hall.
[email-masked]
Thanks Marcus!!! ;^)

User visible changes include

strip.exe works on images with .reloc sections now.
ie 
strip --strip-unneeded cygwin.dll
gives a usable .dll
(still  can't strip files with .rsrc sections)

..reloc sections are now always terminated properly on 
win95, and NT w/out C2 security
(the tradeoff is that you will always have a .reloc section unless you strip it off ;^)

new options for ld.exe
 --subsystem wwindows
 --subsystem wconsole  
(entry @ _wWinMainCRTStartup _wmainCRTStartup respectively for UNICODE apps
currently only useful when linking against the real msvcrt.lib & using vc++ headers)

-lLIBNAME         option to ld.exe (small L)
searches first for LIBNAME.lib files, then libLIBNAME.a
(should make for easier use under command.com/cmd.exe)

new options for gcc.exe
-windows (gui apps pull in the patched Platform SDK headers if you have them
                   see SDK_4_ming_cygwin32.tar.gz)
-console   (console ditto ;^)
use -mwindows or -mconsole for correct .o's with the FSF headers/libs
-dll             (links in the appropriate stub, main_dll.o for windows dll's WinMain_dll.o for console dll's)
-wm (mingw32+Platform SDK) change the paths in specs as appropriate for your system

entry point WinMainCRTStartup added to crt0.c/o in binary dist
(gets rid of those pesky warnings ;^)

relocatable .dll's & .exe's work with the specs file included in binary dist
when linked against libcygwin.a (only tested with coolview)

so to produce a simple nonrelocatable gui dll from source with a DllMain entry point

dlltool --dllname dllmain.dll --output-exp dllmain.exp --output-lib dllmain.a --def dllmain.def
gcc -windows -dll -Wl,--image-base,0x1C000000 -o dllmain.dll dllmain.exp dllmain.c

for a relocatble .dll you must still do 2 passes

gcc -windows -dll -Wl,--base-file=dllmain.base -o dllmain.dll dllmain.c
dlltool --dllname dllmain.dll --base-file dllmain.base --output-exp dllmain.exp --output-lib dllmain.a --def dllmain.def
gcc -windows -dll -o dllmain.dll dllmain.exp dllmain.c

  Also a patch that should do the same thing for egcs/B19, produced
against the gas-971123 snap (MAYBE ;-)

From MS's PEI spec

>5.5.6. COMDAT Sections (Object Only)
>The Selection field of the Section Definition auxiliary format is 
>applicable if the section is a COMDAT section: a section that 
>can be defined by more than one object file. (The flag 
>IMAGE_SCN_LNK_COMDAT is set in the Section Flags field 
>of the section header.) The way that the linker resolves the multiple 
>definitions of COMDAT sections is determined by the Selection field.

>The first symbol having the section value of the COMDAT section 
>is the section symbol This symbol has the name of the section, 
>Value field equal to 0, the section number of the COMDAT section 
>in question, Type field equal to IMAGE_SYM_TYPE_NULL, Class 
>field equal to IMAGE_SYM_CLASS_STATIC, and one auxiliary 
>record. The second symbol is called "the COMDAT symbol" and 
>is used by the linker in conjunction with the Selection field.			<<<<<<<<< the main thing

I have added a routine to the bfd backend (in pei-i386.c) to offer the 
comdat symbol/associated section info  in a seperate
  routine pei_get_comdat_info() then fixed ld and objdump to use it.

Also added a struct to asection->pe_comdat_info to offer the info to applications,
this seemed to be the lesser of all evils, if it breaks other backends,
the #ifdefs and extern funcs wouldn't be hard to set up.

also minor changes to dlltool to allow inter operability with 
  vc++ generated import libraries/objects.
  exported symbols can start with ? (c++) as well as _ (c)
  this will allow generated .def files with v(c++) symbols to compile
  also corrects _imp__ symbol names.

The changes were made against the gas-971123 snap,
as well as the B18 source tree.

/ *  THIS SOFTWARE IS NOT COPYRIGHTED
 *
 *  This source code is offered for use in the public domain. You may
 *  use, modify or distribute it freely.
 *
 *  This code is distributed in the hope that it will be useful but
 *  WITHOUT ANY WARRANTY. ALL WARRENTIES, EXPRESS OR IMPLIED ARE HEREBY
 *  DISCLAMED. This includes but is not limited to warranties of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 */

TODO
objcopy/strip fixed for stripping exe's/dll's with .rsrc sections

objcopy/strip associated sections removed when COMDAT section stripped
(not critical as the new ld should ignore associated sections without a COMDAT)
dlltool still needs to be fixed to produce more MS compatible import libraries so link.exe
can be used with them

On Wed, 29 Oct 1997 22:53:23 -0500, you wrote:

>   From: [email-masked] (Mikey)
>   Date: Thu, 30 Oct 1997 01:11:06 GMT
>
>   There are quite a few binary incompatibilities like this left between cygwin32
>   and MS pei that need to be corrected, but it has been so long since the last

< snip>

>
>That particular problem was fixed some months ago.  It means that if
>you want to use the new linker and/or the new assembler, you must
>recompile and reassemble every .o and .a file.
>
>Ian
>

([email-masked])
delete REMOVETHIS from the above to reply
         Mikey

Windows vs Linux is a no-win situation.

Windows 95: --  32-bit extensions and a GUI   
shell for a 16-bit patch to an 8-bit OS       
originally coded for a 4-bit processor 
written by a 2-bit company that   
can't produce 1 bit of quality.

----=_349975924311027075358a9.MFSBCHJLHS
Content-Type: application/octet-stream; name=bfd_ld_comdat_sym_B18.dif.gz
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=bfd_ld_comdat_sym_B18.dif.gz

----=_349975924311027075358a9.MFSBCHJLHS
Content-Type: application/octet-stream; name=bfd_ld_comdat_sym_gas971123.dif.gz
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=bfd_ld_comdat_sym_gas971123.dif.gz

----=_349975924311027075358a9.MFSBCHJLHS--
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".