Closed Bug 432430 Opened 12 years ago Closed 11 years ago

[PATCH] NSPR port to Symbian OS, unit tests tested

Categories

(NSPR :: NSPR, enhancement)

4.7.1
All
Symbian
enhancement
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: me, Assigned: me)

References

Details

(Keywords: mobile)

Attachments

(8 files, 13 obsolete files)

10.88 KB, patch
Details | Diff | Splinter Review
2.34 KB, patch
Details | Diff | Splinter Review
3.19 KB, patch
Details | Diff | Splinter Review
4.22 KB, patch
Details | Diff | Splinter Review
13.05 KB, patch
Details | Diff | Splinter Review
13.70 KB, patch
blassey
: review-
Details | Diff | Splinter Review
39.12 KB, patch
nelson
: review+
Details | Diff | Splinter Review
12.13 KB, patch
nelson
: review+
Details | Diff | Splinter Review
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: 

This is my patch for NSPR. In this patch I added some files as Symbian OS project file (plays role of Makefile) and modified some .c files to make NSPR compiled for Symbian OS both emulator(x86 compiler instead of true ARM simulator) and target device (cross compile for ARM CPU on phones). At this moment those builds, both NSPR dynamic library(dll) and unit tests finished compiling with success but haven't been run for tests on both emulator and target device.

Details of new files: // all of them are placed in mozilla/nsprpub/build/symbian
bld.inf : Project file for whole NSPR, includes other single projects and tests projects.
nspr.mmp : Single project file for NSPR on Symbian OS.
plc.mmp : Single project file for PLC on Symbian OS.
ver_bld.mk : GNU Makefile used to generate _pr_bld.h and _pl_bld.h at compile time.
macro.h : Common macros used in project files.
prcpucfg.h : A cpu config file copied from _linux.cfg. Because of build tool chain can not use .cfg file as header and other macro flow control problem, I place CPU config header with this name at this place.

Those project files(bld.inf and .mmp) are used for building Symbian OS binaries, but the tool chain and development environment setup process will cost too many words to make it clear here. For your convenience of knowing Symbian OS development, I would give you two resources:

http://www.forum.nokia.com/main/resources/technologies/symbian/documentation/getting_started.html

http://wiki.forum.nokia.com/index.php/How_do_I_start_programming_for_Symbian_OS%3F

At last, I have to get you know this is my first time to submit a Mozilla patch, I use my spare time to make the building works without functionality verify in 1.5 weeks. Probably there will be many to fix, so please point out anything that will help me improving at will.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Attachment #319556 - Flags: review?
Attachment #319557 - Flags: review?
I confirm this is an enhancement request.  :)

Harry, per your request, here are some suggestions.

1) Make this bug be an NSPR bug.  IF & when you get to NSS, create a bug
for Symbian work in NSS, and make it an NSS bug.  Create an "umbrella" bug
for your project (which I gather is Fennec), and let all those other bugs
block it.  DO likewise for each piece of Mozilla code you need to touch.
This strategy will lessen the chance that your projects will be ignored by
the owners of the various modules.  If you can't change this bug's product,
let any of the NSPR module owners know, and we can do it.

2) Avoid "Monster Patches".  Your second patch, above, at 483.6KB, might just
be a new record for biggest patch.  Nobody likes to review monster patches
so Monster Patches tend to sit around for LONG periods of time (months) 
waiting for reviews.  10 smaller patches will get reviewed much faster than
1 big patch containing all 10 parts.  

A big patch gets one grade. It's all or nothing.  Even if 90% of the patch is
ready to go in, but 10% is not, the whole thing stops for that 10%.  But if
that 10% is in its own separate patch, and the other parts are in their own 
separate patches, then the parts that are ready (get positive reviews) can 
be checked in without waiting for the rest.

The worst case scenario, for a reviewer, is the monster patch that gets a 
negative review, and then a subsequent version of the patch either includes 
a different set of files than the previous version, or patches a different 
version of some file than the previous patch.  A single one of either kind 
of change means that the tools that compare patches won't work, and the 
reviewer will be faced with reviewing the entire monster patch again.
Some reviewers simply say no to requests to review monster patches subsequent 
to the first one, unless the new patch is comparable in all respects (same
exact set of files and file versions).  So, once you start developing a 
patch, don't cvs update those files again in your workarea until your patch
gets a positive review.  THEN if the patch needs to be adjusted due to 
patch collisions, those can be resolved after the main patch gets a positive
review.

Monster patches that contain only entirely new files in entirely new 
directories might be an exception to that rule.  

Regarding your two patches above, I'd suggest that you obsolete the second
patch, which is the first patch plus a large set of new files, and create a
third patch that is ONLY the new files that were added to the second patch.
That way, those two sets of patches to files can be reviewed separately.  
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → harry.li
Component: General → NSPR
Product: Fennec → NSPR
Version: 1.0 → 4.7.1
Regarding the huge boatload of project files: Is it possible to build this
code for Symbian using only gmake and a shell (the common build environment
for all unix/linux-like systems)?  I think it's safe to say that the existing
NSPR developers would far prefer it if the new port was built using the same 
basic build methods used on all the other systems.

Finally (for this comment), I can't help but wonder if this port hasn't already been done.  I'm pretty sure there's a browser based on gecko (the core of 
firefox) on Nokia's n770, n800, and n810, which (I think) are Symbian devices.
I know those products use NSPR and NSS already.  I'm CC'ing somebody who might
know.
QA Contact: general → nspr
Thanks for your fast reply Nelson :) I am working on splitting the second patch now. 
For your query, the answer is that there is a way to build it under unix/linux shell but that method is very unofficial and the result is not guaranteed. More information can be get from http://www.martin.st/symbian/ . I just don't know if this way means more painful than setting up a build environment on Windows OS, ore less. I will try to keep three build configurations(Nokia Carbide.c++ IDE build for x86 emulator, Nokia Carbide.c++ IDE build for ARM target device with GCCE compiler, Unix/Linux shell build with patched tool chain for ARM target device) IF the community has a great need. Although the first two configurations are IDE based, it is also possible to make these two run under Windows shell/command prompt, actually it means nothing compared with our goal of utilizing gmake and unix shell.
I use the Slackware Linux as my primary OS, fetch mozilla source from cvs with this OS. And I run a Windows in my VirtualBox machine, doing Symbian OS development (my primary work) inside the guest Windows. I am trying to adopt the way I learned from www.martin.st/symbian gradually, but I haven't put this way the first choice cause of production quality concerns.
N770 to N810 are not Symbian OS based devices, they are based on Linux kernel and a distro looks like Debian.
apply this patch under
mozilla/nsprpub/build/symbian/tests
and use "gen_tests_mmp.py" to generate all unit test project files for Symbian OS automatically, instead of all test project files in old patch(attachment id 319557).
by the way, there is a nspr_gui_test project acts as a caller to test all other unit tests, but maybe i need to replace their directory placement in future to get everything more clear.
Attachment #319557 - Attachment is obsolete: true
Attachment #319735 - Flags: review?
Attachment #319557 - Flags: review?
Status: NEW → ASSIGNED
Blocks: 432606
Comment on attachment 319556 [details] [diff] [review]
nspr port for Symbian OS, no tests project files

Harry,

I glanced through this patch quickly.  Here are some comments.

It seems that Symbian provides a POSIX environment because you're
actually using the NSPR Unix files for Symbian.  It may be good
to define XP_UNIX for Symbian because this POSIX environment looks
very complete.  It would eliminate some of your changes.

Let's just use the SYMBIAN macro and remove XP_SYMBIAN.  We only
need one.

Ideally, you should add include/md/_symbian.cfg to the source tree,
and create a symlink named prcpucfg.h to _symbian.cfg during the
build.  Can you do that?

Some of your files are copied from Linux files.  Please go through
them and remove the unnecessary code.  For example, I doubt Symbian
supports CPU architectures such as __ia64__ and __s390__.  (Your
prcpucfg.h file shows Symbian only supports __arm__.)  Also change
references to Linux to Symbian.

Why do you need to undefine _WIN32 and __i386__?
Thanks for comment, they are very nice and I will start working on them soon. 

About the last one, the preprocessor used in build process behaves some strangely that sometime it will expose lines in a "#ifdef _WIN32" or a "#ifdef __i386__", maybe the preprocessor which produces the emulator binary(x86,WINNT based) has some built-in MACRO. Later I will verify this guess with further tests.

Now I am adding more to test cases in order to get them running on target device(I have an Nokia N82 at hand, and the ideal device is Nokia N73, it's the leading device, most typical model in the platform) and verify functionalities of this patch. With more test cases running on target device, I will fix what can be fixed and make a summary of NSPR limitations for Symbian OS.
If you really need to undefine _WIN32 and __i386__ to
work around the strange preprocessor problem, please add
a short comment to explain that.  Thanks!
I am working on fix for the patch now. However, there is something tough with the free-software compiler and complexcity of test cases on a Nokia S60 Phone which is Symbian OS based. Because I don't know if you have a deadline or acceptable time requirement for a patch fix in Mozilla community for a part-time contributor. Here I send you my apologize for time delay. If any rules or customs you think I should learn first, please feel free to guide me.

I think there are three problems I am facing now, I am working on fix them one by one, but probably you guys could give me some comments:

1) The compiler problem can be found here: http://groups.google.com/group/mozilla.dev.platforms.mobile/browse_thread/thread/2e7ef1c47d3971fe# . 

2) There is a issue about build tool chain, initial discussion found here: http://wiki.mozilla.org/Mobile/Build/Symbian#Can_I_build_it_under_Linux.2FUnix_with_gmake.3F

3) Test cases are large in number and probably many of them are not applicable for a phone, like socket bind/listen. I have to find them one by one, find reason for runnable or un-runnable cases from source to behavior, this is a large amount of work which will cost time. If anyone could give me guides on efficiency, I will be glad to take.

Thanks again for attention on this bug.
You only need to port the tests listed in
mozilla/nsprpub/pr/tests/runtests.sh.  If Symbian
supports server sockets, it is still useful to
port the server socket functions so that you can
run our socket tests, which are standalone tests
that don't require another computer acting as a
server.

You can take your time working on the Symbian port.
We don't have a deadline for you.
I made a spreadsheet which reports the status of test cases running on NSPR for Symbian OS, at here : http://spreadsheets.google.com/pub?key=puHMGxziDYnOk8BeukovcSA . 

There is still a lot to test, yet the method of making a single test case and some tricks to get the case run/PASS are covered in past a few days.
Keywords: mobile
Please find details about this patch at
http://wiki.mozilla.org/Mobile/Symbian/NSPR
and
http://wiki.mozilla.org/Mobile/Build/Symbian

All functionalities which are applicable on Symbian OS are done as earlier description. Most test cases for UNIX OS run well and get passed. Eight waiver candidates are : anonfm, dlltest, ioconthr, peek, pipeping, pipeping2, sema, sockping. Now those eight test cases are waiting for waiver approval, however some of them may have workaround to get run/pass or even functionality fix/recover inside NSPR in future.

There are still potential changes. So just point out any comment.

Thanks a lot!
Attachment #319556 - Attachment is obsolete: true
Attachment #319735 - Attachment is obsolete: true
Attachment #324584 - Flags: review?(wtc)
Attachment #319556 - Flags: review?
Attachment #319735 - Flags: review?
Summary: [PATCH] NSPR port to Symbian OS, functionality not complete yet. → [PATCH] NSPR port to Symbian OS, unit tests tested
Comment on attachment 324584 [details] [diff] [review]
nspr port for Symbian OS, with testcases run

Harry,

I reviewed _symbian.cfg, _symbian.h, symbian.c, and
cleaned them up.  I have some questions.

1. Does we need the following in both _symbian.cfg and
_symbian.h?

+#if defined(__WINS__)
+#undef _WIN32
+#undef __i386__
+#endif

It should be enough to just add that to _symbian.cfg.
Another method is to do that on the compiler command
line: -U_WIN32 -U__i386__

2. Is Symbian using glibc?  Since you copied the Linux
code, there are a lot of #if tests for __GLIBC__ in your
Symbian code.  I'm not sure whether __GLIBC__ is defined
on Symbian, or it's just that you didn't remove __GLIBC__
from the Linux code you copied.

3. If Symbian doesn't have AF_INET6, we need to pick
a value for PR_AF_INET6 that is different from any
AF_xxx defined on Symbian.  Could you email me the
system header file that defines AF_INET?

4. Does Symbian have the pthread library?  Are you
using it?

5. In _symbian.h, you have

+#ifdef DYNAMIC_LIBRARY
+#define HAVE_DLL
+#define USE_DLFCN
+#endif

What is the DYNAMIC_LIBRARY macro?
Comment on attachment 324584 [details] [diff] [review]
nspr port for Symbian OS, with testcases run

Another question about

+/* Symbian OS emulator build preprocessor has built-in _WIN32 and __i386__ macro */
+#if defined(__WINS__)
+#undef _WIN32
+#undef __i386__
+#endif

Does that mean in the Symbian OS emulator build, both
__i386__ and __arm__ are defined?  If so, that's just
wrong.
1, Yes, we can remove these #undef in _symbian.h, and if we shall use command
line parameters for compiler, we could addd
"OPTION CW -U__i386__ -U_WIN32"
under the line "LINKEROPTION GCCE --shared" in "nspr.mmp".
OPTION = give command line parameter
CW = Compiler for WINS(emulator) build
I think this also answers your next comment: "there is __i386__ define built in
the preprocessor of emulator build tool chain, so we have to undef them".

2, There is no "__GLIBC__" macro and the library in Symbian, so it's just some
unreachable codes in those lines.

3, email on the way. But IPv6 is supported in a recent "Open C" plugin release,
so maybe I could add this in future.

