incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: [jira] Commented: (STDCXX-675) [MSVC] implement autolinking feature
Date Thu, 20 Dec 2007 05:59:14 GMT
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Travis Vitek (JIRA) [] 
>> Sent: Wednesday, December 19, 2007 1:22 AM
>> To:
>> Subject: [jira] Commented: (STDCXX-675) [MSVC] implement 
>> autolinking feature
>>     [ 
>> ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#actio
>> n_12552933 ] 
>> Travis Vitek commented on STDCXX-675:
>> -------------------------------------
>> If the new user takes advantage of the autolinking feature, 
>> they will have to modify their build system to get it to work 
>> with a previous version of the library. i.e. they will need 
>> to explicitly link the library file when they go back to 4.2.0.
>   You're right, but what the type of incompatibility of this case? :)
> Source? - No, because there no source changes. Binary? - No again :)

I agree, it's a gray area.

The general rule of thumb I tend use for maintenance releases is that
they must be hassle-free drop-in replacements for each other. I.e., it
should be just as easy to swap in the previous release into a project
built with a maintenance release as it is in the opposite direction.
The safest way to achieve this goal is to refrain from implementing
any enhancements in maintenance releases and restrict changes to
bug fixes only. Even then, though, an argument could be made that
if a user program builds against the maintenance release and relies
on a bug fix implemented in the release they may not be able to
simply drop in a prior version and expect the program to work as

>> Will this ever be useful for any compiler other than MSVC and 
>> ICC/Windows?
>   Yes, if the autolinking feature will be implemented there :)
>> Is there a way that we can ensure the user links 
>> the right library on all platforms?
>   We can define some symbol in the library with the unique name
> for the each build type, and make the reference to this symbol
> in <config.h>. Then in case the linking with incorrect library
> the "undefined symbol reference" linker error will be issued.

It might be worth exploring this idea a bit before making a decision.
If it turns out we're not completely comfortable with the solution
for 4.2.1 there's always 4.3.


>> This wouldn't avoid the 
>> need to explicitly link the library, but it would eliminate 
>> issues with linking the wrong library.
>   Right.
> Farid.

View raw message