mingwm10.dll

[Bob Rossi-2]

On Wed, Feb 14, 2007 at 01:39:15PM +1100, James Steward wrote:

> On Tue, 2007-02-13 at 20:55 -0500, Bob Rossi wrote:
> > On Tue, Feb 13, 2007 at 04:25:30PM -0800, Brian Dessent wrote:
> > > Bob Rossi wrote:
> > >
> > > > and even with my full blown application, I don't get it brought in.
> > > >
> > > > What triggers this dll?
> > >
> > > Look at the specs file.  It is added when using -mthreads, which is
> > > required for correct behavior if you code uses multiple threads.
> > >
> > > *libgcc:
> > > %{mthreads:-lmingwthrd} -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
> >
> > Wierd. I use apr (http://apr.apache.org/), and I use the thread support
> > that it has. So, somehow I'm getting thread support, but don't end up
> > with the mingw10.dll problem.
> >
> > Any ideas why?
>
> Could it be that the apr stuff wraps the mingw10.dll within it's own?
>
> For example, I wrote a dll that uses libxml2.  If I objdump and look for
> the dlls used by my dll it reports libxml2 among others.  If I then
> objdump libxml2.dll I see that it uses iconv.dll and zlib1.dll - however
> they are not mentioned in the objdump of my dll!

What you are suggesting is possible. However, I build everything
statically. There are no dll's. Is there a way that I can prove this?

Thanks,
Bob Rossi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Brian Dessent]

Bob Rossi wrote:

> Wierd. I use apr (http://apr.apache.org/), and I use the thread support
> that it has. So, somehow I'm getting thread support, but don't end up
> with the mingw10.dll problem.

If you are using APR with threads enabled and it hasn't added -mthreads
to the CFLAGS then APR is broken.  I took a quick look at its m4 files
and I see APR_PTHREADS_CHECK() in apr_threads.m4 checks for -mthreads,
so it should be in your CFLAGS.  If your app is multithreaded and you
aren't compiling with -mthreads then expect all sorts of strange
unexplainable bugs, especially if you use C++ exceptions.

Brian

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Bob Rossi-2]

On Tue, Feb 13, 2007 at 06:59:37PM -0800, Brian Dessent wrote:

> Bob Rossi wrote:
>
> > Wierd. I use apr (http://apr.apache.org/), and I use the thread support
> > that it has. So, somehow I'm getting thread support, but don't end up
> > with the mingw10.dll problem.
>
> If you are using APR with threads enabled and it hasn't added -mthreads
> to the CFLAGS then APR is broken.  I took a quick look at its m4 files
> and I see APR_PTHREADS_CHECK() in apr_threads.m4 checks for -mthreads,
> so it should be in your CFLAGS.  If your app is multithreaded and you
> aren't compiling with -mthreads then expect all sorts of strange
> unexplainable bugs, especially if you use C++ exceptions.

OK.

Well, then maybe I have a bug to report. I compile apr statically. In
the lib/ directory I have,
  apr.exp  libapr-1.a  libapr-1.la  pkgconfig

The command,
  $ objdump -p libapr-1.a  | grep "DLL Name"
returns nothing.

When I build and link against it, the word "thread" is not used anywhere
on the compile or link lines.

Finally, if I grep for 'thread' in bin/apr-1-config, nothing is
returned.

So, I'm fairly sure that -mthread isn't being used. I'm using both
threads and C++ exceptions and have not noticed any problems as of yet.
Is this a bug in my build system?

Thanks,
Bob Rossi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Brian Dessent]

Bob Rossi wrote:

> Well, then maybe I have a bug to report. I compile apr statically. In
> the lib/ directory I have,
>   apr.exp  libapr-1.a  libapr-1.la  pkgconfig
>
> The command,
>   $ objdump -p libapr-1.a  | grep "DLL Name"
> returns nothing.

Nor should it.  A static archive is just a collection of .o files that
have not been linked yet.  There is no way for it to know about or even
specify anything about a DLL, or any other kind of library.  It may
depend on other libraries, it may not, there's no way to tell because it
has not been linked yet.  So this is meaningless.

What you should look at is config.log for when libapr was configured,
and the resulting Makefile for what was set for CFLAGS.  Also, if you
specified --enable-threads=something to configure.

> When I build and link against it, the word "thread" is not used anywhere
> on the compile or link lines.
>
> Finally, if I grep for 'thread' in bin/apr-1-config, nothing is
> returned.
>
> So, I'm fairly sure that -mthread isn't being used. I'm using both
> threads and C++ exceptions and have not noticed any problems as of yet.
> Is this a bug in my build system?

You should ask on the apr list.  But it sounds like apr's configury is
not doing the right thing on MinGW if it has enabled threads but not
added -mthreads to CFLAGS.

Brian

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Brian Dessent]

Brian Dessent wrote:

> You should ask on the apr list.  But it sounds like apr's configury is
> not doing the right thing on MinGW if it has enabled threads but not
> added -mthreads to CFLAGS.