4, Yes, there is pthread library in Symbian with a plugin called "Open C" which
is an official plugin from Nokia.

5, As mentioned in http://wiki.mozilla.org/Mobile/Symbian/NSPR#Notes point 1,
the current open source compiler/linker--"GCCE from CodeSourcery" can not
produce correct DLL binary for target device. This compiler defect can be found
here http://www3.symbian.com/faq.nsf/AllByDate/B8542F039C193CCC802573DA0011DFA7
. I just missed document this in source.
More questions regarding _symbian.h:

1. Does Symbian have the poll() function?

2. Does Symbian have large file support?  This is the
case if the off_t type is 64-bit, or there is an off64_t
type.

If you don't know the answer, we can just define
_PR_NO_LARGE_FILES for now.

3. If you don't plan to support IPv6, we can remove the
following IPv6-related macros from _symbian.h:

//#define _PR_INET6 // Symbian OS Open C does not support IPv6
#define _PR_HAVE_INET_NTOP
#define _PR_HAVE_GETHOSTBYNAME2
#define _PR_HAVE_GETADDRINFO
//#define _PR_INET6_PROBE // Symbian OS Open C does not support IPv6

4. Does Symbian have gethostbyname_r()?  If so, what's
its function prototype?
1, Symbian/Open C does not have poll().

2, Symbian/Open C doesn't implement large file support(no open64 and others). so we have to keep _PR_NO_LARGE_FILES.

3, For simplify our initial patch, I'm OK with this.

4, Symbian/Open C does not have gethostbyname_r(), but unlike question 1 and 2, this missing function is not documented anywhere. So further limitation confirmation needs to be done.
(In reply to comment #5)
I spoke to Doug Turner about your use of project files
this morning.  He too suggested that you should use
makefiles if possible.  Have you ever built Firefox on
Windows?  It uses a Unix-like command line environment
called MSYS.  MSYS has bash and GNU make.  It would be
nice if you can use MSYS to drive your Symbian compiler
and linker on Windows.
I checked in these three files on the NSPR trunk first.

RCS file: /cvsroot/mozilla/nsprpub/pr/include/md/_symbian.cfg,v
done
Checking in pr/include/md/_symbian.cfg;
/cvsroot/mozilla/nsprpub/pr/include/md/_symbian.cfg,v  <--  _symbian.cfg
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/nsprpub/pr/include/md/_symbian.h,v
done
Checking in pr/include/md/_symbian.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_symbian.h,v  <--  _symbian.h
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/nsprpub/pr/src/md/unix/symbian.c,v
done
Checking in pr/src/md/unix/symbian.c;
/cvsroot/mozilla/nsprpub/pr/src/md/unix/symbian.c,v  <--  symbian.c
initial revision: 1.1
done
Comment on attachment 324584 [details] [diff] [review]
nspr port for Symbian OS, with testcases run

I reviewed the changes in pr/include and pr/src/{io,linking}.

1. prtypes.h:

MDCPUCFG should be defined by the build system.  See configure.in
and autoconf.mk.in:
http://lxr.mozilla.org/nspr/search?string=MDCPUCFG

I will create a new section for SYMBIAN for the __declspec(dllexport)
stuff.  Does Symbian OS have __declspec(dllimport), too?

2. prlink.c:

In Unix, dlerror() returns char *:
http://www.opengroup.org/onlinepubs/009695399/functions/dlerror.html

We can assign a char * value to a const char * variable without
casting.  What does dlerror() return on Symbian OS?

3. _symbian.cfg:

About the issue of whether we should undefine _WIN32 and __i386__
in this header or on the compiler command line: this depends on
whether we need to do this for NSPR only or also for anything
that uses NSPR.

If we need to undefine _WIN32 and __i386__ for NSPR only, we
should do this on the compiler command line.

If we need to undefine _WIN32 and __i386__ for NSPR and anything
that uses NSPR, we can do this in _symbian.cfg.  This is because
_symbian.cfg is included in every NSPR header file.

Also, you should review the values of the macros defined in
_symbian.cfg.  Many of the macros are supposed to be generated
by the file mozilla/nsprpub/pr/include/gencfg.c:
http://lxr.mozilla.org/nspr/source/nsprpub/pr/include/gencfg.c

I haven't run that program for a long time.  You'd need to port
it to Symbian OS first.
this updated patch removes all /mozilla/nsprpub/build/symbian directory cause we are preparing moving to configure/gmake build system. And also some minor fixes since last update.
1, there is no more
#ifdef SYMBIAN
#define MDCPUCFG "md/_symbian.cfg"
#endif
in prtypes.h.
In Symbian headers, they define
#define IMPORT_C __declspec(dllexport)
for emulator builds, and 
#define IMPORT_C __declspec(dllimport)
for device(GCCE,RVCT) builds.

2,In Symbian, dlerror() also returns char*, but the strict type checking compiler will return error without a explicit type cast. Please refer: http://www.forum.nokia.com/document/CDL_Extension_S60_3rd_Ed_FP2/GUID-719955DA-415B-420E-9F9B-F6DB37615EC5/html/s60_oss_porting_using_openc6.html#topic5.5

3,The situation is that we need to undef these __i386__ and _WIN32 anywhere when we are building for Symbian emulator with its compiler. So I suggest this deserves a hard-coded -U as compiler flags in Makefile.

Further more, I will try port and run gencfg.c on a Symbian device soon. Probably the result will arrive in next 12 hours :)
The code
    const char *error = NULL;
    error = (const char*) dlerror();
should not require the (const char*) typecase
if dlerror() returns char *.  A compiler with
strict type checking should allow an assignment
of "T *" to "const T *" without a (const T *)
typecast.

Perhaps dlerror() is not declared, so it get
the default int return type?  Did you include
<dlfcn.h>?

If dlerror() is properly declared to return
char *, and the compiler requires the (const char*)
typecast, this is a compiler bug.
I just had a double check, and then found for this line in prlink.c, actually the type cast is not needed, with either compiler. So this was my lack of carefulness. We can remove this stupid "(const char*)" here.
Comment on attachment 327262 [details] [diff] [review]
updated nspr for symbian [Jun 28th 2008]

Glad to know the (const char*) typecast in prlink.c is not needed.

In this new patch (Jun 28th 2008), you didn't change prtypes.h.
So do we still need to use __declspec(dllexport)?

Don't spend too much time on gencfg.c if it turns out to be a lot
of work to port and run it on Symbian OS.  You can just review
the macro values in _symbian.cfg.  The meaning of those macros
should be obvious by their names.
After reviewing gencfg result, two lines found not the same as values in past _symbian.cfg:
#define PR_ALIGN_OF_INT64   8
#define PR_ALIGN_OF_DOUBLE  8
But they remain the same value "4" on emulator builds (32bit x86 arch. on Windows OS). So I fixed _symbian.cfg as followings:

#ifdef __WINS__
#define PR_ALIGN_OF_INT64   4
#define PR_ALIGN_OF_DOUBLE  4
#else
#define PR_ALIGN_OF_INT64   8
#define PR_ALIGN_OF_DOUBLE  8

About the dllimport and dllexport, I made the fix in this submit too.
Depends on: 442706
Harry, I checked in your updated _symbian.cfg and prtypes.h
on the NSPR trunk (NSPR 4.7.2).  The only change I made is
that I gave SYMBIAN its own section in prtypes.h, rather than
sharing the Unix section.

You may be able to use __declspec(dllexport) in the PR_EXTERN,
PR_IMPLEMENT, PR_EXTERN_DATA, and PR_IMPLEMENT_DATA macros.
Please see the WIN32, XP_BEOS, and XP_OS2 sections in prtypes.h,
and compare them with the SYMBIAN section.

Checking in md/_symbian.cfg;
/cvsroot/mozilla/nsprpub/pr/include/md/_symbian.cfg,v  <--  _symbian.cfg
new revision: 1.3; previous revision: 1.2
done
Checking in prtypes.h;
/cvsroot/mozilla/nsprpub/pr/include/prtypes.h,v  <--  prtypes.h
new revision: 3.37; previous revision: 3.36
done
Attachment #327301 - Attachment is obsolete: true
I don't know if I mentioned this before.  I think we should
consider the emulator builds as the x86 (i386) arch.
(In reply to comment #30)
> I don't know if I mentioned this before.  I think we should
> consider the emulator builds as the x86 (i386) arch.
> 

I guess you haven't mentioned this. However, I had mentioned that the emulator builds are really x86(i386) arch. binary executables.
(In reply to comment #29)
> Created an attachment (id=330396) [details]
> updated _symbian.cfg and prtypes.h [June 29th 2008] (as checked in)
> 
> Harry, I checked in your updated _symbian.cfg and prtypes.h
> on the NSPR trunk (NSPR 4.7.2).  The only change I made is
> that I gave SYMBIAN its own section in prtypes.h, rather than
> sharing the Unix section.
> 
> You may be able to use __declspec(dllexport) in the PR_EXTERN,
> PR_IMPLEMENT, PR_EXTERN_DATA, and PR_IMPLEMENT_DATA macros.
> Please see the WIN32, XP_BEOS, and XP_OS2 sections in prtypes.h,
> and compare them with the SYMBIAN section.
> 
> Checking in md/_symbian.cfg;
> /cvsroot/mozilla/nsprpub/pr/include/md/_symbian.cfg,v  <--  _symbian.cfg
> new revision: 1.3; previous revision: 1.2
> done
> Checking in prtypes.h;
> /cvsroot/mozilla/nsprpub/pr/include/prtypes.h,v  <--  prtypes.h
> new revision: 3.37; previous revision: 3.36
> done
> 

I think these changes will be OK. I will verify them with the new build tool chain updates together.

Now I almost finish the build tool chain immigration to gnu make/autoconf, only final testing and compiler arguments line de-uglification works left. Before you move on with this nspr patch, I should tell you that there is a minor changes in nsprpub/pr/src/md/unix/symbian.c because of build tools change. And also there might be potential changes in nsprpub/pr/src/pthread/ptio.c because pt_Accept() function still can't take NULL as its second argument if timeout is set to unlimited. stuart in IRC channel #mobile talked with me about this issue today. Finally, there will be further fixes on the run_nspr_tests.cpp, the tests caller application who plays the role of "runtests.sh" in a Symbian OS phone, most refinements are inspired by NSS testing scripts.
I checked in the remaining header file changes on the NSPR
trunk (NSPR 4.7.2).

Checking in md/_pth.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_pth.h,v  <--  _pth.h
new revision: 3.34; previous revision: 3.33
done
Checking in md/_unixos.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_unixos.h,v  <--  _unixos.h
new revision: 3.37; previous revision: 3.36
done
Checking in md/prosdep.h;
/cvsroot/mozilla/nsprpub/pr/include/md/prosdep.h,v  <--  prosdep.h
new revision: 3.18; previous revision: 3.17
done
Comment on attachment 327262 [details] [diff] [review]
updated nspr for symbian [Jun 28th 2008]

Harry, based on your comment 26, I will omit your change
to prlink.c in this patch.
I checked in the straightforward porting changes in the
pr/src directory on the NSPR trunk (NSPR 4.7.2).

Checking in mozilla/nsprpub/pr/src/io/prmapopt.c;
/cvsroot/mozilla/nsprpub/pr/src/io/prmapopt.c,v  <--  prmapopt.c
new revision: 3.19; previous revision: 3.18
done
Checking in mozilla/nsprpub/pr/src/md/prosdep.c;
/cvsroot/mozilla/nsprpub/pr/src/md/prosdep.c,v  <--  prosdep.c
new revision: 3.13; previous revision: 3.12
done
Checking in mozilla/nsprpub/pr/src/md/unix/uxrng.c;
/cvsroot/mozilla/nsprpub/pr/src/md/unix/uxrng.c,v  <--  uxrng.c
new revision: 1.20; previous revision: 1.19
done
Checking in mozilla/nsprpub/pr/src/misc/prsystem.c;
/cvsroot/mozilla/nsprpub/pr/src/misc/prsystem.c,v  <--  prsystem.c
new revision: 3.29; previous revision: 3.28
done
Checking in mozilla/nsprpub/pr/src/misc/prtime.c;
/cvsroot/mozilla/nsprpub/pr/src/misc/prtime.c,v  <--  prtime.c
new revision: 3.33; previous revision: 3.32
done
Checking in mozilla/nsprpub/pr/src/pthreads/ptsynch.c;
/cvsroot/mozilla/nsprpub/pr/src/pthreads/ptsynch.c,v  <--  ptsynch.c
new revision: 3.30; previous revision: 3.29
done
Attachment #324584 - Attachment is obsolete: true
Attachment #324584 - Flags: review?(wtc)
patch against current v4.7.2 HEAD, patch size reduced.
prnetdb.c updated since last patch.
PR_Accept() in ptio.c still needs further tunes.
Attachment #327262 - Attachment is obsolete: true
Attachment #331916 - Flags: review?(wtc)
Comment on attachment 331916 [details] [diff] [review]
updated nspr for symbian [Jul 31st 2008]

Harry,

I reviewed the changes to pr/src (except prnetdb.c)
in this patch.  I have some questions.

1. pr/src/md/unix/unix.c

Why can't we initialize _md_iovector with 'open'?
What is the compiler error or warning message?

2. pr/src/md/unix/uxshm.c

>+    /* In Symbian OS the system imposed minimum is 1 byte, instead of ZERO */
>+    id = shmget( key, 1, 0 );
>+#else
>     id = shmget( key, 0, 0 );
>+#endif

I need to study this issue.  A 'size' (second argument)
of 0 may have a special meaning.  What happens if you
pass a 'size' of 0?  If shmget fails, what's the errno?

>+#ifdef SYMBIAN
>+        genName = PR_smprintf( "%s\\NSPR-AFM-%d-%p.%d",
>+#else
>         genName = PR_smprintf( "%s/.NSPR-AFM-%d-%p.%d", 
>+#endif

Does this mean the directory separator on Symbian is
'\\' rather than '/'?  If so, we need to change the
definition of PR_DIRECTORY_SEPARATOR and
PR_DIRECTORY_SEPARATOR_STR in _unixos.h for Symbian.

3. pr/src/pthreads/ptio.c

Does accept() disallow a NULL 'addr' argument?
You may want to report this limitation to the Open C
developers.  It is common to pass NULL as the second
argument to accept().

Does Symbian not have the MSG_PEEK macro defined for
recv()?

PR_NewTCPSocketPair: If Symbian doesn't have the
socketpair() function, we need to emulate it with
a pair of TCP sockets.  See the implementation of
PR_NewTCPSocketPair in prsocket.c.  You can use
the code for "WINNT" as a basis.

What's the errno if we call
    fcntl(fd, F_SETFD, 0)
or
    fcntl(fd, F_SETFD, FD_CLOEXEC)?

So Symbian doesn't have getrlimit() and setrlimit(),
but has the related struct rlimit rlim.  Isn't that
strange?

4. pr/src/pthreads/ptthread.c

Why do we need to undefine
_POSIX_THREAD_PRIORITY_SCHEDULING?
(In reply to comment #37)

1. The compiler error has gone by now, probably because of fixes from other places.

2. pr/src/md/unix/uxshm.c
It really means the directory separator on Symbian is '\\' rather than '/'? Symbian uses FAT file system, and it has drive letter with ':' and '\\' separated folder name. For all phones "C:" = NAND FLASH, "E:" = Memory Card, "Z:" = ROM where the OS residents. So actually PR_DIRECTORY_SEPARATOR and PR_DIRECTORY_SEPARATOR_STR should be changed.

I will investigate shmget() behavior tomorrow when I get the testing phone.

3. pr/src/pthreads/ptio.c
When passing NULL as 'addr' to accept(), it just gives a crash, with error code indicating something shouldn't be NULL is NULL. The reason may be the in the Open C implementation, which is not open source.

MSG_PEEK is defined. But it doesn't work as expected. Nokia internal tech support suggested workaround of making extra buffer to mark the receiving data which I suppose we could do it separately.

Emulated socketpair() function will be added soon.

fcntl() error code will be reported later.

getrlimit() and setrlimit() are unimplemented. However, after a detail comparing between <sys/resource.h> from Linux and Symbian, I found the rlim related lines in this patch is NOT correct indeed. RLIM_NLIMITS is not the value I should return in PR_GetSysfdTableMax(). I will work on this issue at once, probably the fix is coming soon.

4. Because Open C doesn't implemented pthread_attr_* functions, there should be no "_POSIX_THREAD_PRIORITY_SCHEDULING" defined. However, in the <unistd.h> system include, there is the define line: 
#define	_POSIX_THREAD_PRIORITY_SCHEDULING 200112L
So I undef it in source file.

Harry's TODO List:
a) Investigate behavior and error code from fcntl() and shmget().
b) Fix rlimit issue.
c) Make a socketpair() function.
d) Make workaround for NULL as 'addr' with accept(), before Open C implementation fix this.
(In reply to comment #37)

for task a) Investigate behavior and error code from fcntl() and shmget().

fcntl() will return -1 on both callings:
    fcntl(fd, F_SETFD, 0)
and
    fcntl(fd, F_SETFD, FD_CLOEXEC)
both errnos are "78"
according to errno.h defined in Symbian OS, its
#define	ENOSYS 78 /* Function not implemented */

when calling 
id = shmget( key, 0, 0 );
-1 is returned and errno is 22.
it's defined as
#define	EINVAL 22 /* Invalid argument */
Harry,

Thanks a lot for finding the answers to my question.  The errno
information will allow me to map it to an NSPR error code.

Yes, we can emulate MSG_PEEK ourselves.  There is such emulation
code in prsocket.c.  Search for _PR_FD_NEED_EMULATE_MSG_PEEK in
the NSPR source tree:
http://mxr.mozilla.org/nspr/ident?i=_PR_FD_NEED_EMULATE_MSG_PEEK

If the application you want to port to Symbian OS isn't using
PR_MSG_PEEK, you don't need to emulate MSG_PEEK now.
in this patch, b) and c) in todo list is done.
Description:
for PR_GetSysfdTableMax(), sysconf(_SC_OPEN_MAX) is used instead of getrlimit() because Symbian supports this.
for PR_NewTCPSocketPair(), codes are copied from WINNT implementation, and some minor modification. The last two _PR_MD_INIT_FD_INHERITABLE() are removed. This function has been tested on test case "foreign" and "ioconthr". However, there are some test cases problem to solve.

