Friday 11 May 2007

STLport for Symbian OS released!



STLport for Symbian OS has been updated! A pre-release of version 5.1.5 (source code only) is available here.


I'm happy to announce the first full-featured release of STLport for Symbian OS 9.x!

STLport is a high-quality implementation of the C++ Standard Template Library (STL), a library that is part of the ISO/IEC C++ Standard and that is not included natively in the Symbian OS platform. By supporting the STL, Symbian applications can benefit from a wide range of existing C++ code that can now be ported easily.

This version of STLport should work on all Symbian OS 9.x devices, both S60 and UIQ variants. The library has been succesfully compiled with (and binaries are provided for) following platform SDKs:

  • S60 3rd Edition 1.1 (Maintenance Release)
  • S60 3rd Edition Feature Pack 1
  • UIQ 3.0

The only dependency is a conforming Standard C library, that is provided by either the P.I.P.S. library (available for both S60 and UIQ devices) or Nokia's Open C plugin (S60 only).

All features of STLport have been ported, although locales other than the default "C" locale are not yet implemented. This will be done in next releases. All unit tests have passed on both the emulator and a wide range of devices, while only one test in the exception handling testsuite is still failing. More details are available in documentation files that come with the downloadable package.

So, now the interesting part. If you are using one of the aforementioned SDKs and you don't need to change any of the STLport configuration options, then you can download the prebuilt package that includes header files and binaries for a specific SDK:

Download prebuilt package for S60 3rd Edition 1.1 Maintenance Release SDK


Download prebuilt package for S60 3rd Edition Feature Pack 1 SDK


Download prebuilt package for UIQ 3.0 SDK


Download the README file that contains installation instructions


Please note that binaries for S60 were compiled against the OpenC library, while those for UIQ were compiled against the P.I.P.S. library. If you want to compile the library for another SDK or if you want to change the build configuration, you need the full source code so that you can recompile STLport from scratch:

Download full source code


The source code package also contains the necessary files for building an installable SIS package containing the STLport test suite.

If you have any questions or suggestions, please let me know. I can be contacted on the Forum Nokia's discussion forum, my nickname is "polo78".

Enjoy!

62 comments:

krishna said...

I must be really stupid to ask this question, But i will ask (i dont want to keep that with me).

But, How will STL for Symbian will help programmers (i mean are there any particular set of problems whose solutions become more simpler is STL is used) ?

Marco said...

@krishna: the STL is a standard library. Being part of the C++ Standard itself, it is widely used in C++ applications, especially in those applications that aim to be cross-platform and that don't use any specific C++ dialect or platform-dependent library. The main advantages of the STL are: platform independence, robustness, good programming paradigms (such as the separation between containers, iterators and algorithms), genericity (most components work on any existing and new data types without requiring run-time polymorphism). Efficiency is also important, because the C++ language is perhaps the only one that gives the compiler a lot of power so that many tasks that would usually be executed at run time can actually be resolved at compile time. The STL library enforces this behaviour.
That said, most cross-platform C++ applications out there (especially non-GUI apps) are based on the STL, and thanks to STLport for Symbian they can now be ported without huge efforts.

svdwal said...

Hi

There appears to be a minor error in the stlport\stl\config\stl_gcce.h file. This file starts with a guard

#ifndef _STLP_WINSCW_H
#define _STLP_WINSCW_H

#define _STLP_COMPILER "GCCE"

that is the same as for the stl_winscw.h file. I think this should be changed to

#ifndef _STLP_GCCE_H
#define _STLP_GCCE_H

#define _STLP_COMPILER "GCCE"

etc

Sander van der Wal
www.mBrainSoftware.com

Marco said...

@svdwal: oops thank you, it's now fixed in my development tree (will appear in next release). The reason why I didn't notice it before is that only one of the two header files is actually used during the build process, so the collision never takes place.

Unknown said...

I´m wondering if this port to Symbian is going to be part of the STLPort official branch or do you want to mantain it as a separate branch.

Marco said...

@Carlos: I'm keeping it separate for now. The main reasons are: (1) the Symbian build system is a whole different world than ordinary makefile-based systems like that used by STLport; (2) I'm not yet very confident with the STLport internals, and I fear that integrating this variant into the main development tree would possibly break existing code on other platforms. However, this is something I'll take into consideration in future releases.

