STLPort 5.0 and multiple VC versions

| 2 Comments
I'm in the process of testing some of my code with Visual Stuio 2005 and the first thing I found that I needed to do was to upgrade my STLPort installation from 4.6.2 to 5.0.0 to get a version that built with VC8. Given that I like to test one change at a time I first upgraded my VC6 build to use STLPort 5; STLPort built fine with VC6 and all my tests passed. The next step was to build STLPort with VC8, build my code with VC8 and run the tests. Unfortunately this is where the latest version of STLPort falls down compared to previous versions.

In the latest version of STLPort some bright spark (with a unix background) has decided to 'rationalise' the naming of the output libraries so that they're called the same thing on all platforms. This is, probably, a noble cause but unfortuantely it means that they decided to remove the compiler name from the library name. Previously you'd end up with names like stlport_vc646.dll; note the vc6 in there... Now, you end up with stlport.5.0.dll which is slightly prettier but useless if you want to have a single STLPort installation for multiple installed versions of Visual C++. Various reasons may mean that the libraries are not link compatible between compiler versions. VC uses a typedef to create a wchar_t whereas VC7, VC7.1 and VC8 allow it to be a real type and VC8 defaults to this new behaviour; this affects name mangling and this prevents linkage between VC8 and VC6 compiled code (unless you disable the real wchar_t in VC8 and I don't want to do that...).

You can use the configure script to set the build system up for building "cross compiled versions" using -x but this just puts the output in separate directories so that you can build multiple versions on one machine, this doesn't help me.

The fix is relatively easy, you need to edit Makefile.inc and change this line:

LIBNAME = stlport

to this:

LIBNAME = stlport_$(COMPILER_NAME)

That change builds the library with the compiler name included in the output name. Next you need to change the header file that generates the #pragma that auto links the library for you. Edit stl_msvc.h and find this line:

#  define _STLP_STLPORT_LIB "stlport"_STLP_LIB_OPTIM_MODE""_STLP_LIB_TYPE"."_STLP_VERSION_STR".lib"
and change it to

// Start LFH
// Put back the useful, working code from pre 5.0.0 that allows coexistance of multiple VC version builds of
// STLPort, and add a case for VC8

# ifdef __ICL # define _STLP_LIB_BASENAME "stlport_icl" # else # if (_MSC_VER >= 1400) # define _STLP_LIB_BASENAME "stlport_vc8" # elif (_MSC_VER >= 1310) # define _STLP_LIB_BASENAME "stlport_vc71" # elif (_MSC_VER >= 1300) # define _STLP_LIB_BASENAME "stlport_vc70" # elif (_MSC_VER >= 1200) //# ifdef _UNICODE //# define _STLP_LIB_BASENAME "stlport_vc6_unicode" //# else # define _STLP_LIB_BASENAME "stlport_vc6" //# endif # elif (_MSC_VER >= 1100) //# ifdef _UNICODE //# define _STLP_LIB_BASENAME "stlport_vc5_unicode" //# else # define _STLP_LIB_BASENAME "stlport_vc5" //# endif # endif /* (_MSC_VER >= 1200) */ # endif /* __ICL */ // end LFH # define _STLP_STLPORT_LIB _STLP_LIB_BASENAME""_STLP_LIB_OPTIM_MODE""_STLP_LIB_TYPE"."_STLP_VERSION_STR".lib"

There's probably a better way to do this, but this works for me, it might work for you.

The changed files are here (mainly as a convenience for me for when I happen to reinstall and get all confused...)

STLport-5.0.0\build\lib\Makefile.inc

STLport-5.0.0\stlport\config\stl_msvc.h

2 Comments

Hi Len,

have u experienced pseudo memory leaks with stlport 5.0 when used with vc 6.0? have u used _STLP_USE_NEWALLOC and _STLP_LEAKS_PEDANTIC in order to avoid them. is performance reduced if we don't use node allocation optimization by introducing mentioned macros?

(http://stlport.sourceforge.net/FAQ.shtml#leaks)

regards.

Alek

Yes, well, actually I've experienced them with releases prior to 5.0, as well. Since they tend to be fairly obvious once you get used to them and since most of the memory leak checking tools that I've used over the years have had this problem with pooled memory I tend to just tell the tools to ignore the pseudo leaks once I'm sure that's what they are - or just ignore them myself.

I would expect that performance is reduced if you change the default STLPort allocator behaviour, but I haven't checked it. You could, of course, create a build that includes the memory checking friendly allocation strategy and adjust the library naming of the STLPort libs by adjusting the macros that I use to name the libs by compiler. This would let you have the various versions of STLPort co-exist and would allow you to have a new build configuration (Debug Mem Check, perhaps) that you can build when running the memory check tools so that the perf hit doesn't affect your normal debug/release build...

Leave a comment

About this Entry

Panto season! was the previous entry in this blog.

Pluggable exception handling is the next entry in this blog.

I usually write about C++ development on Windows platforms, but I often ramble on about other less technical stuff...

Find recent content on the main index or look in the archives to find all content.

I have other blogs...

Subscribe to feed The Server Framework - high performance server development
Subscribe to feed Lock Explorer - deadlock detection and multi-threaded performance tools
Subscribe to feed l'Hexapod - embedded electronics and robotics
Subscribe to feed MegèveSki - skiing