By now there is only the PR_Accept() takes NULL as 'addr' problem left. This will be by the end of this week hopefully.
Attachment #332550 - Flags: review+
Harry,

I reviewed your updated ptio.c patch (attachment 332550 [details] [diff] [review]).  I
made some changes and checked it in on the NSPR trunk (NSPR 4.7.3).

Please verify that the comments I added about the problems
with accept with addr==NULL and MSG_PEEK are accurate.  Please
also test the new implementation of PR_NewTCPSocketPair. (I copied
the "default implementation" from prsocket.c, which uses NSPR
functions to create and connect the TCP socket pairs.)

Checking in include/md/_beos.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_beos.h,v  <--  _beos.h
new revision: 3.24; previous revision: 3.23
done
Checking in include/md/_os2.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_os2.h,v  <--  _os2.h
new revision: 3.40; previous revision: 3.39
done
Checking in include/md/_unixos.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_unixos.h,v  <--  _unixos.h
new revision: 3.38; previous revision: 3.37
done
Checking in src/io/prmapopt.c;
/cvsroot/mozilla/nsprpub/pr/src/io/prmapopt.c,v  <--  prmapopt.c
new revision: 3.20; previous revision: 3.19
done
Checking in src/md/unix/unix_errors.c;
/cvsroot/mozilla/nsprpub/pr/src/md/unix/unix_errors.c,v  <--  unix_errors.c
new revision: 3.28; previous revision: 3.27
done
Checking in src/pthreads/ptio.c;
/cvsroot/mozilla/nsprpub/pr/src/pthreads/ptio.c,v  <--  ptio.c
new revision: 3.110; previous revision: 3.109
done
Attachment #332550 - Attachment is obsolete: true
Wan-Teh,

I have built and tested these new checkins, the test result is just OK on a Nokia 6220 Navigator. But this device won't run some test cases even before these updates. I am fixing them now, and results or patches will be posted as soon as they get done.
Hi Harry Li:
   how can I down the build/symbian/ files?
I have down the svn "revision 5";
and I build failed.
this is the config.log
//===========================================================================
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:632: checking host system type
configure:653: checking target system type
configure:671: checking build system type
configure:1080: checking for whoami
configure:1151: checking for i686-pc-mingw32 compiler
configure:1157: checking for gcc
configure:1203: checking whether the i686-pc-mingw32 compiler (gcc  ) works
configure:1212: gcc -c   conftest.c 1>&5
configure:1241: checking for arm-none-symbianelf-gcc
configure:1275: checking for gcc
configure:1388: checking whether the C compiler (gcc  ) works
configure:1404: gcc -o conftest    conftest.c  1>&5
configure:1430: checking whether the C compiler (gcc  ) is a cross-compiler
configure:1435: checking whether we are using GNU C
configure:1463: checking whether gcc accepts -g
configure:1688: checking for arm-none-symbianelf-ranlib
configure:1723: checking for arm-none-symbianelf-ar
configure:1758: checking for arm-none-symbianelf-as
configure:1793: checking for arm-none-symbianelf-ld
configure:1828: checking for arm-none-symbianelf-strip
configure:1863: checking for arm-none-symbianelf-windres
configure:1863: checking for arm-none-symbianelf-windres
configure:2613: checking for gcc -pipe support
configure:2662: checking for visibility(hidden) attribute
configure:2739: checking for perl5
configure:5161: checking for dlopen in -ldl
configure:5240: checking whether mwccsym2.exe needs -traditional
configure:5288: checking for lchown
configure:5288: checking for strerror
configure:5396: checking for pthread_create in -lpthreads
mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis -include Symbian_OS_v9.1.hrh  -lpthreads  

Errors caused tool to abort.
configure:5418: checking for pthread_create in -lpthread
mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis -include Symbian_OS_v9.1.hrh  -lpthread  

Errors caused tool to abort.
configure:5440: checking for pthread_create in -lc_r
mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis -include Symbian_OS_v9.1.hrh  -lc_r  

Errors caused tool to abort.
configure:5462: checking for pthread_create in -lc
mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis -include Symbian_OS_v9.1.hrh  -lc  

Errors caused tool to abort.
configure:5594: checking whether mwccsym2.exe accepts -pthread
configure:5617: checking whether mwccsym2.exe accepts -pthreads
hi harry, i built fault too !

config.log

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:632: checking host system type
configure:653: checking target system type
configure:671: checking build system type
configure:1080: checking for whoami
configure:1151: checking for i686-pc-mingw32 compiler
configure:1157: checking for gcc
configure:1203: checking whether the i686-pc-mingw32 compiler (gcc  ) works
configure:1212: gcc -c   conftest.c 1>&5
configure:1241: checking for arm-none-symbianelf-gcc
configure:1275: checking for gcc
configure:1388: checking whether the C compiler (arm-none-symbianelf-gcc  ) works
configure:1404: arm-none-symbianelf-gcc -o conftest    conftest.c  1>&5
d:/Program Files/CSL Arm Toolchain/bin/../lib/gcc/arm-none-symbianelf/3.4.3/../../../../arm-none-symbianelf/bin/ld.exe: warning: cannot find entry symbol _start; defaulting to 00008000
configure:1430: checking whether the C compiler (arm-none-symbianelf-gcc  ) is a cross-compiler
configure:1435: checking whether we are using GNU C
configure:1444: arm-none-symbianelf-gcc -E conftest.c
configure:1463: checking whether arm-none-symbianelf-gcc accepts -g
configure:1688: checking for arm-none-symbianelf-ranlib
configure:1723: checking for arm-none-symbianelf-ar
configure:1758: checking for arm-none-symbianelf-as
configure:1793: checking for arm-none-symbianelf-ld
configure:1828: checking for arm-none-symbianelf-strip
configure:1863: checking for arm-none-symbianelf-windres
configure:1863: checking for arm-none-symbianelf-windres
configure:2613: checking for gcc -pipe support
configure:2662: checking for visibility(hidden) attribute
configure:2686: checking for visibility pragma support
configure:2739: checking for perl5
configure:2739: checking for perl
configure:5161: checking for dlopen in -ldl
configure:5180: mwccsym2.exe -o conftest  -MD -nostdinc -O0 -inline off -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh   conftest.c -ldl   1>&5
mwccsym2.exe: No library file found matching 'libdl{.lib|.a}' or 'dl'

Errors caused tool to abort.
configure: failed program was:
#line 5169 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char dlopen();

int main() {
dlopen()
; return 0; }
configure:5240: checking whether mwccsym2.exe needs -traditional
./conftest.c: /c/cygwin/bin/Autoconf: No such file or directory
./conftest.c: /c/cygwin/bin/Autoconf: No such file or directory
configure:5288: checking for lchown
configure:5316: mwccsym2.exe -o conftest  -MD -nostdinc -O0 -inline off -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh   conftest.c  1>&5
(command-line defines):2: the file 'Symbian_OS_v9.1.hrh' cannot be opened
conftest.c:5: the file 'assert.h' cannot be opened

Errors caused tool to abort.
configure: failed program was:
#line 5293 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char lchown(); below.  */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char lchown();

int main() {

/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined (__stub_lchown) || defined (__stub___lchown)
choke me
#else
lchown();
#endif

; return 0; }
configure:5288: checking for strerror
configure:5316: mwccsym2.exe -o conftest  -MD -nostdinc -O0 -inline off -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh   conftest.c  1>&5
(command-line defines):2: the file 'Symbian_OS_v9.1.hrh' cannot be opened
conftest.c:5: the file 'assert.h' cannot be opened

Errors caused tool to abort.
configure: failed program was:
#line 5293 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char strerror(); below.  */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char strerror();

int main() {

/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined (__stub_strerror) || defined (__stub___strerror)
choke me
#else
strerror();
#endif

; return 0; }
configure:5396: checking for pthread_create in -lpthreads
mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh  -lpthreads  

Errors caused tool to abort.
configure:5418: checking for pthread_create in -lpthread
mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh  -lpthread  

Errors caused tool to abort.
configure:5440: checking for pthread_create in -lc_r
mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh  -lc_r  

Errors caused tool to abort.
configure:5462: checking for pthread_create in -lc
mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh  -lc  