BANUDK said...

I think its excellent work.I work in Nokia as Product Manager for Open C .There is going to be Open C challange organised by Nokia please participate in it with this project .Contact me at banudk@gmail.com for further details .I would also be intrested in getting feedback from you on Open C .

Unknown said...

OH! MY! GOODNESS! - I cant believe it! I am amazed at what i am reading. The Standard Template Library ready to rock and roll on Symbian OS! Congratulations. You deserve a pat on the back. I have just been issued with a new work phone which is a Nokia N95. It uses Symbian OS 9.2 with S60 3rd Edition Feature Pack! Ive never done any Symbian programming but the first thing i am going to do is install Carbide and have a play.. This truly is a wonderful achivement.

Flippy!

Unknown said...

Hey there. Me again! - I successfully got everything working yesterday but std::ostringstream does not seem to work..

when simply add to my sample code:

std::ostringstream strm;

i compile i get a lot of "undefined reference" in the output window. just wondered if you knew abou this?

Marco said...

@flippy: did you follow all instructions correctly? are you linking against the static library stlport_s.lib?

Unknown said...

Hello there Marco.. There is a very high probability that i am not doing something right. Yes, i am statically linking to stlport_s.lib. I have just re-read your readme.txt and notice it says that i may need to link to some native Symbian libraries like efsrv.lib. I am not doing this so will try adding this to the .mnp file

Unknown said...

okay, you can ignore me.. Adding efsrv.lib fixed my problem. :)

thanks again for this port. Keep up the good work.

余昕 said...

Can you teach me how to run the test program on N95 ? I just copy it in mem-card but cannot run...

thank you...

Marco said...

@941: just install the SIS file as you would do with any other application. A new icon should then appear in your applications' menu.

Unknown said...

Hi,

When trying to compile for the device using GCCE, I get an error regarding missing the stlport_s.dso file. How can I get it?

Thanks!

Marco said...

@lior: .dso files are "import libraries" for DLLs. stlport_s is a static library, not a DLL, so there is no stlport_s.dso file, and no such file is required to build applications that use STLport. It's quite surprising that your build chain is requiring it. Did you follow the documentation closely? In particular, make sure you are linking to stlport_s.lib as a *static* library and not as a *dynamic* library.

jezzy said...

Hey Marco. Thanks for your great job.

I'm currently using stlport with open-c for S60 3rd edition MR. I'm working with carbide.vs and the WINSCW emulator.

When including sstream file and using std::ostringstream, i'm getting an (and only one) "undefined symbol" error when linking... The undefined symbol is "__insert_grouping" referenced from class std::ostreambuf_iterator

Got no problem with the other includes.....

Adding efsrv.lib doesn't fix this issue.....

Any idea? Am I missing something?

Marco said...

@jezzy: I'm afraid I don't know Carbide.vs, so I can't comment on it. Perhaps there is something strange going on with its build chain. For example, Carbide.c++ 1.1 has bugs that prevent STLport-based applications from building correctly, whereas Carbide.c++ 1.2 works fine. I wrote STLport configuration headers so that they could work with the build environments I currently use, that is command-line build tools and the Carbide.c++ Express IDE.
I don't own VS.NET 2003 so I can't test Carbide.vs. The best advice I can give you is to try to compile your application with Carbide.c++ Express 1.2 and see if there is any difference.

jezzy said...

Ok Marco, thanks for the reply!

Using Carbide c++ 1.2 express solves the point. I will take a little time to find why.....

thanks again....

Unknown said...

Marco said "Carbide.c++ 1.1 has bugs that prevent STLport-based applications from building correctly"

Could you give an explanation of this. I didn't see anything in the documentation, plus i'm using 1.1 and so far it appears to work. There are some workarounds i've ran into (related to size_t for gcce builds, and usrt2_2.lib for gcce builds) but it builds and runs.

ts said...

Works like a charm for now! Can't wait to drive this a little more. Thanks a lot for this!

Marco said...

@tim: using Carbide 1.1 resulted in linker errors even with a simple test program based on fstream, string and stringstream. I don't remember exactly what the error was, I simply installed Carbide.c++ 1.2 and it worked without further changes. Good to hear you don't have the same problems!

Unknown said...

