Sign in to follow this  

Compiling Boost with STLPort under VC8?

This topic is 3724 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Has anyone compiled the Boost libraries under VC8 using STLPort (5.1.3 for me) as the stdlib? I know Boost 1.33 had support for STLPort under the VC7.1 compiler, but it doesn't specifically have a VC8+STLPort setting, and Boost 1.34 doesn't mention STLPort at all (I've read in the Boost mailing lists where people were doing it, but they were compiling with bjam parameters that I haven't seen documented anywhere). I'm using STLPort in my current project, so I'd really like Boost to do the same for consistency. Why would there be no documentation on this? Boost 1.33 had better build instructions than 1.34 did. Any ideas on how to go about getting this setup?

Share this post


Link to post
Share on other sites
It does seem like it, yes. There's little reason I can think of to use STLPort over VC8's native STL, so the intersection of people who use all of Boost, VC8, and STLPort would be rather small.

Share this post


Link to post
Share on other sites
Really? VC8's STL is that good? I'm migrating from VC7.1, and I know it had several STL shortcomings (i.e. unimplemented standard functions). The other reason for using STLPort was to have a common STL implementation across all platforms, since my project is cross-platform.

Does this mean that STLPort is now rather antiquated for VC8 users? Are there any known issues with VC8's STL (like the dreaded "safe" libraries) that could make cross-platform development difficult?

After convincing myself in the past that STLPort was the safest way to go, I'm hesitant to just drop it again without knowing what I'm getting myself into...

Share this post


Link to post
Share on other sites
Which unimplemented standard functions were those? I'm pretty sure that VC7.1's STL was complete, and VC7's as well (though it's been longer), in stark contrast to VC6's.... thing. In any case, yeah, it's a good implementation... standards-compliant enough that it'll interoperate fine with code written for a standards-compliant standard library, and as efficient as any standard library as long as the checked iterator stuff isn't turned on.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Which unimplemented standard functions were those? I'm pretty sure that VC7.1's STL was complete, and VC7's as well (though it's been longer), in stark contrast to VC6's.... thing. In any case, yeah, it's a good implementation... standards-compliant enough that it'll interoperate fine with code written for a standards-compliant standard library, and as efficient as any standard library as long as the checked iterator stuff isn't turned on.


std::uncaught_exception was there, but not implemented until 8.0, but that's the only thing I can come up with off the top of my head.

Here's the 7.1 MSDN Help on uncaught_exception - "As can be seen in the Visual C++ source file, uncaught.cpp, uncaught_exception always returns false even in cases where the standard specifies that it should return true.

See Knowledge Base article Q242192 for more information."

Share this post


Link to post
Share on other sites
Huh. You learn something new every day. Of course, STLPort would have no way of implementing uncaught_exception.

Share this post


Link to post
Share on other sites
I guess I was thinking of functions like vsnprintf(), which in VC7.1 only exist as _vsnprintf(). If I remember correctly there are quite a number of library functions renamed like that. Ultimately not a big issue in itself, but it leaves the impression of being less complete or compliant than STLPort.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nairou
I guess I was thinking of functions like vsnprintf(), which in VC7.1 only exist as _vsnprintf().

vsnprintf() is there. You just have to #define _CRT_SECURE_NO_WARNINGS if you don't want the spurious warnings.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Quote:
Original post by Nairou
I guess I was thinking of functions like vsnprintf(), which in VC7.1 only exist as _vsnprintf().

vsnprintf() is there. You just have to #define _CRT_SECURE_NO_WARNINGS if you don't want the spurious warnings.


It's not really a spurious warning...

Share this post


Link to post
Share on other sites
Alright, that is good to know, I guess VC8 is a big improvement then. :) I guess I'll just stick with VC8 without STLPort and see how it goes then. Thanks for all of the feedback on this!

Share this post


Link to post
Share on other sites
Quote:
Original post by Washu
It's not really a spurious warning...

The hell it isn't. vsnprintf() is not a security risk if properly used. If I try to use DeleteFile(), should I get a warning telling me to make sure not to delete anything important?

Share this post


Link to post
Share on other sites
hi --

it's funny you ask about this, i've just been experimenting with it.
i was able to get boost 1.34 to compile against STLPort 5.1.3
i was using visual studio 2005.

the reason i was experimenting with it is because of this page which indicates that STLPort containers are faster than visual studios, and i use a lot of containers. i don't personally have any numbers to report, though :)


http://garrys-brain.blogspot.com/2007/01/development-stlport-versus-microsoft.html


anyways, i had the same experience you did -- there's almost no documentation, and some of the documentation that does exist is wrong.

here are the issues and solutions.

1) the version of stlport.jam that comes with boost 1.34.0 is bad, in that it will generate bad library names. what i ended up doing was making stlport.jam in boost look like this version from a nice man (David Deakins) on the internet:
http://lists.boost.org/boost-build/2007/08/17123.php

what i did was cut and paste the section of that post that has the full text of the stlport.jam file; avoid the section that is the patch.

he filed this bug with boost about the issues, but i'm not sure if it is resolved yet.
http://svn.boost.org/trac/boost/ticket/1177

2) you have to tell boost about stlport

in the user-config.jam, there needs to be a line telling boost about sltport.
i think it ends up something like


using stlport : 5.1.3 : c:/STLPort-5.1.3/stlport c:/STLPort-5.1.3/lib ;

clearly, adjust those paths as you need to.
and i think you can omit the first version number, but i'm not sure.

off the top of my head, i can't remember where the user-config.jam file is, but i bet you can find it on your disk :)

3) don't use the msvc-stlport toolset.

although that seems like a reasonable thing to do, don't do it; it will generate library files again with the wrong names. basically, this is the command you need:

bjam --toolset=msvc-8.0 stdlib=stlport stage

or something very similar... but that required that you have set up the "using stlport" settings above.


i guess you might not be interested in trying this anymore, and i'm not sure if all of these steps are exactly right, or if i'm still missing something. however, maybe it will help you out.

thanks,
ryan.

Share this post


Link to post
Share on other sites

This topic is 3724 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this