Errors caused tool to abort.
configure:5594: checking whether mwccsym2.exe accepts -pthread
configure:5617: checking whether mwccsym2.exe accepts -pthreads
(In reply to comment #45)
Hi  redpanda:
    you must to install the 3.1 sdk the which include Symbian_OS_v9.1.hrh

or it will use another version.

    eg:

     s60_3rd_fp2 use Symbian_OS_v9.3.hrh

    you can try rename Symbian_OS_v9.3.hrh to Symbian_OS_v9.1.hrh




> hi harry, i built fault too !
> 
> config.log
> 
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> 
> configure:632: checking host system type
> configure:653: checking target system type
> configure:671: checking build system type
> configure:1080: checking for whoami
> configure:1151: checking for i686-pc-mingw32 compiler
> configure:1157: checking for gcc
> configure:1203: checking whether the i686-pc-mingw32 compiler (gcc  ) works
> configure:1212: gcc -c   conftest.c 1>&5
> configure:1241: checking for arm-none-symbianelf-gcc
> configure:1275: checking for gcc
> configure:1388: checking whether the C compiler (arm-none-symbianelf-gcc  )
> works
> configure:1404: arm-none-symbianelf-gcc -o conftest    conftest.c  1>&5
> d:/Program Files/CSL Arm
> Toolchain/bin/../lib/gcc/arm-none-symbianelf/3.4.3/../../../../arm-none-symbianelf/bin/ld.exe:
> warning: cannot find entry symbol _start; defaulting to 00008000
> configure:1430: checking whether the C compiler (arm-none-symbianelf-gcc  ) is
> a cross-compiler
> configure:1435: checking whether we are using GNU C
> configure:1444: arm-none-symbianelf-gcc -E conftest.c
> configure:1463: checking whether arm-none-symbianelf-gcc accepts -g
> configure:1688: checking for arm-none-symbianelf-ranlib
> configure:1723: checking for arm-none-symbianelf-ar
> configure:1758: checking for arm-none-symbianelf-as
> configure:1793: checking for arm-none-symbianelf-ld
> configure:1828: checking for arm-none-symbianelf-strip
> configure:1863: checking for arm-none-symbianelf-windres
> configure:1863: checking for arm-none-symbianelf-windres
> configure:2613: checking for gcc -pipe support
> configure:2662: checking for visibility(hidden) attribute
> configure:2686: checking for visibility pragma support
> configure:2739: checking for perl5
> configure:2739: checking for perl
> configure:5161: checking for dlopen in -ldl
> configure:5180: mwccsym2.exe -o conftest  -MD -nostdinc -O0 -inline off
> -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc
> -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i-
> -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant
> -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis
>   -include Symbian_OS_v9.1.hrh   conftest.c -ldl   1>&5
> mwccsym2.exe: No library file found matching 'libdl{.lib|.a}' or 'dl'
> 
> Errors caused tool to abort.
> configure: failed program was:
> #line 5169 "configure"
> #include "confdefs.h"
> /* Override any gcc2 internal prototype to avoid an error.  */
> /* We use char because int might match the return type of a gcc2
>     builtin and then its argument prototype would still apply.  */
> char dlopen();
> 
> int main() {
> dlopen()
> ; return 0; }
> configure:5240: checking whether mwccsym2.exe needs -traditional
> ./conftest.c: /c/cygwin/bin/Autoconf: No such file or directory
> ./conftest.c: /c/cygwin/bin/Autoconf: No such file or directory
> configure:5288: checking for lchown
> configure:5316: mwccsym2.exe -o conftest  -MD -nostdinc -O0 -inline off
> -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc
> -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i-
> -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant
> -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis
>   -include Symbian_OS_v9.1.hrh   conftest.c  1>&5
> (command-line defines):2: the file 'Symbian_OS_v9.1.hrh' cannot be opened
> conftest.c:5: the file 'assert.h' cannot be opened
> 
> Errors caused tool to abort.
> configure: failed program was:
> #line 5293 "configure"
> #include "confdefs.h"
> /* System header to define __stub macros and hopefully few prototypes,
>     which can conflict with char lchown(); below.  */
> #include <assert.h>
> /* Override any gcc2 internal prototype to avoid an error.  */
> /* We use char because int might match the return type of a gcc2
>     builtin and then its argument prototype would still apply.  */
> char lchown();
> 
> int main() {
> 
> /* The GNU C library defines this for functions which it implements
>     to always fail with ENOSYS.  Some functions are actually named
>     something starting with __ and the normal name is an alias.  */
> #if defined (__stub_lchown) || defined (__stub___lchown)
> choke me
> #else
> lchown();
> #endif
> 
> ; return 0; }
> configure:5288: checking for strerror
> configure:5316: mwccsym2.exe -o conftest  -MD -nostdinc -O0 -inline off
> -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc
> -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i-
> -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant
> -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis
>   -include Symbian_OS_v9.1.hrh   conftest.c  1>&5
> (command-line defines):2: the file 'Symbian_OS_v9.1.hrh' cannot be opened
> conftest.c:5: the file 'assert.h' cannot be opened
> 
> Errors caused tool to abort.
> configure: failed program was:
> #line 5293 "configure"
> #include "confdefs.h"
> /* System header to define __stub macros and hopefully few prototypes,
>     which can conflict with char strerror(); below.  */
> #include <assert.h>
> /* Override any gcc2 internal prototype to avoid an error.  */
> /* We use char because int might match the return type of a gcc2
>     builtin and then its argument prototype would still apply.  */
> char strerror();
> 
> int main() {
> 
> /* The GNU C library defines this for functions which it implements
>     to always fail with ENOSYS.  Some functions are actually named
>     something starting with __ and the normal name is an alias.  */
> #if defined (__stub_strerror) || defined (__stub___strerror)
> choke me
> #else
> strerror();
> #endif
> 
> ; return 0; }
> configure:5396: checking for pthread_create in -lpthreads
> mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off
> -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int
> -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH)
> -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include
> -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh 
> -lpthreads  
> 
> Errors caused tool to abort.
> configure:5418: checking for pthread_create in -lpthread
> mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off
> -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int
> -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH)
> -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include
> -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh 
> -lpthread  
> 
> Errors caused tool to abort.
> configure:5440: checking for pthread_create in -lc_r
> mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off
> -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int
> -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH)
> -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include
> -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh 
> -lc_r  
> 
> Errors caused tool to abort.
> configure:5462: checking for pthread_create in -lc
> mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off
> -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int
> -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH)
> -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include
> -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh  -lc 
> 
> Errors caused tool to abort.
> configure:5594: checking whether mwccsym2.exe accepts -pthread
> configure:5617: checking whether mwccsym2.exe accepts -pthreads
hi terry,

i use s60 3rd MR, symbian_os_v9.1.hrh is in D:\Symbian\9.1\S60_3rd_MR\Epoc32\include\variant\


(In reply to comment #46)
> (In reply to comment #45)
> Hi  redpanda:
>     you must to install the 3.1 sdk the which include Symbian_OS_v9.1.hrh
> 
> or it will use another version.
> 
>     eg:
> 
>      s60_3rd_fp2 use Symbian_OS_v9.3.hrh
> 
>     you can try rename Symbian_OS_v9.3.hrh to Symbian_OS_v9.1.hrh
> 
> 
> 
> 
> > hi harry, i built fault too !
> > 
> > config.log
> > 
> > This file contains any messages produced by compilers while
> > running configure, to aid debugging if configure makes a mistake.
> > 
> > configure:632: checking host system type
> > configure:653: checking target system type
> > configure:671: checking build system type
> > configure:1080: checking for whoami
> > configure:1151: checking for i686-pc-mingw32 compiler
> > configure:1157: checking for gcc
> > configure:1203: checking whether the i686-pc-mingw32 compiler (gcc  ) works
> > configure:1212: gcc -c   conftest.c 1>&5
> > configure:1241: checking for arm-none-symbianelf-gcc
> > configure:1275: checking for gcc
> > configure:1388: checking whether the C compiler (arm-none-symbianelf-gcc  )
> > works
> > configure:1404: arm-none-symbianelf-gcc -o conftest    conftest.c  1>&5
> > d:/Program Files/CSL Arm
> > Toolchain/bin/../lib/gcc/arm-none-symbianelf/3.4.3/../../../../arm-none-symbianelf/bin/ld.exe:
> > warning: cannot find entry symbol _start; defaulting to 00008000
> > configure:1430: checking whether the C compiler (arm-none-symbianelf-gcc  ) is
> > a cross-compiler
> > configure:1435: checking whether we are using GNU C
> > configure:1444: arm-none-symbianelf-gcc -E conftest.c
> > configure:1463: checking whether arm-none-symbianelf-gcc accepts -g
> > configure:1688: checking for arm-none-symbianelf-ranlib
> > configure:1723: checking for arm-none-symbianelf-ar
> > configure:1758: checking for arm-none-symbianelf-as
> > configure:1793: checking for arm-none-symbianelf-ld
> > configure:1828: checking for arm-none-symbianelf-strip
> > configure:1863: checking for arm-none-symbianelf-windres
> > configure:1863: checking for arm-none-symbianelf-windres
> > configure:2613: checking for gcc -pipe support
> > configure:2662: checking for visibility(hidden) attribute
> > configure:2686: checking for visibility pragma support
> > configure:2739: checking for perl5
> > configure:2739: checking for perl
> > configure:5161: checking for dlopen in -ldl
> > configure:5180: mwccsym2.exe -o conftest  -MD -nostdinc -O0 -inline off
> > -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc
> > -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i-
> > -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant
> > -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis
> >   -include Symbian_OS_v9.1.hrh   conftest.c -ldl   1>&5
> > mwccsym2.exe: No library file found matching 'libdl{.lib|.a}' or 'dl'
> > 
> > Errors caused tool to abort.
> > configure: failed program was:
> > #line 5169 "configure"
> > #include "confdefs.h"
> > /* Override any gcc2 internal prototype to avoid an error.  */
> > /* We use char because int might match the return type of a gcc2
> >     builtin and then its argument prototype would still apply.  */
> > char dlopen();
> > 
> > int main() {
> > dlopen()
> > ; return 0; }
> > configure:5240: checking whether mwccsym2.exe needs -traditional
> > ./conftest.c: /c/cygwin/bin/Autoconf: No such file or directory
> > ./conftest.c: /c/cygwin/bin/Autoconf: No such file or directory
> > configure:5288: checking for lchown
> > configure:5316: mwccsym2.exe -o conftest  -MD -nostdinc -O0 -inline off
> > -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc
> > -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i-
> > -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant
> > -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis
> >   -include Symbian_OS_v9.1.hrh   conftest.c  1>&5
> > (command-line defines):2: the file 'Symbian_OS_v9.1.hrh' cannot be opened
> > conftest.c:5: the file 'assert.h' cannot be opened
> > 
> > Errors caused tool to abort.
> > configure: failed program was:
> > #line 5293 "configure"
> > #include "confdefs.h"
> > /* System header to define __stub macros and hopefully few prototypes,
> >     which can conflict with char lchown(); below.  */
> > #include <assert.h>
> > /* Override any gcc2 internal prototype to avoid an error.  */
> > /* We use char because int might match the return type of a gcc2
> >     builtin and then its argument prototype would still apply.  */
> > char lchown();
> > 
> > int main() {
> > 
> > /* The GNU C library defines this for functions which it implements
> >     to always fail with ENOSYS.  Some functions are actually named
> >     something starting with __ and the normal name is an alias.  */
> > #if defined (__stub_lchown) || defined (__stub___lchown)
> > choke me
> > #else
> > lchown();
> > #endif
> > 
> > ; return 0; }
> > configure:5288: checking for strerror
> > configure:5316: mwccsym2.exe -o conftest  -MD -nostdinc -O0 -inline off
> > -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc
> > -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i-
> > -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant
> > -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis
> >   -include Symbian_OS_v9.1.hrh   conftest.c  1>&5
> > (command-line defines):2: the file 'Symbian_OS_v9.1.hrh' cannot be opened
> > conftest.c:5: the file 'assert.h' cannot be opened
> > 
> > Errors caused tool to abort.
> > configure: failed program was:
> > #line 5293 "configure"
> > #include "confdefs.h"
> > /* System header to define __stub macros and hopefully few prototypes,
> >     which can conflict with char strerror(); below.  */
> > #include <assert.h>
> > /* Override any gcc2 internal prototype to avoid an error.  */
> > /* We use char because int might match the return type of a gcc2
> >     builtin and then its argument prototype would still apply.  */
> > char strerror();
> > 
> > int main() {
> > 
> > /* The GNU C library defines this for functions which it implements
> >     to always fail with ENOSYS.  Some functions are actually named
> >     something starting with __ and the normal name is an alias.  */
> > #if defined (__stub_strerror) || defined (__stub___strerror)
> > choke me
> > #else
> > strerror();
> > #endif
> > 
> > ; return 0; }
> > configure:5396: checking for pthread_create in -lpthreads
> > mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off
> > -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int
> > -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH)
> > -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include
> > -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh 
> > -lpthreads  
> > 
> > Errors caused tool to abort.
> > configure:5418: checking for pthread_create in -lpthread
> > mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off
> > -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int
> > -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH)
> > -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include
> > -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh 
> > -lpthread  
> > 
> > Errors caused tool to abort.
> > configure:5440: checking for pthread_create in -lc_r
> > mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off
> > -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int
> > -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH)
> > -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include
> > -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh 
> > -lc_r  
> > 
> > Errors caused tool to abort.
> > configure:5462: checking for pthread_create in -lc
> > mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off
> > -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int
> > -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH)
> > -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include
> > -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh  -lc 
> > 
> > Errors caused tool to abort.
> > configure:5594: checking whether mwccsym2.exe accepts -pthread
> > configure:5617: checking whether mwccsym2.exe accepts -pthreads
Hi redpanda:
  you would to check the env variable SYMBIAN_SDK_PATH:
  this is my:
  ===================================
     /d/S60/devices/S60_3rd_FP2_SDK/
  ===================================
  be care of the leader "/" and the low case "d" not the "D"

  good luck

