delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1997/07/07/18:03:46

From: root AT jacob DOT remcomp DOT fr (root)
Subject: Re: MSVC link: a proposal for a general solution
7 Jul 1997 18:03:46 -0700 :
Sender: mail AT cygnus DOT com
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <m0wlKJO-000AK2C.cygnus.gnu-win32@jacob.remcomp.fr>
Original-To: pjm AT rbd DOT com (Paul J. Metzger)
Original-Cc: gnu-win32 AT cygnus DOT com
In-Reply-To: <Pine.LNX.3.91.970707112233.16490F-100000@thunder.rbd.com> from "Paul J. Metzger" at Jul 7, 97 11:31:44 am
Original-Sender: owner-gnu-win32 AT cygnus DOT com

Paul:
> 
> My ultimate objective is to link existing .lib files compiled with
> MSVC with Unix code ported to NT via the GNU Win32 environment.  It
> doesn't matter to me if the startup code is cygnus or MSVC.  Likewise,
> it doesn't matter whose 'printf' (and similar functions) I use.
> 
Well, if you need cygnus, then the best is to use the startup of cygnus,
and the printf of cygnus.

BUT

PROBLEMS WITH THE STATIC LINK APPROACH:
--------------------------------------

You should call from your main, somehow, the C runtime initialization of
MSVC so that a printf in your .libs will behave as expected, i.e. with a
FILE structure as defined by MSVC, and not a FILE as defined by cygnus...

Printf expects implicitely that stdout is pointing to the right thing, and
FILE * point to slightly different structs with cygnus and msvc. This is just
an example, since all structures defined in .hs will probably be slightly
different.

To call the startup code of msvc looks difficult to do since that code expects 
to be called from the operating system, and it will not work just with adding

	_mainCRTStartup();
in your _main function.

You should get the startup source code (comes with the MSVC distribution) and 
see how you should initialize things so that the library programs are happy.

In the last resort you will end up writing an emulation of MSVC's runtime
using cygnus... not a very exciting thing to do...

Another problem is the obvious name-conflicts
If you have an object file in a .lib with

void foo(void)
{
	printf("Hello from msvc\n");
}

THAT printf should be msvc's printf and not cygnus. Since BOTH functions are
called printf (cygnus's and msvc's), the linker will not be able to choose 
the right one.
Again, THIS example of printf probably would work in both cases, but there are
surely calls that do not.


SOLUTION:
--------

USE A DLL!!!

Build a DLL with your msvc code, and link it using msvc. THEN use LoadLibrary
and GetProcAddress to get the function pointers to the code you want to use
from inside your cygnus code.

Then just use those function pointers instead of calling your msvc functions
directly.

Voila!

This BYPASSES all problems, since you build a self consistent executable
with msvc, using your .libs. The startup code will work correctly etc.

-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France
-
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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019