Wednesday 23 April 2008

Pre-release of STLport 5.1.5 for Symbian OS available for testing

The new version of STLport for Symbian OS is here! Actually this is just a pre-release that I'm making available for testing, and it's only distributed as source code. If you don't feel like compiling STLport by yourself (even though it's really simple and painless), then you'll have to wait for the official release.
I want to thank everyone who has helped me put together this pre-release by reporting anomalies, fixing bugs or simply leaving comments on this blog. But I still need your help! Please download this source package and test it against your existing code, and report any problems you may have with it.

Download
Get the source package at http://www.webalice.it/marco.jez/files/STLport-5.1.5-symbian-r1-RC.zip.

Platform compatibility
STLport can be used with all non-beta S60 and UIQ SDKs available at time of writing. Beta SDKs may work but I haven't tested them. Please note that I still have to test the library on non-Nokia devices.

Important notes

  • The prerequisites have changed. Please read the INSTALL.txt file located in the ./symbian subdirectory. In a nutshell, this release requires PIPS 1.2 (or Open C MR) and Carbide.c++ 1.3. Older versions may or may not work, but they aren't officially supported. Previous versions of PIPS/Open C have bugs that also affect STLport, so you better stay away from them.
  • STLport headers are now automatically installed into your SDK's epoc32/include directory. In order to use STLport from your applications, the directory to be added to the header search path is now /epoc32/include/stlport. The library name remains stlport_s.lib as in previous release.
  • There is an experimental Python script that automatically builds all configurations of STLport for every SDK that is installed on your system. See INSTALL.txt for details.

Changes

  • updated to STLport 5.1.5
  • added support for UIQ 3.1 and S60 3rd Edition FP2
  • fixed bug in _symbian_ecvt() which affected rendering of numerical values (thanks Peter Barth)
  • fixed bug that affected the reference counting mechanism of the RFs instance in _fstream.cpp (thanks Peter Barth)
  • improved project files and build scripts for easier installation
  • forced null-pointer check after every allocation through operator new, because Symbian's operator new never throws std::bad_alloc
  • minor cleanup to remove some annoying warning messages
  • RTTI (std::type_info) is supported

Feedback is greatly appreciated!

4 comments:

Guru meditation said...

Hi there, and thank you for everything !

My question isn't specific to the new release, but I think it's still relevant.

The last I checked the PIPS library .sis is 463 kB. This is way too much for some purposes.

I'm wondering if it would be possible to cut down that size. What are the real dependencies there for STLport, and how could I cut down the size of the PIPS library ?

It is possible that this will take care of the problem in the future:
"It is expected that the P.I.P.S. libraries will be included in ROM on certain smartphones based on Symbian OS v9.3 and later."
Ref:
[Symbian] PIPS Essential booklet.

But in the meantime, can you give me any pointers towards making the dependencies less heavy ?

Marco said...

STLport depends on the standard C library (such as PIPS) heavily, I don't think it's even possible to remove this dependency. I'm afraid, you can't have STLport without PIPS. You can still do some experiments though... Try building STLport without having installed PIPS first, and see if at least some parts compile cleanly. As for STLport itself, you can drastically cut down your application's binary size by not using i/o streams (sstream, fstream, iostream, etc.). If you don't use them, you don't even need to link against stlport_s.lib, as almost all other STL components are purely header-based (they are templates). Anyway, I can confirm that newer devices based on S60 3rd FP2 have PIPS pre-installed in ROM.

Guru meditation said...

It might be of interest to some parties that Penrillian/uSTL does not have the kinds of library dependencies discussed above. It might be of concern to some that at least right now they don't support RVCT, only GCCE. I didn't try whether STLport can be compiled w/RVCT, so I don't know if there's a difference in this regard or not.

Hitesh said...

How is this STLport implementation any different or better than the one we get from the Open C++ plugin from Nokia?

And do you have any plans for porting boost? The Open C++ plugin doesn't support all the boost libraries, infact it supports too few of them.

Thanks.