terry.
(In reply to comment #47)
> hi terry,
> i use s60 3rd MR, symbian_os_v9.1.hrh is in
> D:\Symbian\9.1\S60_3rd_MR\Epoc32\include\variant\
> (In reply to comment #46)
> > (In reply to comment #45)
> > Hi  redpanda:
> >     you must to install the 3.1 sdk the which include Symbian_OS_v9.1.hrh
> > 
> > or it will use another version.
> > 
> >     eg:
> > 
> >      s60_3rd_fp2 use Symbian_OS_v9.3.hrh
> > 
> >     you can try rename Symbian_OS_v9.3.hrh to Symbian_OS_v9.1.hrh
> > 
> > 
> > 
> > 
> > > hi harry, i built fault too !
> > > 
> > > config.log
> > > 
> > > This file contains any messages produced by compilers while
> > > running configure, to aid debugging if configure makes a mistake.
> > > 
> > > configure:632: checking host system type
> > > configure:653: checking target system type
> > > configure:671: checking build system type
> > > configure:1080: checking for whoami
> > > configure:1151: checking for i686-pc-mingw32 compiler
> > > configure:1157: checking for gcc
> > > configure:1203: checking whether the i686-pc-mingw32 compiler (gcc  ) works
> > > configure:1212: gcc -c   conftest.c 1>&5
> > > configure:1241: checking for arm-none-symbianelf-gcc
> > > configure:1275: checking for gcc
> > > configure:1388: checking whether the C compiler (arm-none-symbianelf-gcc  )
> > > works
> > > configure:1404: arm-none-symbianelf-gcc -o conftest    conftest.c  1>&5
> > > d:/Program Files/CSL Arm
> > > Toolchain/bin/../lib/gcc/arm-none-symbianelf/3.4.3/../../../../arm-none-symbianelf/bin/ld.exe:
> > > warning: cannot find entry symbol _start; defaulting to 00008000
> > > configure:1430: checking whether the C compiler (arm-none-symbianelf-gcc  ) is
> > > a cross-compiler
> > > configure:1435: checking whether we are using GNU C
> > > configure:1444: arm-none-symbianelf-gcc -E conftest.c
> > > configure:1463: checking whether arm-none-symbianelf-gcc accepts -g
> > > configure:1688: checking for arm-none-symbianelf-ranlib
> > > configure:1723: checking for arm-none-symbianelf-ar
> > > configure:1758: checking for arm-none-symbianelf-as
> > > configure:1793: checking for arm-none-symbianelf-ld
> > > configure:1828: checking for arm-none-symbianelf-strip
> > > configure:1863: checking for arm-none-symbianelf-windres
> > > configure:1863: checking for arm-none-symbianelf-windres
> > > configure:2613: checking for gcc -pipe support
> > > configure:2662: checking for visibility(hidden) attribute
> > > configure:2686: checking for visibility pragma support
> > > configure:2739: checking for perl5
> > > configure:2739: checking for perl
> > > configure:5161: checking for dlopen in -ldl
> > > configure:5180: mwccsym2.exe -o conftest  -MD -nostdinc -O0 -inline off
> > > -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc
> > > -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i-
> > > -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant
> > > -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis
> > >   -include Symbian_OS_v9.1.hrh   conftest.c -ldl   1>&5
> > > mwccsym2.exe: No library file found matching 'libdl{.lib|.a}' or 'dl'
> > > 
> > > Errors caused tool to abort.
> > > configure: failed program was:
> > > #line 5169 "configure"
> > > #include "confdefs.h"
> > > /* Override any gcc2 internal prototype to avoid an error.  */
> > > /* We use char because int might match the return type of a gcc2
> > >     builtin and then its argument prototype would still apply.  */
> > > char dlopen();
> > > 
> > > int main() {
> > > dlopen()
> > > ; return 0; }
> > > configure:5240: checking whether mwccsym2.exe needs -traditional
> > > ./conftest.c: /c/cygwin/bin/Autoconf: No such file or directory
> > > ./conftest.c: /c/cygwin/bin/Autoconf: No such file or directory
> > > configure:5288: checking for lchown
> > > configure:5316: mwccsym2.exe -o conftest  -MD -nostdinc -O0 -inline off
> > > -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc
> > > -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i-
> > > -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant
> > > -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis
> > >   -include Symbian_OS_v9.1.hrh   conftest.c  1>&5
> > > (command-line defines):2: the file 'Symbian_OS_v9.1.hrh' cannot be opened
> > > conftest.c:5: the file 'assert.h' cannot be opened
> > > 
> > > Errors caused tool to abort.
> > > configure: failed program was:
> > > #line 5293 "configure"
> > > #include "confdefs.h"
> > > /* System header to define __stub macros and hopefully few prototypes,
> > >     which can conflict with char lchown(); below.  */
> > > #include <assert.h>
> > > /* Override any gcc2 internal prototype to avoid an error.  */
> > > /* We use char because int might match the return type of a gcc2
> > >     builtin and then its argument prototype would still apply.  */
> > > char lchown();
> > > 
> > > int main() {
> > > 
> > > /* The GNU C library defines this for functions which it implements
> > >     to always fail with ENOSYS.  Some functions are actually named
> > >     something starting with __ and the normal name is an alias.  */
> > > #if defined (__stub_lchown) || defined (__stub___lchown)
> > > choke me
> > > #else
> > > lchown();
> > > #endif
> > > 
> > > ; return 0; }
> > > configure:5288: checking for strerror
> > > configure:5316: mwccsym2.exe -o conftest  -MD -nostdinc -O0 -inline off
> > > -wchar_t off -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc
> > > -enum int -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i-
> > > -I$(VPATH) -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant
> > > -I$(SYMBIAN_SDK_PATH)Epoc32/include -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis
> > >   -include Symbian_OS_v9.1.hrh   conftest.c  1>&5
> > > (command-line defines):2: the file 'Symbian_OS_v9.1.hrh' cannot be opened
> > > conftest.c:5: the file 'assert.h' cannot be opened
> > > 
> > > Errors caused tool to abort.
> > > configure: failed program was:
> > > #line 5293 "configure"
> > > #include "confdefs.h"
> > > /* System header to define __stub macros and hopefully few prototypes,
> > >     which can conflict with char strerror(); below.  */
> > > #include <assert.h>
> > > /* Override any gcc2 internal prototype to avoid an error.  */
> > > /* We use char because int might match the return type of a gcc2
> > >     builtin and then its argument prototype would still apply.  */
> > > char strerror();
> > > 
> > > int main() {
> > > 
> > > /* The GNU C library defines this for functions which it implements
> > >     to always fail with ENOSYS.  Some functions are actually named
> > >     something starting with __ and the normal name is an alias.  */
> > > #if defined (__stub_strerror) || defined (__stub___strerror)
> > > choke me
> > > #else
> > > strerror();
> > > #endif
> > > 
> > > ; return 0; }
> > > configure:5396: checking for pthread_create in -lpthreads
> > > mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off
> > > -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int
> > > -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH)
> > > -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include
> > > -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh 
> > > -lpthreads  
> > > 
> > > Errors caused tool to abort.
> > > configure:5418: checking for pthread_create in -lpthread
> > > mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off
> > > -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int
> > > -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH)
> > > -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include
> > > -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh 
> > > -lpthread  
> > > 
> > > Errors caused tool to abort.
> > > configure:5440: checking for pthread_create in -lc_r
> > > mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off
> > > -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int
> > > -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH)
> > > -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include
> > > -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh 
> > > -lc_r  
> > > 
> > > Errors caused tool to abort.
> > > configure:5462: checking for pthread_create in -lc
> > > mwccsym2.exe -o dummy dummy.c  -MD -nostdinc -O0 -inline off -wchar_t off
> > > -align 4 -warnings on -w nohidevirtual,nounusedexpr -msgstyle gcc -enum int
> > > -str pool -exc ms -trigraphs on -nostderr -gccdep -cwd source -i- -I$(VPATH)
> > > -I$(SYMBIAN_SDK_PATH)Epoc32/include/variant -I$(SYMBIAN_SDK_PATH)Epoc32/include
> > > -I$(SYMBIAN_SDK_PATH)Epoc32/include/stdapis   -include Symbian_OS_v9.1.hrh  -lc 
> > > 
> > > Errors caused tool to abort.
> > > configure:5594: checking whether mwccsym2.exe accepts -pthread
> > > configure:5617: checking whether mwccsym2.exe accepts -pthreads
Guys, when replying to each other's comments, please don't quote more text
than you really must.  Thanks.
hi terry , 

  My env variable SYMBIAN_SDK_PATH is /d/Symbian/9.1/S60_3rd_MR/

   i checked it. It is ok.

  :-(   

   

(In reply to comment #48)
> Hi redpanda:
>   you would to check the env variable SYMBIAN_SDK_PATH:
>   this is my:
>   ===================================
>      /d/S60/devices/S60_3rd_FP2_SDK/
>   ===================================
>   be care of the leader "/" and the low case "d" not the "D"
> 
>   good luck
>
I'm repeating myself in other Symbian related bugs but I do believe it is important to mention that Symbian has two mayor dialects: S60 (Nokia) and, often forgotten, UIQ (SonyEricsson, Motorola).
Attached patch continue working on portings (obsolete) — Splinter Review
I'm very sorry for the delay of the porting works because of my busy Oct and Sept. In Aug and Sept I tried to verify patched ptio.c, and it was good. I also did some test cases run on more devices during last two months. This patch is made against the latest trunk (4.7.4 beta). It is tested on a N80 device. One tiny reminder, the unix.c has to remain patched as in this patch, or most of the test cases will fail with "panic" (unexpected error/exit) KERN-EXEC-3 (http://www.symbian.com/developer/techlib/v9.2docs/doc_source/reference/SystemPanics/KernExecPanics.html#Panics.kern-exec).
Attachment #324627 - Attachment is obsolete: true
Attachment #331916 - Attachment is obsolete: true
Attachment #349592 - Flags: review+
Attachment #331916 - Flags: review?(wtc)
Comment on attachment 349592 [details] [diff] [review]
continue working on portings

Welcome back.  I will take a look at the new patch.
Attachment #349592 - Flags: review+ → review?(wtc)
set platform to symbian
OS: Other → Symbian
Hardware: Other → All
(In reply to comment #53)
> (From update of attachment 349592 [details] [diff] [review])
> Welcome back.  I will take a look at the new patch.

Hi Wan-Teh,

Would you please have a review on the patch that had been made in last November? Thanks for your response~
Hi everyone. I am currently working in a project where we port an OSS POSIX-based component to Symbian OS and thought I could share some comments with you.

1)
I noticed that the patch contains some #ifdef __WINS__ and #ifdef __WINSCW__ diretives for the Symbian emulator. I think those macros might have slightly too generic names for a widely portable codebase such as this. I would put those parts within a block selected by

#if defined(SYMBIAN) && defined(__WINS__)
...
#endif

I also noticed that both __WINSCW__ and __WINS__ macros are used. Using __WINS__ would suffice for detecting Symbian emulator build, see http://www.symbian.com/developer/techlib/v9.1docs/doc_source/N10356/BuildTools/emulator/macros.html#buildguide%2eemul%2emacros.

2)
There are some #ifdefs for changing paths of test-related files to c:\data on SymbianOS. Maybe these could be handled more generically in the codebase by adding a new #ifdef called e.g. NSPR_TEST_TMP_FILES_PATH or similar to the Mozilla platform.

3)
Some non-const static constants could be changeable with reasonable effort to more Symbian-friendly const static data, e.g.
char *TEST_DIR = "c:\\data\\prsocket"; -> const char * const TEST_DIR = "c:\\data\\prsocket";
Harry, sorry about the lack of review.  I hope to get
back to this bug soon.  From end of November to end of
December, I worked on a JavaScript cross-compilation bug
exposed by an NSPR upgrade.  Recently I just finished
the review of a big WinCE patch (which was submitted
earlier than this bug).  This weekened I'm reviewing the
new random number generator in NSS.

Nelson, or any other Mozilla developer interested in
Symbian OS, please feel free to review Harry's patch.
Attachment #349592 - Flags: review?(nelson)
Attachment #349592 - Attachment description: continue woking on portings → continue working on portings
Attachment #349592 - Flags: review?(nelson) → review-
Comment on attachment 349592 [details] [diff] [review]
continue working on portings

r-
These review comments contain some questions for the submittor of this patch.  Please answer those questions before, or when, submitting the 
next version of this patch.

1. I see that a copy of NSPR which already bears this patch is already 
committed in some Google source repository.  For example, see 
http://code.google.com/p/mozilla-symbian/source/browse/trunk/nsprpub/pr/tests/sigpipe.c?spec=svn5&r=5

Submittor: are you actually the author of this patch? Or are you merely 
trying to take a patch that someone else has already been applied to another repository and "push it upstream"?  The real question is: will you be able 
to fix the problems described below?

2. Is it correct that Symbian is a Unix-like OS that uses Windows-like
file systems (e.g. drive letters, back slashes for directory separators)?
Or is the use of Windows style file pathnames only necessary in WINS, the 
Symbian emulator that runs on Windows?  Do Windows-style file pathnames 
work on native (not emulated) Symbian?  

3. Are the NSPR test programs ever going to be run on native symbian 
systems? or are they only run on WINS (the emulator)?

The answers to questions 2-3 have bearing on parts of the patch that
conditionally compile the path names to use Windows-style path names in otherwise pure-unix source files, such as this patch to 
pr/src/md/unix/uxshm.c