Marco: i'm using string (actually wstring) and wstringstream. no fstream ,and so far i haven't ran into problems. If you said simple app for 1.1 i could take a look and see what i have configured differently if anything?

Cheers

Marco said...

@Tim: I'm afraid I no longer have the test program that was failing, but you can recreate the same conditions easily: just create a new S60 project from the Carbide.c++ wizard and replace all filesystem-related code (RFs, RFile, etc.) with STL counterparts.

gramic said...

When using file streams i noticed that the file name can be only CHAR and not Wchar. Is there a reason for that and how this can be changed?

The problem is that i have code that uses files with a path that includes non ascii characters.

Thanks in advance!

Marco said...

@gramic: AFAIK the C++ STL (not only STLport) doesn't support wide-char filenames in std::fstream and companions. I don't know whether there are any technical reasons behind the choice of not supporting them. Maybe the C++ Standards Committee simply didn't consider them useful enough... However you can direct this question to the STLport team, they probably have a better answer.

Channamallesh said...

Hi
I am building my application got GCCE phone release. My application uses stlport_s.lib . I am getting the errors while building like :

"\stlport_s.lib\(locale_impl.o): undefined reference to `wmemcpy' "

The application works perfectly fien on the emulator. Is there any way out from this error ?

Thanks
Rashmi

Vitor Medina Cruz said...

Hello,

There seams to be a problem using wofstream and wclog. I got KERNEL-EXEC 0 every time i try to use it.

[]s,
Vitor.

Pascal said...

Hi!

I am using very successfully the STLport with S60 3RD MR. The only problem I have is that C++ streams are not working if I use them in a dll. In a exe the following code works fine, but if a use them in a dll which a link in a exe the application works fine in the emulator, but not on any device. The application doesn't start up and exits with a "KERN-EXEC 3". If i remove all " << " and " >> " 's all works fine:

[CODE]
std::cout << "Hello world" << endl;
[/CODE]

Thanx a lot for your help!

Pascal

Marco said...

@everyone: I apologize for not being able to reply to your latest comments, but I've been very busy in the last months. Now I'm about to take 1 week off (at last!); when I come back I'll do some testing and I'll try to answer to all your questions. Thanks for your patience!

Ed Welch said...
This comment has been removed by the author.
Ed Welch said...

Hi Marco,
I downloaded the prebuilt package for S60 3rd Edition 1.1.
I get the following error when I include the string header file:
1>C:\Symbian\9.1\S60_3rd_MR\epoc32\include\stlport\stl\_cmath.h(417) : error: undefined identifier 'fabsf'
(included from:
1> expanding macro '_STLP_MATH_INLINE'
1> expanding macro '_STLP_DEF_MATH_INLINE'
1> C:\Symbian\9.1\S60_3rd_MR\epoc32\include\stlport\stl\_cstdlib.h:162
1> C:\Symbian\9.1\S60_3rd_MR\epoc32\include\stlport\stl\_alloc.h:39
1> C:\Symbian\9.1\S60_3rd_MR\epoc32\include\stlport\stl\_string.h:23
1> C:\Symbian\9.1\S60_3rd_MR\epoc32\include\stlport\stl\_string_hash.h:27
1> C:\Symbian\9.1\S60_3rd_MR\epoc32\include\stlport\string:35
1> C:\workspace\SymbianTest\SymbianTest\src\SymbianTestappview.cpp:14)


I have the following setup:
s60 3rd edition sdk mr
VS.NET 2005
Carbide.vs 3
open c
and I have the include directories setup:
$(EPOCROOT)\epoc32\include\stdapis;$(EPOCROOT)\epoc32\include\stlport;
any help would be greatly appeciated

Pascal said...

Try to include

#include <cmath>

or

#include "math.h"

Ed Welch said...

Thanks for the quick answer pas.
including cmath caused a whole load of extra errors:

1>C:\Symbian\9.1\S60_3rd_MR\epoc32\include\stlport\stl\_cmath.h(417) : error: undefined identifier 'fabsf'
1>C:\Symbian\9.1\S60_3rd_MR\epoc32\include\stlport\stl\_cmath.h(422) : error: undefined identifier 'acosf'
1>C:\Symbian\9.1\S60_3rd_MR\epoc32\include\stlport\stl\_cmath.h(423) : error: undefined identifier 'asinf'
1>C:\Symbian\9.1\S60_3rd_MR\epoc32\include\stlport\stl\_cmath.h(424) : error: undefined identifier 'atanf'
...

