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
library.
For me it's looking like static versions _cannot_ work on windows, but i might
be wrong there.
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 http://sourceforge.net/projects/interix-wgcc.
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!
Martin
Cheers, Markus
-----Ursprüngliche Nachricht-----
Von: Martin Sebor [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 14. September 2006 18:29
An: [email protected]
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
great...
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