>-        genName = PR_smprintf( "%s/.NSPR-AFM-%d-%p.%d", 
>+#ifdef SYMBIAN
>+        genName = PR_smprintf( "%s\\NSPR-AFM-%d-%p.%d",
>+#else
>+        genName = PR_smprintf( "%s/.NSPR-AFM-%d-%p.%d",
>+#endif

Perhaps that should be 
#if defined(SYMBIAN) && defined(__WINS__)

Also, all the new lines that read 
#if defined(__WINS__)
should be changed to read 
#if defined(SYMBIAN) && defined(__WINS__)

4. Is the use of the drive letter "z" a standard thing on Symbian (as the
use of drive letter "C" is on Windows)?  Or is it merely a convention used
by the author of this patch?  

This question has bearing on the patch to pr/tests/op_filok.c

>-#elif XP_UNIX
>+#elif defined(SYMBIAN)
>+#define EXISTING_FILENAME "z:\\system\\install\\Series60v3.0.sis"
>+#elif defined (XP_UNIX)

5. In two places in file pr/src/misc/prnetdb.c, this patch attempts to 
insert the same block of code, which is:

>	{
>+#ifdef SYMBIAN
>+      /* In Symbian OS, getprotobyname() give NULL in servent.s_aliases */
>+        if (NULL == staticBuf->p_aliases)
>+        {
>+            char* aliases[2];
>+            if (NULL == strcmp(staticBuf->p_name, "ip"))
>+                aliases[0] = "IP";
>+            else if (NULL == strcmp(staticBuf->p_name, "tcp"))
>+                aliases[0] = "TCP";
>+            else if (NULL == strcmp(staticBuf->p_name, "udp"))
>+                aliases[0] = "UDP";
>+            else
>+                aliases[0] = "UNKNOWN";
>+            aliases[1] = NULL;
>+            staticBuf->p_aliases = aliases;
>+        }
>+#endif
>	  rv = CopyProtoent(staticBuf, buffer, buflen, result);

There are two problems with that code:
5a. The address of the array aliases is assigned to staticBuf->p_aliases 
but then the array aliases immediately goes out of scope, leaving 
staticBuf->p_aliases pointing to an array that is no longer in scope.
The solution is to move the declaration of the array aliases two lines 
up, to just before the preceding if statement.

5b. strcmp returns an int, not a pointer, so the results should be compared
to zero, not to NULL.  NULL is declared on some systems as ((void *)0)
and this patch would create warnings on those systems.

The fixes to those problems need to be applied in both of the two places
where that code is inserted.  Perhaps that code should be put into a new
static function in that file.

6. There is a comment about undeffing that merely states the obvious.
It should tell us WHY it is being undef'ed, and not merely that we are 
doing so, which is obvious.
>+#ifdef SYMBIAN
>+/* There is a _POSIX_THREAD_PRIORITY_SCHEDULING in unixtd.h in Symbian OS
>+ * include header files, so undef it here */
>+#undef _POSIX_THREAD_PRIORITY_SCHEDULING
>+#endif

7. There are places in the code where the code already conditionally 
compiled certain file names, and there are places where this patch 
introduces new conditional compilation of file names where there was none
before.  The old code used this style:

#if (condition)
#define FILENAME "some name"
#else
#define FILENAME "some other name"
#endif 
 ...
   some_statement(FILENAME)

The patch introduces a different style, which is:

#if (condition)
   some_statement("some name")
#else
   some_statement("some other name")
#endif

The old style should be used uniformly in all cases of conditional compilation
of file names.  

8. Removal of assertions!
In several test files, the code prior to this patch has a _MY_Assert 
function, the point of which is to have an assertion that works in both
DEBUG and non-DEBUG builds (unles the PR_ASSERT macro).  The conditions
that they are intended to detect are conditions that must cause failure,
and not only in debug builds.  This patch changes those functions, making 
them only work in DEBUG builds.  It defeats the whole purpose of the 
_MY_Assert function.  That's bad.  If the _MY_Assert function is asserting
then the cause of that should be fixed.

9.  Was there an attempt to compile NSPR with a C++ compiler?  
This patch inserts a lot new conditionally compiled code that adds 
explicit casts between void* and pointers of other types. For example:

>+#ifdef SYMBIAN
>+    addr = (char*)PR_AttachSharedMemory( shm , 0 );
>+#else
>     addr = PR_AttachSharedMemory( shm , 0 );
>+#endif

In all cases that I found of new casts in assignment statements, the cast
is correct in all cases, and therefore should not be ifdeffed.  IOW, the
above patch should be:

>-    addr = PR_AttachSharedMemory( shm , 0 );
>+    addr = (char*)PR_AttachSharedMemory( shm , 0 );

Please make that change in all places where you added casts in ASSIGNMENTS
(only).  Having said that, this patch also adds casts for passing pointers
to functions whose formal arguments are void *, e.g. 

>+#ifdef SYMBIAN
>+        rv = PR_SetThreadPrivate(key[keys], (void*)"EXTENSION");
>+#else
>         rv = PR_SetThreadPrivate(key[keys], "EXTENSION");
>+#endif

I object to that change.  That cast is unnecessary in c.  Indeed, the 
reason for the existence of the void * type is to avoid casts in that 
very situation, that is, to allow arguments to be passed to common 
functions, such as memcpy, without requiring casts for every invocation.  
If the compiler being used with Symbian is requiring that cast, then I 
submit that perhaps the wrong compiler is being used. NSPR is c, not c++.  

10. The patch to file pr/tests/prpoll.c must be made conditional.

>-	rv = getsockname(sd, (struct sockaddr *) &saddr, &saddr_len);
>+	rv = getsockname(sd, (struct sockaddr *) &saddr, (unsigned int*)&saddr_len);

That change is wrong for most platforms.  It must be ifdeffed. 
Also, it makes that line longer than 80 columns.  It must be folded.

11.  Extended comment line needs to be wrapped

>-#if defined(XP_MAC)
>+#if defined(XP_MAC) || defined(SYMBIAN)
> /*
>- * Mac does not scale well specially the requirement for thread stack
>+ * Mac and Symbian does not scale well specially the requirement for thread stack
>  * space and buffer allocation space.  It is easy to get into a fragmented
>  * memory and not be able to allocate thread stack or client/server data
>  * buffer.
>  */

The addition of some words to that line cause it to exceed 80 columns, so 
the block comment needs to be re-wrapped.  While you're at it, please fix
the other errors in that line.  It should read:

>+ * Mac and Symbian do not scale well, especially the requirement for 
                       ^              ^ ^
12. Introduction of different platform-dependent semantics for NSPR functions.
This is my single biggest problem with this patch.  It changes the semantics 
of certain NSPR functions to be platform dependent.  The whole point of NSPR 
is to eliminate those platform dependencies as much as possible.  So, the 
changes to the calls to PR_Accept in 
pr/tests/sendzlf.c
pr/tests/socket.c 
pr/tests/zerolen.c
are all unacceptable.  PR_Accept MUST be able to accept a NULL value for
the second argument on ALL platforms.  If the underlying OS accept 
function does not accept that, then that problem must be resolved inside 
of PR_Accept, not in any of the callers to PR_Accept.  

13. Finally, this patch does not apply cleanly to the tip of the NSPR CVS
trunk in Mozilla's repository.  Please ensure that the next patch does.

All the above issues must be addressed.  The most serious of them are 
numbers 5, 8, 10, 12 and 13.  Those affect code correctness the most.
Nelson, thanks a lot for reviewing this patch.  Harry Li is
the author of these patches.  The code.google.com repository
for "mozilla-symbian" that you found looks like a repository
that he's using to check in his work before it is accepted
by the Mozilla and NSPR teams.

I also want a better comment that explains why we need to
undefine _POSIX_THREAD_PRIORITY_SCHEDULING.  The
_POSIX_THREAD_PRIORITY_SCHEDULING macro is a "feature test"
macro.  It should only be defined if "the implementation
supports the thread execution scheduling option":
http://opengroup.org/onlinepubs/007908799/xsh/unistd.h.html

So when Symbian OpenC defines this macro but we can't use
the relevant functions, it means either 1) OpenC should not
define this macro, or 2) NSPR is not using the thread
execution scheduling functions correctly.  A good comment
will help someone resolve this problem in the future (or
tell him why it's not necessary to resolve).

(In reply to comment #58)
> 
> >-    addr = PR_AttachSharedMemory( shm , 0 );
> >+    addr = (char*)PR_AttachSharedMemory( shm , 0 );

I agree the change should be done this way, without #ifdef SYMBIAN.
Harry, could you doublecheck if you're using the C compiler to
compile NSPR?  The above code is a difference between C and C++.
The original code is legal in C, but in C++ it requires a typecast.
I'm fine with adding the (char*) typecast to avoid #ifdef SYMBIAN.
 
> >+#ifdef SYMBIAN
> >+        rv = PR_SetThreadPrivate(key[keys], (void*)"EXTENSION");
> >+#else
> >         rv = PR_SetThreadPrivate(key[keys], "EXTENSION");
> >+#endif

I also object to this change.  The (void*) typecast should be
unnecessary in both C and C++.  Harry, even if you're using a
C++ compiler to compile NSPR, the compiler should not require
us to add the (void*) typecast.
   
> 10. The patch to file pr/tests/prpoll.c must be made conditional.
> 
> >-	rv = getsockname(sd, (struct sockaddr *) &saddr, &saddr_len);
> >+	rv = getsockname(sd, (struct sockaddr *) &saddr, (unsigned int*)&saddr_len);
> 
> That change is wrong for most platforms.  It must be ifdeffed.

It's better to fix this by declaring the variable saddr_len
with the right type.  It's fine to use an ifdef there.  Use
the 'socklen_t' type, if it's available in Symbian OpenC.
    
> >+ * Mac and Symbian do not scale well, especially the requirement for 
>                        ^              ^ ^

Harry, could you also change "Mac" to "Mac OS Classic" when you
fix this comment?  Even better, just remove XP_MAC from the ifdef
and "Mac" from the comment (in which case the verb "does" should
stay unchanged).  Thanks.

Re: PR_Accept: we already took care of the PR_Accept problem:
http://mxr.mozilla.org/nspr/source/nsprpub/pr/src/pthreads/ptio.c#1668
So the test programs should be able to pass NULL as the second
argument to PR_Accept.
Two more comments:

1) In file pr/tests/testfile.c the patch uses conditional compilation to 
insert some casts for function pointer types.  I think those casts are 
always correct, and they appear to be needed, so I'd suggest just doing 
those without ifdefs.  

2) Regarding "Use the 'socklen_t' type, if it's available", I would add,
"... and if the prototype for getsockaddr declares that argument to be 
of that type".
Yes, getsockname takes socklen_t *address_len as the third argument:
http://www.opengroup.org/onlinepubs/009695399/functions/getsockname.html
Not on Windows.
Sorry, my suggestion in comment 59 wasn't clear.  Here is the
precise suggestion to Harry:

In pr/tests/prpoll.c, solve the getsockname problem by declaring
the variable saddr_len with the right type.  It is fine to use
ifdef when you declare saddr_len:

#ifdef SYMBIAN
    unsigned int saddr_len;
#else
    PRIntn saddr_len;
#endif

But since the 'socklen_t' type is available in Symbian OpenC
(as shown by your patch in bug 442706), it is better to use
'socklen_t' than 'unsigned int' for saddr_len:

#ifdef HAVE_SOCKLEN_T
    socklen_t saddr_len;
#else
    PRIntn saddr_len;
#endif
I will post my commentary first and then patch file will be posted after testing on a Symbian phone.

(In reply to comment #58)
> (From update of attachment 349592 [details] [diff] [review])
> r-
> These review comments contain some questions for the submittor of this patch. 
> Please answer those questions before, or when, submitting the 
> next version of this patch.
> 
> 1. I see that a copy of NSPR which already bears this patch is already 
> committed in some Google source repository.  For example, see 
> http://code.google.com/p/mozilla-symbian/source/browse/trunk/nsprpub/pr/tests/sigpipe.c?spec=svn5&r=5
> 
> Submittor: are you actually the author of this patch? Or are you merely 
> trying to take a patch that someone else has already been applied to another
> repository and "push it upstream"?  The real question is: will you be able 
> to fix the problems described below?
> 

This is my working and I will correct all problems here :)

> 2. Is it correct that Symbian is a Unix-like OS that uses Windows-like
> file systems (e.g. drive letters, back slashes for directory separators)?
> Or is the use of Windows style file pathnames only necessary in WINS, the 
> Symbian emulator that runs on Windows?  Do Windows-style file pathnames 
> work on native (not emulated) Symbian?  
> 

Symbian is not a Unix-like OS. We use UNIX branch only because Symbian provides POSIX interface which reduces porting codes and increases clarity. But it uses windows-style file path names on both emulator(WINS) and target device(physical phone).

> 3. Are the NSPR test programs ever going to be run on native symbian 
> systems? or are they only run on WINS (the emulator)?
> 

The test cases are run on Symbian systems since last June, and my patches were submitted only after target device testing.

> The answers to questions 2-3 have bearing on parts of the patch that
> conditionally compile the path names to use Windows-style path names in
> otherwise pure-unix source files, such as this patch to 
> pr/src/md/unix/uxshm.c
> 
> >-        genName = PR_smprintf( "%s/.NSPR-AFM-%d-%p.%d", 
> >+#ifdef SYMBIAN
> >+        genName = PR_smprintf( "%s\\NSPR-AFM-%d-%p.%d",
> >+#else
> >+        genName = PR_smprintf( "%s/.NSPR-AFM-%d-%p.%d",
> >+#endif
> 
> Perhaps that should be 
> #if defined(SYMBIAN) && defined(__WINS__)
> 
> Also, all the new lines that read 
> #if defined(__WINS__)
> should be changed to read 
> #if defined(SYMBIAN) && defined(__WINS__)
> 

In pr/src/md/unix/uxshm.c the "#ifdef SYMBIAN" case works for both emulator and target device.

> 4. Is the use of the drive letter "z" a standard thing on Symbian (as the
> use of drive letter "C" is on Windows)?  Or is it merely a convention used
> by the author of this patch?  
> 
> This question has bearing on the patch to pr/tests/op_filok.c
> 
> >-#elif XP_UNIX
> >+#elif defined(SYMBIAN)
> >+#define EXISTING_FILENAME "z:\\system\\install\\Series60v3.0.sis"
> >+#elif defined (XP_UNIX)
> 

It is a standard. Z means ROM drive where the OS resident on a Symbian phone(C=onboard flash memory, E=memory card). I saw this test is going to verify a file's existence, so in this case we can probably only guarantee this file's existence because a Symbian phone's software system uses this file to identify its version.

> 5. In two places in file pr/src/misc/prnetdb.c, this patch attempts to 
> insert the same block of code, which is:
> 
> >	{
> >+#ifdef SYMBIAN
> >+      /* In Symbian OS, getprotobyname() give NULL in servent.s_aliases */
> >+        if (NULL == staticBuf->p_aliases)
> >+        {
> >+            char* aliases[2];
> >+            if (NULL == strcmp(staticBuf->p_name, "ip"))
> >+                aliases[0] = "IP";
> >+            else if (NULL == strcmp(staticBuf->p_name, "tcp"))
> >+                aliases[0] = "TCP";
> >+            else if (NULL == strcmp(staticBuf->p_name, "udp"))
> >+                aliases[0] = "UDP";
> >+            else
> >+                aliases[0] = "UNKNOWN";
> >+            aliases[1] = NULL;
> >+            staticBuf->p_aliases = aliases;
> >+        }
> >+#endif
> >	  rv = CopyProtoent(staticBuf, buffer, buflen, result);
> 
> There are two problems with that code:
> 5a. The address of the array aliases is assigned to staticBuf->p_aliases 
> but then the array aliases immediately goes out of scope, leaving 
> staticBuf->p_aliases pointing to an array that is no longer in scope.
> The solution is to move the declaration of the array aliases two lines 
> up, to just before the preceding if statement.
> 
> 5b. strcmp returns an int, not a pointer, so the results should be compared
> to zero, not to NULL.  NULL is declared on some systems as ((void *)0)
> and this patch would create warnings on those systems.
> 
> The fixes to those problems need to be applied in both of the two places
> where that code is inserted.  Perhaps that code should be put into a new
> static function in that file.
> 

Fix will be submitted with patch file.

> 6. There is a comment about undeffing that merely states the obvious.
> It should tell us WHY it is being undef'ed, and not merely that we are 
> doing so, which is obvious.
> >+#ifdef SYMBIAN
> >+/* There is a _POSIX_THREAD_PRIORITY_SCHEDULING in unixtd.h in Symbian OS
> >+ * include header files, so undef it here */
> >+#undef _POSIX_THREAD_PRIORITY_SCHEDULING
> >+#endif
> 

New comment will be submitted with patch file.

> 7. There are places in the code where the code already conditionally 
> compiled certain file names, and there are places where this patch 
> introduces new conditional compilation of file names where there was none
> before.  The old code used this style:
> 
> #if (condition)
> #define FILENAME "some name"
> #else
> #define FILENAME "some other name"
> #endif 
>  ...
>    some_statement(FILENAME)
> 
> The patch introduces a different style, which is:
> 
> #if (condition)
>    some_statement("some name")
> #else
>    some_statement("some other name")
> #endif
> 
> The old style should be used uniformly in all cases of conditional compilation
> of file names.  
> 

Fix will be submitted with patch file.

> 8. Removal of assertions!
> In several test files, the code prior to this patch has a _MY_Assert 
> function, the point of which is to have an assertion that works in both
> DEBUG and non-DEBUG builds (unles the PR_ASSERT macro).  The conditions
> that they are intended to detect are conditions that must cause failure,
> and not only in debug builds.  This patch changes those functions, making 
> them only work in DEBUG builds.  It defeats the whole purpose of the 
> _MY_Assert function.  That's bad.  If the _MY_Assert function is asserting
> then the cause of that should be fixed.
> 

Fix will be submitted with patch file.

> 9.  Was there an attempt to compile NSPR with a C++ compiler?  
> This patch inserts a lot new conditionally compiled code that adds 
> explicit casts between void* and pointers of other types. For example:
> 
> >+#ifdef SYMBIAN
> >+    addr = (char*)PR_AttachSharedMemory( shm , 0 );
> >+#else
> >     addr = PR_AttachSharedMemory( shm , 0 );
> >+#endif
> 
> In all cases that I found of new casts in assignment statements, the cast
> is correct in all cases, and therefore should not be ifdeffed.  IOW, the
> above patch should be:
> 
> >-    addr = PR_AttachSharedMemory( shm , 0 );
> >+    addr = (char*)PR_AttachSharedMemory( shm , 0 );
> 
> Please make that change in all places where you added casts in ASSIGNMENTS
> (only).  Having said that, this patch also adds casts for passing pointers
> to functions whose formal arguments are void *, e.g. 
> 
> >+#ifdef SYMBIAN
> >+        rv = PR_SetThreadPrivate(key[keys], (void*)"EXTENSION");
> >+#else
> >         rv = PR_SetThreadPrivate(key[keys], "EXTENSION");
> >+#endif
> 
> I object to that change.  That cast is unnecessary in c.  Indeed, the 
> reason for the existence of the void * type is to avoid casts in that 
> very situation, that is, to allow arguments to be passed to common 
> functions, such as memcpy, without requiring casts for every invocation.  
> If the compiler being used with Symbian is requiring that cast, then I 
> submit that perhaps the wrong compiler is being used. NSPR is c, not c++.  
> 

This problem has been solved by now though not submitted as patch. The reason is that I was porting NSPR with original Nokia IDE which gives me only c++ compiler. Now I am using the gnu make build system, all additional type casts are omitted.

> 10. The patch to file pr/tests/prpoll.c must be made conditional.
> 
> >-	rv = getsockname(sd, (struct sockaddr *) &saddr, &saddr_len);
> >+	rv = getsockname(sd, (struct sockaddr *) &saddr, (unsigned int*)&saddr_len);
> 
> That change is wrong for most platforms.  It must be ifdeffed. 
> Also, it makes that line longer than 80 columns.  It must be folded.
> 

According to this testing script 
http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/tests/runtests.pl ,
prpoll is never called. So I think this is probably a mistake that I made unnecessary change to an unwanted test case. If not, please inform me.

> 11.  Extended comment line needs to be wrapped
> 
> >-#if defined(XP_MAC)
> >+#if defined(XP_MAC) || defined(SYMBIAN)
> > /*
> >- * Mac does not scale well specially the requirement for thread stack
> >+ * Mac and Symbian does not scale well specially the requirement for thread stack
> >  * space and buffer allocation space.  It is easy to get into a fragmented
> >  * memory and not be able to allocate thread stack or client/server data
> >  * buffer.
> >  */
> 
> The addition of some words to that line cause it to exceed 80 columns, so 
> the block comment needs to be re-wrapped.  While you're at it, please fix
> the other errors in that line.  It should read:
> 
> >+ * Mac and Symbian do not scale well, especially the requirement for 
>                        ^              ^ ^

Fix will be submitted with patch file.

> 12. Introduction of different platform-dependent semantics for NSPR functions.
> This is my single biggest problem with this patch.  It changes the semantics 
> of certain NSPR functions to be platform dependent.  The whole point of NSPR 
> is to eliminate those platform dependencies as much as possible.  So, the 
> changes to the calls to PR_Accept in 
> pr/tests/sendzlf.c
> pr/tests/socket.c 
> pr/tests/zerolen.c
> are all unacceptable.  PR_Accept MUST be able to accept a NULL value for
> the second argument on ALL platforms.  If the underlying OS accept 
> function does not accept that, then that problem must be resolved inside 
> of PR_Accept, not in any of the callers to PR_Accept.  
> 

Fix will be submitted with patch file. If it needs more time, maybe I will split this into another submit or a new bug.

> 13. Finally, this patch does not apply cleanly to the tip of the NSPR CVS
> trunk in Mozilla's repository.  Please ensure that the next patch does.
> 
> All the above issues must be addressed.  The most serious of them are 
> numbers 5, 8, 10, 12 and 13.  Those affect code correctness the most.


After all, thanks for reviewing this. If this commentary reply is OK with you, next time (probably with new patch), I will target on problem 5,6,7,8,9,11,12, of course against the latest CVS trunk.


To Wan-Teh Chang:

I think your comment will be solved when above problems are patched in next submit. However in my reply I am not so sure we could omit "prpoll" test. Please wait for my updated patch when all settled.
Thank you for your answers, Harry.  I look forward to your next patch.
Here is the patch with all fixes according to last review except for test cases cause they are still under cleaning up. This latest patch, which is diffed against current HG trunk, solves problem 5,6,7,8,9,11,12 in comment #58. For 8th problem, I just passed the abort() call in PR_Assert() cause Symbian does not support signal related functions.
Tomorrow I will submit a more cleaning patch which solves all problems under nsprpub/pr/tests and three new files as test script in Symbian phone.
This patch has been tested working on a N73 symbian phone.
Attachment #349592 - Attachment is obsolete: true
Attachment #364326 - Flags: review?(ted.mielczarek)
Attachment #349592 - Flags: review?(wtc)
Harry, please submit your patch as a CVS patch against the CVS tip.
The way that this patch will get applied, when it is finally given a 
positive review, is that it will be applied to the CVS trunk, because
the CVS repository is THE master upstream repository, and the hg repository
is downstread from the CVS repositoiry.  So changes are made to the master
CVS repository, and then snapshots of the CVS repository are committed into
the HG repository.  Because changes get made to the CVS repository first, 
and are not always immediately applied to the hg repository, the two 
repositories get out of sync.  That means that a patch against the Hg tip
may not apply cleanly to the CVS trunk.  As an NSPR module owner, I require
patches to apply cleanly to the CVS trunk, regardless of who reviews them.  
So, please resubmit your patch as a patch against the CVS trunk.  Thanks.
Attached patch updated against CVS HEAD (obsolete) — Splinter Review
This is based on CVS trunk now, and content is the same as last one.
Attachment #364326 - Attachment is obsolete: true
Attachment #364326 - Flags: review?(ted.mielczarek)
Attachment #364463 - Flags: review?(ted.mielczarek)
Attachment #364463 - Attachment is patch: true
Attachment #364463 - Attachment mime type: application/octet-stream → text/plain
this test cases caller program is written as a standard symbian console application which has an entry point on a Symbian/S60 phone's UI. it is made with the purpose of providing a generic test cases calling method. a test cases calling script file could be defined like this:

0 nspr_tests_gethost.exe -d -v
0 nspr_tests_accept.exe -d -v
0 nspr_tests_acceptread.exe 
0 nspr_tests_acceptreademu.exe 

Format:expected return value<SPACE>executable name<SPACE>optional arguments
Attachment #364648 - Flags: review?(ted.mielczarek)
Test cases source patch against CVS HEAD. All tested on Nokia N73 (Symbian/S60) phone. A pr/src/md/unix/unix.c patching line included here cause attachment 364463 [details] [diff] [review] missed this.
see test cases result at http://spreadsheets.google.com/ccc?key=puHMGxziDYnMi1x6iShmfQw
Attachment #364649 - Flags: review?(ted.mielczarek)
Attachment #364463 - Flags: review?(ted.mielczarek) → review?(nelson)
Comment on attachment 364463 [details] [diff] [review]
updated against CVS HEAD

Hi Nelson, would you please have this patch reviewed? Thanks very much.
Attachment #364648 - Flags: review?(ted.mielczarek) → review?(nelson)
Attachment #364649 - Flags: review?(ted.mielczarek) → review?(nelson)
Comment on attachment 364463 [details] [diff] [review]
updated against CVS HEAD

Harry, Is this patch complete?
Like the previous version of this patch that I reviewed, this patch tries to 
modify 5 files in mozilla/nsprpub/pr/src, but they're not the same 5 files.

  Old patch             New patch
  --------------------  -----------------
  md/unix/unix.c        io/prlog.c              <not same>
  md/unix/uxproces.c    md/unix/uxproces.c    
  md/unix/uxshm.c       md/unix/uxshm.c       
  misc/prnetdb.c        misc/prnetdb.c
  pthreads/ptthread.c   pthreads/ptthread.c

Did you intend to omit the patch to unix.c ?
(In reply to comment #72)
> (From update of attachment 364463 [details] [diff] [review])
> Harry, Is this patch complete?
> Like the previous version of this patch that I reviewed, this patch tries to 
> modify 5 files in mozilla/nsprpub/pr/src, but they're not the same 5 files.
> 
>   Old patch             New patch
>   --------------------  -----------------
>   md/unix/unix.c        io/prlog.c              <not same>
>   md/unix/uxproces.c    md/unix/uxproces.c    
>   md/unix/uxshm.c       md/unix/uxshm.c       
>   misc/prnetdb.c        misc/prnetdb.c
>   pthreads/ptthread.c   pthreads/ptthread.c
> 
> Did you intend to omit the patch to unix.c ?

The patch for unix.c is missing in attachment 364463 [details] [diff] [review], and it was added in attachment 364649 [details] [diff] [review] as you could see in comment #70 . Also, the io/prlog.c is a newly added one.
Comment on attachment 364463 [details] [diff] [review]
updated against CVS HEAD

I am going to review this patch in pieces.  Please do not submit a 
new version of the patch until I have reviewed all the pieces.  

r- for the patch to io/prlog.c

It changes the functions PR_Abort and PR_Assert so that they are no-ops,
and return without interrupting the flow of program execution.  

The purpose of these functions is to cause the program to fail, utterly.
Crash, stop, write core, invoke the debugger, display an ugly dialog, 
or whatever is appropriate for your system, but not to simply have no 
effect.  Changing these functions to have no effect will not be acceptable.
Comment on attachment 364463 [details] [diff] [review]
updated against CVS HEAD

r- for patch to file md/unix/uxproces.c

- the new #endif being put into function _MD_KillUnixProcess should come
at the end of the function.  Otherwise, all the code in that function 
after that endif is dead code.

r+ for the patch to md/unix/uxshm.c
r+ for the patch to misc/prnetdb.c

r- for the patch to pthreads/ptthread.c

- In function init_pthread_gc_support(void), the declaration of 
    PRIntn rv;
should also be inside of #ifndef SYMBIAN. Otherwise, it will be an 
unused variable on that platform.

- The patch to pt_SuspendSet will cause an assertion failure because 
rv is not initialized.  

This completes my review of this patch (Attachment 364463 [details] [diff])
Attachment #364463 - Flags: review?(nelson) → review-
Comment on attachment 364648 [details] [diff] [review]
nspr symbian test cases caller source files

Harry, 
I gather that these last two patches, 
attachment 364648 [details] [diff] [review] and attachment 364649 [details] [diff] [review], 
are to be treated as one patch.  Yes?

Isn't there a change required to pr/tests/Makefile.in  
to add the new files to the list of CSRCS ?

I don't see such a change in either of these patches.  
But I will continue to review these patches.  
Please do not submit any new patch (for these files) 
until I have completed the reviews of these attachments.
Attachment #364648 - Flags: review?(nelson) → review?
Comment on attachment 364648 [details] [diff] [review]
nspr symbian test cases caller source files

I lack the knowledge of the Symbian programming environment to 
properly review the code in these new files.  However, since they
presumably affect only one platform, I am willing to approve and 
commit them once 
a) any Makefile.in issues are resolved, and 
b) if you get any other Symbian programmer whom you regard as a 
Symbian peer to add a comment giving a positive review tot them, and
c) the following issue is resolved:

Since these are brand new files, and (apparently) do not take/include 
any old code previously in NSPR, the license boilerplate for the file 
symbian_tests_uid.mk should not give copyright ownership to Netscape 
and should not claim that the copyright extends from 1998-2000.  

Please add a line listing yourself as a contributor in the contributor
section of each affected file.
Comment on attachment 364648 [details] [diff] [review]
nspr symbian test cases caller source files

Oh, also, regarding this patch, If/when you create a new version of this patch, please make it a CVS diff against the CVS trunk of NSPR.  Thanks.
Attachment 364694 [details] does not apply cleanly.  In fact, it puts the patch 
program on my box into an infinite loop.  THe problem is that it was
created to look as if all the files being patched are in the same directory,
but they are not.  One is in a different directory.

This patch is the same as the previous one except for all the Index: lines
which I have corrected.  This patch applies cleanly to the CVS tip. 
I will review it.
Attachment #364649 - Attachment is obsolete: true
Attachment #367962 - Flags: review?(nelson)
Attachment #364649 - Flags: review?(nelson)
Comment on attachment 367962 [details] [diff] [review]
nspr symbian test cases source patch (clean CVS patch) (checked in)

Harry,  You really cleaned up this patch a lot!  Thanks!
There's just one small problem with this version, a single
line that I believe is wrong in this patch.  It's in file 
>Index: pr/tests/stack.c

> int main(int argc, char **argv)
> {
>+#if defined(SYMBIAN) && !defined(__WINS__)
>     PRInt32 rv, cnt, sum;
> 	DataRecord	*Item;

That change will turn function main into a no-op on all 
platforms except Symbian non-WINS builds.  

I think what you wanted was 

#if !(defined(SYMBIAN) && defined(__WINS__)) 

or perhaps

#if !defined(SYMBIAN) || !defined(__WINS__)

Rather than have you submit another patch for that one line
change, if you agree to it, I will just make that one line 
change, give it r+ and commit this patch.  

Is that OK with you?
(In reply to comment #80)
> (From update of attachment 367962 [details] [diff] [review])
> Harry,  You really cleaned up this patch a lot!  Thanks!
> There's just one small problem with this version, a single
> line that I believe is wrong in this patch.  It's in file 
> >Index: pr/tests/stack.c
> 
> > int main(int argc, char **argv)
> > {
> >+#if defined(SYMBIAN) && !defined(__WINS__)
> >     PRInt32 rv, cnt, sum;
> > 	DataRecord	*Item;
> 
> That change will turn function main into a no-op on all 
> platforms except Symbian non-WINS builds.  
> 
> I think what you wanted was 
> 
> #if !(defined(SYMBIAN) && defined(__WINS__)) 
> 
> or perhaps
> 
> #if !defined(SYMBIAN) || !defined(__WINS__)
> 
> Rather than have you submit another patch for that one line
> change, if you agree to it, I will just make that one line 
> change, give it r+ and commit this patch.  
> 
> Is that OK with you?

I agree with this. Thanks very much for your clean up on this patch. I believe that line in stack.c is incorrect too. Changing it to 

#if !(defined(SYMBIAN) && defined(__WINS__)) 

will be OK, though not tested at this moment.

About other comments, I will modify sources to satisfy those functionality requirements.
Attachment #367962 - Flags: review?(nelson) → review+
Comment on attachment 367962 [details] [diff] [review]
nspr symbian test cases source patch (clean CVS patch) (checked in)

OK, so r+ for this patch with the one-line change I proposed above.

It appears to me that this patch does not depend on either of the other patches in this bug.  That is, it appears to me that it can be checked in now without breaking any platform except (possibly) Symbian.  
Harry, do you agree with that assessment?
Is there any reason for me NOT to commit this patch now?
(In reply to comment #82)
> (From update of attachment 367962 [details] [diff] [review])
> OK, so r+ for this patch with the one-line change I proposed above.
> 
> It appears to me that this patch does not depend on either of the other patches
> in this bug.  That is, it appears to me that it can be checked in now without
> breaking any platform except (possibly) Symbian.  
> Harry, do you agree with that assessment?
> Is there any reason for me NOT to commit this patch now?

I think if these patches to pr/tests won't bother other platforms, we have no reason to wait :)
Comment on attachment 367962 [details] [diff] [review]
nspr symbian test cases source patch (clean CVS patch) (checked in)

accept.c;        new revision: 3.14; previous revision: 3.13
acceptread.c;    new revision: 1.10; previous revision: 1.9
acceptreademu.c; new revision: 3.7;  previous revision: 3.6
bigfile.c;       new revision: 3.11; previous revision: 3.10
foreign.c;       new revision: 3.16; previous revision: 3.15
nameshm1.c;      new revision: 3.7;  previous revision: 3.6
nonblock.c;      new revision: 3.11; previous revision: 3.10
op_filok.c;      new revision: 3.13; previous revision: 3.12
pipeself.c;      new revision: 3.11; previous revision: 3.10
prpollml.c;      new revision: 3.10; previous revision: 3.9
sel_spd.c;       new revision: 3.17; previous revision: 3.16
selintr.c;       new revision: 3.8;  previous revision: 3.7
semaerr.c;       new revision: 3.8;  previous revision: 3.7
semaerr1.c;      new revision: 3.8;  previous revision: 3.7
semaping.c;      new revision: 3.10; previous revision: 3.9
semapong.c;      new revision: 3.10; previous revision: 3.9
server_test.c;   new revision: 3.13; previous revision: 3.12
servr_kk.c;      new revision: 3.15; previous revision: 3.14
servr_ku.c;      new revision: 3.14; previous revision: 3.13
servr_uk.c;      new revision: 3.14; previous revision: 3.13
servr_uu.c;      new revision: 3.14; previous revision: 3.13
sigpipe.c;       new revision: 3.12; previous revision: 3.11
socket.c;        new revision: 3.21; previous revision: 3.20
sockopt.c;       new revision: 3.15; previous revision: 3.14
stack.c;         new revision: 3.9;  previous revision: 3.8
testfile.c;      new revision: 3.20; previous revision: 3.19
zerolen.c;       new revision: 3.8;  previous revision: 3.7
Attachment #367962 - Attachment description: nspr symbian test cases source patch (clean CVS patch) → nspr symbian test cases source patch (clean CVS patch) (checked in)
Comment on attachment 367962 [details] [diff] [review]
nspr symbian test cases source patch (clean CVS patch) (checked in)

Harry, I did not commit the change to pr/src/md/unix/unix.c
with this patch, since it is not a change to pr/tests.
Please include the patch for that file in your next revision of
your patch for the rest of NSS.  Thanks.
Comment on attachment 367962 [details] [diff] [review]
nspr symbian test cases source patch (clean CVS patch) (checked in)

If the change to unix.c is necessary for Symbian OS, we should
try to make that change without #ifdef SYMBIAN because it shows
the = { open } initializer in the original code is both non-portable
and unnecessary.
Modified sources with guidance in comment #75
Test cases caller patches will be submitted later in another patch.
Attachment #364463 - Attachment is obsolete: true
Attachment #368671 - Flags: review?(nelson)
Comment on attachment 368671 [details] [diff] [review]
nspr-symbian sources patch (Checked in)

Harry,
This version of the patch to unix.c does not include the line 
#undef _POSIX_THREAD_PRIORITY_SCHEDULING

Is that omission intentional?
Is it no longer necessary?
(In reply to comment #88)
> (From update of attachment 368671 [details] [diff] [review])
> Harry,
> This version of the patch to unix.c does not include the line 
> #undef _POSIX_THREAD_PRIORITY_SCHEDULING
> 
> Is that omission intentional?
> Is it no longer necessary?

this line should be in "pthreads/ptthread.c", and it has been checked into the tree already. (http://mxr.mozilla.org/mozilla/source/nsprpub/pr/src/pthreads/ptthread.c)
Comment on attachment 368671 [details] [diff] [review]
nspr-symbian sources patch (Checked in)

md/unix/unix.c;         new revision: 3.54; previous revision: 3.53
md/unix/uxproces.c;     new revision: 3.23; previous revision: 3.22
md/unix/uxshm.c;        new revision: 3.13; previous revision: 3.12
misc/prnetdb.c;         new revision: 3.58; previous revision: 3.57
pthreads/ptthread.c;    new revision: 3.82; previous revision: 3.81
Attachment #368671 - Attachment description: nspr-symbian sources patch → nspr-symbian sources patch (Checked in)
Attachment #368671 - Flags: review?(nelson) → review+
Comment on attachment 364648 [details] [diff] [review]
nspr symbian test cases caller source files

This patch contains 3 new files, and reviewing it seems to me to require more knowledge of Symbian than of NSPR. 
Brad Lassey has experience with both, and has offered to review this patch.  

Thanks Brad.  I won't add you to the CC list, but of course, free free to add yourself.
Attachment #364648 - Flags: review? → review?(bugmail)
Comment on attachment 364648 [details] [diff] [review]
nspr symbian test cases caller source files

Brad Lassey:  Ping ?
Nelson, Christian told me that this wasn't a priority for the Symbian effort, so I've back burnered the review (its a big patch).  I do hope to get through it soon-ish though.
A quick meta comment though.... I think it would be better to have the test harness written in python than native Symbian.  That way it would be useful to more platforms that just Symbian.
Blocks: 491441
please be aware that comment 86 broke NSPR_LOG_MODULES on all unix platforms.
timeless, thanks a lot for tracking down the crash.

Harry, could you Symbian's compiler error messages for
mozilla/nsprpub/pr/src/md/unix/unix.c if we don't have
the ifdef SYMBIAN change?
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/pr/src/md/unix/unix.c&rev=3.56&mark=2652-2654,2656#2650

We now know why _md_iovector has to be initialized to
{ open }, so we need to make that work on Symbian OS.
(In reply to comment #96)
> timeless, thanks a lot for tracking down the crash.
> 
> Harry, could you Symbian's compiler error messages for
> mozilla/nsprpub/pr/src/md/unix/unix.c if we don't have
> the ifdef SYMBIAN change?
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/pr/src/md/unix/unix.c&rev=3.56&mark=2652-2654,2656#2650
> 
> We now know why _md_iovector has to be initialized to
> { open }, so we need to make that work on Symbian OS.

The compiler will give a successful build on unix.c if we use "struct _MD_IOVector _md_iovector = { open };". But as stated in comment #52, some of result test cases will give "KERN-EXEC 3 Panic" which is explained as null pointer error. If needed, I will build all test cases later and see if the result remains same as last winter.
I see.  If there is no compilation error, this is harder to
deal with.  You can try editing mozilla/nsprpub/pr/include/md/_unixos.h
and change the _MD_Open64 typedef to match the prototype of 'open'
exactly on Symbian OS:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/pr/include/md/_unixos.h&rev=3.40&mark=618#618

The current definition matches the prototype specified in Single
Unix Specification:
http://www.opengroup.org/onlinepubs/000095399/functions/open.html

But Symbian's declaration of 'open' may be slightly different or
may have a calling convention specifier.
Harry, is it possible to have the test harness written in python (or use the existing perl script)?
(In reply to comment #99)
> Harry, is it possible to have the test harness written in python (or use the
> existing perl script)?

I'm sorry for such a long silence cause. Actually writing a python script doing the test cases invoking is possible. However, this needs another runtime environment. I don't know if this brings inconvenience or not. You could find helpful information here http://wiki.opensource.nokia.com/projects/PyS60 . If a script is needed, maybe I could start it later next week.
(In reply to comment #100)
as I said in comment #94, I think a script that could be used cross platform would be preferable.  But, I suppose that is more a question for the nspr owners.

You might want to try using the existing perl script using the s60 perl run time http://opensource.nokia.com/projects/symbian-perl/index.html
At this moment, I think this bug has almost reach its life-cycle. Only the test scripts is left. I think it's better to open that problem in a new bug to reduce the redundant information discussed in this bug. If everybody is OK with this, I will mark as resolved later today.
Harry, if you want to open a new bug for the two proposed new test files,
and mark this bug resolved, that's fine with me.
bug 501172 will address the rest of this bug.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Attachment #364648 - Flags: review?(bugmail) → review-
You need to log in before you can comment on or make changes to this bug.