including "math.h" doesn't make any difference.

Marco said...

Hi Ed,
try to invert the order in which Open C and STLPort paths are searched. That is, place "$(EPOCROOT)\epoc32\include\stlport" before "$(EPOCROOT)\epoc32\include\stdapis".
Also, notice I've never tested STLport with latest version of Open C.

Ed Welch said...

No, makes no difference the order of the includes. Oh well, thanks for the answer anyways

pailes said...

Hi Marco, thanks for your great work,. I've successfully compiled your STLport branch while trying to port a rather large STL based framework to Symbian. Unfortunately the framework is also using RTTI and this is were I'm stuck right now. Do you have information on using std::type_info in Symbian projects? I wonder if if even works with both CW and GCC compilers. I can only find very few information on RTTI.

Regards

Marco said...

@pailes: yes, there is an update that allows you to use std::type_info, but I'm not sure I can make it public for a couple of reasons. Email me privately if you're interested: marco.jez[AT]gmail.com

HamishW said...

Hi
Looks great. Do you have mak files to allow this to be built using RVCT?

Marco said...

@HamishW: I'm afraid, RVCT is not supported.

pailes said...

Hi marco, while investigeting your port a little bit further, I noticed that the double to string conversion in _symbian_ecvt does not work correctly. Try to convert 3.1415f to a string and see what the result is. I'll be posting a fix when I'm done. Cheers

Marco said...

