This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: MSVCRT/threads


eyal.ben-david@aks.com writes:
> 
> Thats correct. I tried compile a C++ program that uses iostream.
> 1. There is a linking problem with HUGE_VAL
> 2. The linker tries to link with 'lcrtdll' even if it is not mentioned at
> all in the specs.
> 3. I put a HUGE_VAL in a dummy libcrtdll.a to eliminate problems 1, 2
> 4. Only then the program linked OK but crashed at runtime.

Use the msvcrt40 runtime additions. See

  ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/egcs-1.1/

It's untested, so beware of more than the usual NO WARRANTY caveats. 

> 
> I think that the situation of a __MSVCRT__  #define in the mingw32 headers
> is bad.
> The headers should not remind __MSVCRT__ or any other macro that depends
> on the actual runtime linked.

Actually, that's not possible without some extra work, since there 
*are* differences in API between the two runtimes. For example, MSVCRT 
has some extra routines that we don't want exposed for CRTDLL 
(beginthreadex for example).

> 
> Instead mingw32 should add some functions in libmingw32.a to overcome the
> problem.
> It is clear that there will be two libmingw32.a files (for msvcrt, and for
> crtdll).
> 
> Example:
> 
> The code (from errno.h)
> 
>      #ifdef    __MSVCRT__
>      /* One of the MSVCRTxx libraries */
>      extern int*    __imp__sys_nerr;
>      #define   sys_nerr  (*__imp__sys_nerr)
>      #else
>      /* CRTDLL run time library */
>      extern int*    __imp__sys_nerr_dll;
>      #define sys_nerr    (*__imp__sys_nerr_dll)
>      #endif
> 
> could be replaced with:
> 
>      extern int*         __mingw32_sys_nerr(void);
>      #define sys_nerr    (*__mingw32_sys_nerr())
> 
> All the differences will be in the function __mingw32_sys_nerr(void).
> A similar pattern for all other differences.
> 

Almost, but there are a few more. For example, you need to make sure
that libmoldname.a is linked to the right runtime.

> Gains:
> * I can compile my code so that it will not depend on the runtime selected.
> * All the libraries (except libmingw32.a) will not depend on the runtime
> DLL.
> * Distribution is much simpler. (no duplication of all the libs).
> 
> What do you think ?

I think it's very good idea, but the details of how it's supposed to work
needs to be worked out.

If you can implement it cleanly and submit the changes, I'll be more than
happy to include them in the standard distribution.

Regards,
Mumit

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]