...and in the meantime you should add -mthreads to CFLAGS yourself (e.g.
./configure CFLAGS="-g -O2 -mthreads") when building libapr and when
building your project.  All objects used in a multithreaded app should
be compiled with -mthreads, not just parts.  The option does more than
just link to mingwm10.dll, it also #defines _MT which is used elsewhere
in the headers.  If your app is multithreaded and has been built thus
far without -mthreads then it's luck that you haven't noticed any
problems.  This is like depending on undefined behavior, it may work
fine for years or it may blow up in flames.

Brian

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Bob Rossi-2]

On Tue, Feb 13, 2007 at 07:43:00PM -0800, Brian Dessent wrote:

> Brian Dessent wrote:
>
> > You should ask on the apr list.  But it sounds like apr's configury is
> > not doing the right thing on MinGW if it has enabled threads but not
> > added -mthreads to CFLAGS.
>
> ...and in the meantime you should add -mthreads to CFLAGS yourself (e.g.
> ./configure CFLAGS="-g -O2 -mthreads") when building libapr and when
> building your project.  All objects used in a multithreaded app should
> be compiled with -mthreads, not just parts.  The option does more than
> just link to mingwm10.dll, it also #defines _MT which is used elsewhere
> in the headers.  If your app is multithreaded and has been built thus
> far without -mthreads then it's luck that you haven't noticed any
> problems.  This is like depending on undefined behavior, it may work
> fine for years or it may blow up in flames.

Thanks! I'll look more into this.

Bob Rossi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[James Steward-2]

On Tue, 2007-02-13 at 19:43 -0800, Brian Dessent wrote:

> Brian Dessent wrote:
>
> > You should ask on the apr list.  But it sounds like apr's configury is
> > not doing the right thing on MinGW if it has enabled threads but not
> > added -mthreads to CFLAGS.
>
> ...and in the meantime you should add -mthreads to CFLAGS yourself (e.g.
> ./configure CFLAGS="-g -O2 -mthreads") when building libapr and when
> building your project.  All objects used in a multithreaded app should
> be compiled with -mthreads, not just parts.  The option does more than
> just link to mingwm10.dll, it also #defines _MT which is used elsewhere
> in the headers.  If your app is multithreaded and has been built thus
> far without -mthreads then it's luck that you haven't noticed any
> problems.  This is like depending on undefined behavior, it may work
> fine for years or it may blow up in flames.

This is for C++ apps only, isn't it?

`-mthreads'
     Support thread-safe exception handling on `Mingw32'.  Code that
     relies on thread-safe exception handling must compile and link all
     code with the `-mthreads' option.  When compiling, `-mthreads'
     defines `-D_MT'; when linking, it links in a special thread helper
     library `-lmingwthrd' which cleans up per thread exception
     handling data.

If a threaded app is written in C where there's no exception handling,
it shouldn't be a problem, right?

Cheers,
James.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Brian Dessent]

James Steward wrote:

> If a threaded app is written in C where there's no exception handling,
> it shouldn't be a problem, right?

I'm not sure.  But I did notice that if _MT is not defined then stdio.h
selects faster non-threadsafe versions of getc, putc, getchar, and
putchar.  So using those functions in a multithreaded C application
without -mthreads would be a possible example of such a case.  I didn't
see any other obvious uses of _MT but I didn't really look that hard.

Brian

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Bob Rossi-2]

On Tue, Feb 13, 2007 at 10:10:33PM -0800, Brian Dessent wrote:

> James Steward wrote:
>
> > If a threaded app is written in C where there's no exception handling,
> > it shouldn't be a problem, right?
>
> I'm not sure.  But I did notice that if _MT is not defined then stdio.h
> selects faster non-threadsafe versions of getc, putc, getchar, and
> putchar.  So using those functions in a multithreaded C application
> without -mthreads would be a possible example of such a case.  I didn't
> see any other obvious uses of _MT but I didn't really look that hard.

My application is C++ anyways, even though apr is written in C.

Bob Rossi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[James Steward-2]

On Tue, 2007-02-13 at 22:10 -0800, Brian Dessent wrote:

> James Steward wrote:
>
> > If a threaded app is written in C where there's no exception handling,
> > it shouldn't be a problem, right?
>
> I'm not sure.  But I did notice that if _MT is not defined then stdio.h
> selects faster non-threadsafe versions of getc, putc, getchar, and
> putchar.  So using those functions in a multithreaded C application
> without -mthreads would be a possible example of such a case.  I didn't
> see any other obvious uses of _MT but I didn't really look that hard.

Curious.

I believe the OP uses g++, threads, linked static?  However I'd like to
know whether there is any impact of this for my situation, gcc, threads,
linked dynamic.

I built both my test app and dll with and without -mthreads and diffed
the objdump -D output.  There were a few differences (say about 6 lines)
even though I do not directly use any of the functions that may differ
in stdio.h depending on whether _MT is defined or not (see below).