@pailes: thanks for spotting this, I've identified the bug and I'm now fixing it. The fix will be available in next release (based on STLport 5.1.5) which is coming soon (I'm working on it).

pailes said...

Sorry for my late reply, I've been sick for the past few days. I also fixed your conversion routine with some code I've found in the net, I've sent you an email with the fix, maybe you find it useful. Regards.

vendelin said...

Hi!

I installed stlport, and I get a weird error: call of overloaded `log(const TInt&)' is ambiguous
..//..//9.1//S60_3rd_MR_2//EPOC32//include/stdapis/math.h:279: note: candidates are: double log(double)
..//..//9.1//S60_3rd_MR_2//EPOC32//include//stlport/stl/_cmath.h:435: note: float log(float)

My mmp file includes:
USERINCLUDE ..\inc
SYSTEMINCLUDE \epoc32\include\stlport
SYSTEMINCLUDE \epoc32\include
SYSTEMINCLUDE \epoc32\include\stdapis

Maybe I installed stlport badly?

vendelin said...

I forgot the details:

I use Carbide c++ under Win xp
and tried STLport-5.1.5-symbian-r1-RC version.

Thx

Marco said...

@Bodi: can you please show me the line of code that is causing the error? Also, if you are using STL functions, make sure you prefix them with the std:: namespace.

Unknown said...

Hi marco,
Thanks for stlport. It is a lifesaver for many like me. I have one doubt which plugin is better pips or open c. I have recently started using c++ and am new to symbian development. and do you know any sites where i can find examples of using stlport in symbian c++.

cheers....

Ed Welch said...

Does stlport handle out of memory conditions?
I did a test using this code:

vector |int| list;
try
{
int n = list.max_size();
list.resize(n/2);
}
catch (...)
{
return false;
}

Normal stl implementions would throw a bad_alloc exception, but stlport just seems to crash and the catch clause never gets called.
I am using the version of stlport from the open c++ plugin.

pailes said...

The new operator from Symbian does not throw anything. You need to download the new version of this port which has been released a few weeks ago. It should deal with this case correctly.

Apoorva said...

Hi

I'm using carbide.c++ 1.3, UIQ3.1SDK, PIPS9.2. After installing the stlport, i have included path to stlport and stdapis as stated in the readme.txt. When i included the usage to std::string i get the following errors:
mwldsym2.exe: Undefined symbol: 'void * std::__malloc_alloc::allocate(unsigned int &) (?allocate@__malloc_alloc@std@@SAPAXAAI@Z)'
mwldsym2.exe: referenced from 'char * std::allocator char ::allocate(unsigned int, unsigned int &) (?allocate@?$allocator@D@std@@QAEPADIAAI@Z)' in _alloc.h:432
mwldsym2.exe: Undefined symbol: 'void std::__stl_throw_length_error(char const *) (?__stl_throw_length_error@std@@YAXPBD@Z)'
mwldsym2.exe: referenced from 'void stlp_priv::_String_base char, class std::allocator char >::_M_throw_length_error(void) const (?_M_throw_length_error@?$_String_base@DV?$allocator@D@std@@@stlp_priv@@IBEXXZ)' in _string.c:613

Can you tell me what is going wrong?

Marco said...

@Apoorva: any chance you forgot to add stlport_s.lib to the list of static libraries used by your project?

Apoorva said...

when i added stlport_s.lib it started working.

Apoorva said...

STL port on top of winscw is working fine. When i try to get a armcc build (RVCT2.2), i get the following errors:
Fatal error: L6024U: Library stlport_s.lib contains an invalid member name.
Not enough information to list image symbols.

Any inputs to resolve this issue?

Marco said...

@apoorva: as stated in the documentation, only WINSCW and GCCE targets are supported. I work on STLport for Symbian OS in my spare time and with my own resources, so I'm not going to support a commercial product unless someone buys a license for me.

Nate said...
This comment has been removed by the author.
Nate said...

Hi Marco,

I downloaded the prebuilt package for S60 3rd Edition 1.1 and I get the following errors:
'box.cpp: undefined reference to 'fabsf'
'box.cpp: undefined reference to 'sqrtf'
'box.cpp: undefined reference to 'atan2f'
'box.cpp: undefined reference to 'sqrtf'
and so on for any math function I can think of.

I have the following setup:
s60 3rd edition sdk
Carbide.c++ 1.3
Open c
I have the include directories:
$(EPOCROOT)\epoc32\include\stlport
$(EPOCROOT)\epoc32\include\stdapis

I'm pretty sure it has to do with the math of libc, which I removed after it gave me problems (for example: http://developer.symbian.com/forum/thread.jspa?messageID=73654)

I'd be greatful if you could save me please :)

Nate

Marco said...

@nate: those functions are defined in Open C's standard C library (libc.lib), which is a dependency for STLport. If you remove libc from the list of libraries to link against, you'll probably fail to build any code based on STLport. Why did you remove libc.lib from the MMP? The web link you posted actually refers to someone getting linker warnings, not errors.

Nate said...

Thanks Marco for your reply.
I still link against libc.lib, I meant I removed the
SYSTEMINCLUDE \epoc32\include\libc.
Perhaps I shouldn't remove it, but when I do include
SYSTEMINCLUDE \epoc32\include\libc in my mmp, I get a bunch of other errors, as in:
http://discussion.forum.nokia.com/forum/showthread.php?t=137500.

Marco said...

@Nate: it's ok to remove that include path, as it belongs to the old C library. I supposed your errors were linker errors, but I see they are emitted by a file named "box.cpp", so they must be compiler errors (please correct me if I'm wrong). If you are explicitly calling those math functions from within your own code, make sure to include <cmath> and to qualify function names with prefix std:: (for example, std::fabsf, std::cosf, etc.). You can also include the C-style <math.h> header and avoid namespace qualification altogether, but it's not recommended. If, instead, those functions are being called from some extraneous code (or from STLport itself), then we must figure out what's going wrong and where. In this case, sending me a simple test case that reproduces the problem would be useful.

Nate said...

Hey Marco.

math.h was already included and compilation was going fine. These were linking errors. Turns out I didn't link against OpenC's libm.lib when using vector.
It finally works and I am greatful to you for your library and kind help. You save poor programmers' lives every day :). I wish you all the best.

Nate.

Unknown said...

@macro & @nate
hi,
i'm getting the same compile time errors:

undefined symbols for the math functions (fabs and its likes) in _cmath and undefined "rename" and "remove" in _cwchar

(my rig is carbide.c++ 2.0 and nokia s60 3.1 sdk),
i didn't originally have an epoc32/include/stdapis/ directory ( i do have the epoc32/include/clib, which is also in my system include path )

it seems stlport does not include the math.h on its own accord.

any config settings that could help with this?

thanks!

Lalit said...

Adding libstdcpp.lib solved the problem. "Undefined symbol: 'void std::__stl_throw_length_error(char const *) (?__stl_throw_length_error@std@@YAXPBD@Z)'"