stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: problem using static libraries on windows
Date Fri, 15 Sep 2006 16:40:10 GMT
Duft Markus wrote:
> Hey,
> First of all, thanks for the reply, and yes, there is still an issue with the static
version i'd like to resolve. It's not really urgent, but i would need it for certain cases.
> The thing is, that building stdcxx is not really a problem, since i'm still doing it
with build.bat, means devenv.exe. Whats the problem is, that i'm building applications with
my wgcc wrapper around cl.exe, and those applications use stdcxx. But the problem with the
static version (shared works fine now) is, that i get lots of duplicate symbols when just
adding the stdlib15s.lib for the linker.

That suggests that the native C++ standard library is being linked
in along with stdcxx.

> On the other hand when adding /NODEFAULTLIB:msvcprt i get thousands of unresolved symbols
(in a very simple test case). I believe this is because of stdcxx depending on msvcprt as
far as i have seen.

Msvcprt is the MSVC implementation of the C++ standard library.
stdcxx cannot depend on it since it's another implementation of
the same. The two are mutually exclusive -- a program can either
depend on one or the other, but not both. Unresolved references
to symbols defined in msvcprt indicate that some object files
that are being linked were compiled against the MSVC C++ standard

> For me it's looking like static versions _cannot_ work on windows, but i might be wrong

We've been testing and Rogue Wave customers have been using the
archive library on Windows for many years so I'm quite confident
that if there is a problem it's either with the options used to
build stdcxx (the stdcxx build infrastructure is different and
much more recent from what's used by the Rogue Wave one), or
with the building of the executables that exhibit the problem.

If any part of the program depends on the native implementation
of the C++ standard library that comes with MSVC linking it also
with stdcxx is likely to have the symptoms you describe. The MSVC
#pragma comment feature makes it possible to insert dependencies
on libraries into header or source files which can makes it less
than obvious when hunting down these types of issues.

> On Interix you may want to add wgcc support to the GNUMakefile !? Ist a wrapper around
cl.exe, so one can work like when using gcc, but produces native win32 binary images (additionally
compilation is faster, etc....). You can find wgcc at

Neat! We'll check it out.

> This would just create a little bootstrap problem, since wgcc wants to use stdcxx, but
it can operate without it well...
> P.S.: i'm not offended if you won't use wgcc, just a tip ;o)

Thanks, it sounds like a useful tool!


> Cheers, Markus
> -----Urspr√ľngliche Nachricht-----
> Von: Martin Sebor [] 
> Gesendet: Donnerstag, 14. September 2006 18:29
> An:
> Betreff: Re: problem using static libraries on windows
> Duft Markus wrote:
>>hey there!
>>i have a little problem (see STDCXX-287) with using stdcxx. The shared 
>>version does work somehow, but iostreams seem to be broken, and the 
>>static version cannot be linked because of billions of conflicts with 
>>msvcprt. how can i use the static version without conflicting with 
>>microsoft runtimes? Or even better, how can i get the shared version 
>>to work?
>>I'm working on the command-line (Interix, but using microsoft tools 
>>(cl.exe & co)) and not in the VS IDE, so commandline tips would be 
> We don't have a command line only solution for MSVC at this time (it is there for all
other compilers including gcc on Interix) but based on feedback like yours we're thinking
about adding it. I've worked around it in the past by writing a simple little wrapper script
for cl.exe to translate UNIX paths to Windows and invoked it through the GNUMakefile infrastructure
just like any other compiler. IIRC, this was on Cygwin and very slow but it got the job done.
> Since you said that STDCXX-287 is not an issue, do you still need any help with the shared
vs archive library issue?
> You can see the MSVC command line options we use to build stdcxx in the IDE. In general,
the compiler options are something like
> this: -EHsc -MD -W3 -O2 -GR (or -MDd -Zi to enable debugging), and we pass /NODEFAULTLIB:msvcprt
to the linker to avoid linking with the native implementation of the C++ Standard Library.
That should prevent any conflicts. Let me know if there's anything else.
> Martin

View raw message