I do use fgets.  Could that call getc?  Otherwise I wonder why gcc
creates differences in the compiled code?

Also, the thread cleanup helper dll was not in the list according to
objdump -p of the -mthreads built version, so it must be a g++ thing
only?

I guess so long as one thread only accesses a file using the non thread
safe versions of the functions (below) there would be no danger of
corruption.

Regards,
James.

#if !defined _MT

__CRT_INLINE int __cdecl getc (FILE* __F)
{
  return (--__F->_cnt >= 0)
    ?  (int) (unsigned char) *__F->_ptr++
    : _filbuf (__F);
}

__CRT_INLINE int __cdecl putc (int __c, FILE* __F)
{
  return (--__F->_cnt >= 0)
    ?  (int) (unsigned char) (*__F->_ptr++ = (char)__c)
    :  _flsbuf (__c, __F);
}

__CRT_INLINE int __cdecl getchar (void)
{
  return (--stdin->_cnt >= 0)
    ?  (int) (unsigned char) *stdin->_ptr++
    : _filbuf (stdin);
}

__CRT_INLINE int __cdecl putchar(int __c)
{
  return (--stdout->_cnt >= 0)
    ?  (int) (unsigned char) (*stdout->_ptr++ = (char)__c)
    :  _flsbuf (__c, stdout);}

#else  /* Use library functions.  */

_CRTIMP int __cdecl     getc (FILE*);
_CRTIMP int __cdecl     putc (int, FILE*);
_CRTIMP int __cdecl     getchar (void);
_CRTIMP int __cdecl     putchar (int);

#endif



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[rogerwells]

FWIW

I am following this with interest since we field lots (~25) programs as
part of our survey system that are all multithreaded.  They are "C"
programs that have been built first with MinGW gcc v2.95.2 and for the
last year or so with gcc v3.3.1.  We have never used the -mthread flag
and never have had a problem from this source as far as we know.  Maybe
its time for some experiments...

Brian Dessent wrote:

> James Steward wrote:
>
>  
>> If a threaded app is written in C where there's no exception handling,
>> it shouldn't be a problem, right?
>>    
>
> I'm not sure.  But I did notice that if _MT is not defined then stdio.h
> selects faster non-threadsafe versions of getc, putc, getchar, and
> putchar.  So using those functions in a multithreaded C application
> without -mthreads would be a possible example of such a case.  I didn't
> see any other obvious uses of _MT but I didn't really look that hard.
>
> Brian
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>
>  

--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.wells@...


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Danny Smith]

>
> Curious.
>
> I believe the OP uses g++, threads, linked static?  However
> I'd like to
> know whether there is any impact of this for my situation,
> gcc, threads,
> linked dynamic.
>
> I built both my test app and dll with and without -mthreads and diffed
> the objdump -D output.  There were a few differences (say
> about 6 lines)
> even though I do not directly use any of the functions that may differ
> in stdio.h depending on whether _MT is defined or not (see below).

GCC will optimize  something like this
 printf ("a");
to putchar  

Likewise with iostream char I/O/

Given the lack of documentation on the _MT preprocessor switch, maybe
the stdio optimizations
should be based on a runtime switch (_CRT_MT) which really does know
about thread support

Danny


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Σταμάτης Μητροφάνης]

Danny Smith wrote:

> GCC will optimize  something like this
>  printf ("a");
> to putchar  
>
> Likewise with iostream char I/O/
>
> Given the lack of documentation on the _MT preprocessor switch, maybe
> the stdio optimizations
> should be based on a runtime switch (_CRT_MT) which really does know
> about thread support
>
> Danny

This code seems to work fine with the unmodified GCC:



VOID NTAPI tls_callback(PVOID dll_handle, DWORD reason, PVOID reserved)
{ printf("TLS callback! %d\n", reason); }

DWORD tls_index = 0;
PIMAGE_TLS_CALLBACK callbacks[] = { tls_callback, 0 };
extern "C" {
    IMAGE_TLS_DIRECTORY _tls_used =
{0,0,(DWORD)&tls_index,(DWORD)callbacks,0,0};
}


You can simply put whatever you want in `tls_callback', compile this
into an object, and link that instead of `mingwm10.dll'.  However, that
is NOT the best solution.  The best solution would be to be able to mark
each callback function and each global TLS variable with some special
keyword and have the compiler and linker write out all the PE structures
(or have the linker recognise multiple `_tls_used' definitions). The PE
format was designed to support an arbitrary number of such callbacks. Of
course, if there is only one such callback in the executable, then the
above works fine.

Problem (mostly) solved.  At least for Windows NT, 2000, XP and all
later versions.

As for Windows 98, 95 etc., well, gcc MIGHT need an option to link or
not to link with `mingwm10.dll'.  I'd prefer NOT linking be the default,
but you may want to maintain backwards compatibility.

I haven't tested this under MS-Windows-95 (or should I say MS-DOS-95?)
so it might work anyway!

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users