[MSVC] implement autolinking feature

• Key: STDCXX-675
• Type: Improvement
• Status: Open
• Priority: Trivial
• Assignee: Unassigned
• Reporter: Farid Zaripov
• Component/s: Configuration
• Affects Version/s: 4.1.2, 4.1.3, 4.1.4, 4.2.0
• Fix Version/s: 4.3.0

Description

At the moment the users of the library should explicitly specify the used library name in linker command line. Here might be problems if the user's project was compiled with config.h for some configuration (let's say 12d) but linked with library for another configuration (i.e. libstd12s.lib).

The MSVC and ICC/Windows has the posibility to specify the library using #pragma comment (lib, libname) directive. So #including any header from the library will leads to linking automatically with the proper library file.

Comments

[Farid Zaripov]

Perhaps the another compilers may has the similar feature.

[Martin Sebor]

I don't know of any UNIX compiler that has a feature like this.

It seems like it might be worth looking into at least on Windows.

[Farid Zaripov]

ChangeLog:

STDCXX-675

• include/rw/_autolink.h: New header file to enable autolinking feature.
• include/rw/_config-msvcrt.h: #include _autolink.h.
• src/export.cpp: Added missing #define _RWSTD_LIB_SRC macro.

The _autolink.h file is intended to be #included in _config.h, but since this feature is supported by only MSVC and ICC/Windows, it #included in _config-msvcrt.h.

[Martin Sebor]

Is this change forward compatible?

[Farid Zaripov]

Yes. This change doesn't affect the exported symbols or anything else. It's only add's the record in object files, compiled with using this change, to link these object files with libstdxx.lib.

[Travis Vitek]

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.

Will this ever be useful for any compiler other than MSVC and ICC/Windows? Is there a way that we can ensure the user links the right library on all platforms? This wouldn't avoid the need to explicitly link the library, but it would eliminate issues with linking the wrong library.

[Farid Zaripov]

This issue is potentially forward incompatible. Since the priority of this issue is low, deferring to 4.3 release.

[Travis Vitek]

There is also the issue that we don't always know what the name of the library is going to be. The user may select a different name for the library (by changing the project file or possibly renaming the file directly). If this happens, then the autolink will cause the linker to look for a library file with the wrong name. In order to get it working again, they would need to #define _RWSTD_NO_EXT_AUTOLINK or modify _autolink.h. The problem is that they may spend hours trying to figure out where the reference to the library is coming from.

What real utility does this provide? The user still needs to set the library path so that the given library is found. Perhaps a better idea would be to add a blurb to the documentation telling the user about the option to use the #pragma in their code?

[Farid Zaripov]

The STLport and boost both are using this feature. This feature is useful when you make the library files for all build modes in the same directory (like STLport and boost does). Then you have to specify this path to the linker and linker itself select the proper library file.

Of course when you have library files for different build modes in their distinct directories and you have to specify the path of the concrete library for some build mode this feature is looking as redundant.

[Travis Vitek]

I agree. I don't see this as useful for our users.

If we are really worried about them using libraries and headers from different configurations, we could generate a symbol name based on the configuration. The library would export the symbol and one of the library headers would import it. That way the executable won't link if the library and headers are from different configurations.