This is the mail archive of the mailing list for the libstdc++ project.

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

Re: GNU Technical Consulting

[Get raw message]
[Another FAQ anonymized, answered and sent BCC.]

> Our firm, [...] Technologies, is in the process of porting a Win 32
> application that is multi-threaded and makes extensive use of the standard
> C++ libraries to GNU.  We have encountered software failures in stress tests
> that appear to be rooted in our not having built the libraries or our
> application or both for multi-threaded operation.  Are you aware of
> consultants with expertise in this area to whom you could refer us?  

For various reasons, I must refer you to the standard file distributed
by the FSF related to people and companies that want to work on GNU
software for hire, .

However, assuming that you have someone on your own team willing to do
a little leg work, you may have a fairly simple problem that requires
no outside consultant.  Since our main interest is in promoting GCC
for any platform, here is some "free advice".  All this advice assumes
that you are using gcc 3.0 or later (more or less in line with the
official FSF source tree).

[When I first read the question, I assumed you were porting to g++ on
 Win32.  Upon rereading, I suppose it could be any g++ port, hopefully
 GNU/Linux or some other free and open OS.  Here is something I wrote
 up assuming that you are porting the application code to g++ on Win32
 but the steps to debug the situation without a consultant mostly fits
 for other platforms as well.]

Check the following: (1) If `gcc -v' reports `Thread model: none' then
you have a problem that might be solved by merely rebuilding gcc with
--enable-threads=win32 (use --enable-threads or --enable-threads=posix
instead on most other POSIX platforms).  (2) Next, if `gcc -v' reports
`Thread model: win32' then you have a problem that might be solved by
merely rebuilding your entire application with the -mthreads option
added to CCFLAGS (the option varies by port and may not be right for
all the Win32 ports --- while paying special attention to the entries
for cpp and lib, looking through the output of `gcc -dumpspecs' for
your port is the only definitive place to find the right answer for
your port).  If you have the first problem and don't have anyone able
to rebuild gcc from source, then I suggest contacting the people that
release the binary version of gcc you use and see if they are willing
to make such a release (possibly as a work for hire).  If you have
satisfied both the first and the second issue without resolving your
problem, then it is possible that someone, possibly someone you hire,
needs to update or install initial thread support for your port in
libstdc++-v3/config/os/*/bits/os_defines.h and
libstdc++-v3/ (or, more rarely, some other file).

OK, even if you get to that point or get stuck trying to get to that
point, you might still decide you need no consultant.  You do not
mention exactly which Win32 gcc port you are currently using, if any,
but my quick look at gcc configuration files makes me think that at
least one of them does not support threads (at least not in any manner
similar to other modern ports).  In that case, you might want to
switch to another Win32 gcc port.  (There are at least 3 common ports,
each with slightly different assumptions on how much Microsoftening is
appropriate.)  I will mention the one port that looks OK to me at a
quick glance: cygwin appears to support threads when built properly.
I have no idea if any particular binary release is built with such
support, but you can check as I have outlined above.


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