stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: svn commit: r525939 - in /incubator/stdcxx/trunk/etc/config/windows: build.wsf generate.wsf summary.js
Date Fri, 06 Apr 2007 20:35:27 GMT
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [] 
>> Sent: Friday, April 06, 2007 1:34 AM
>> To:
>> Subject: Re: svn commit: r525939 - in 
>> /incubator/stdcxx/trunk/etc/config/windows: build.wsf 
>> generate.wsf summary.js
>> ======================================================================
>>> ========
>>> --- incubator/stdcxx/trunk/etc/config/windows/build.wsf (original)
>>> +++ incubator/stdcxx/trunk/etc/config/windows/build.wsf Thu Apr  5 
>>> +++ 12:28:50 2007
>> [...]
>>> @@ -197,7 +212,7 @@
>>>          }   
>>>          WScript.Echo("Compiling stdlib library...\n");
>>> -        res = BuildProject(solutionBuild, 
>> "Projects\\stdlib.vcproj");
>>> +        res = BuildProject(solutionBuild, ".stdlib");
>> We should rename stdlib to stdcxx everywhere for consistency.
>   Done:
>   Also I've renamed the output library name from stdlib.[lib|dll] to
> libstd.[lib|dll] for consistency with unix names.

Great! Thanks for handling it!

>   What about the adding the compiler name to the output library name?
> For example: libstd_msvc-8.0_11s.lib for MSVC8.1,
> libstd_msvc-7.1_11s.lib for MSVC7.1,
> libstd_gcc_11s.lib for gcc (or maybe add gcc version too:
> libstd_gcc-4.1.3_11s.lib) and so on.
> That would be useful for working with more that one compiler on the same
> workstation.
> I've been working with four of them: MSVC7.1, MSVC8.0, ICC9.1,
> gcc/cygwin. And not so often
> I'm using the MSVC7.0 and ICC9.0.

FYI, we have a somewhat related request to include the name (and
version) of the compiler in config.h. See:

Implementing the config header idea in some form is necessary if
we want to continue to accommodate the existing use case of using
the same source directory tree for builds of multiple configurations
of the library. Since most compilers aren't 100% source compatible
with one another (i.e., there are minor differences that cause one
compiler to reject code that's accepted by the other) stdcxx needs
to #include a different config.h header depending on which compiler
(and which configuration) it is being used with. This can be done
by encoding the name (and version) of the compiler either in the
name of the config file or by storing it in a different directory
(i.e., by encoding the compiler and version in the pathname of
the header). The former requires stdcxx headers to somehow decide
which config.h to #include. The latter could be handled similarly
or it could be left up to the user to store config.h in a directory
separate from the config.h headers for all the other compilers and
specify the appropriate path in the -I option to the preprocessor.

On the other hand, C++ compilers that target the same platform
(most notably Linux and Windows) typically produce compatible
object code to make interoperability easy. For example, it's
possible to take an object file generated by Intel C++ and link
it with another object file generated by MSVC (or maybe even
Borland or other compilers) to produce a working program.
Similarly, it's possible to mix and match libraries produced by
these compilers, or substitute a shared library compiled with one
compiler for the same library compiled with another. Encoding the
name of a compiler in the name of a library would prevent this
substitutability, and encoding the version number of a compiler
in the name of a library would defeat the purpose of library
versioning. Users who want to install stdcxx binaries configured
with different compilers can do so by placing each in its own
directory and by specifying the appropriate paths using the -L
option to the linker. The stdcxx sources or infrastructure don't
need to change in order to make this possible.


View raw message