singularity 2.0 build fail

Mar 25, 2009 at 5:08 AM

Hi,

I am trying to build singularity 2, with a tiny project configuration. However, the build failed. Here is the message.
According to the message, something weird happened with the source EvProcessor.cs. What is that?

M:\Singularity RDK 2.0 Source\base>msb Distro\Tiny.proj
Using 32-bit MSBuild from .NET Framework 3.5
creating log dir - M:\Singularity RDK 2.0 Source\base.obj\MSBuildLogs
CompileBootPrograms:
   Assembling: Fat32_BS.asm
  @
CompileBootPrograms:
   Assembling: Fat16_BS.asm
  @
CompileBootPrograms:
   Assembling: Etfs_BS.asm
  @
CompileBootPrograms:
   Assembling: UsbFat16_BS.asm
  @
BuildEntry16:
   Assembling: blentry16.asm
  @
Singularity\Eventing\EvProcessor.cs(303,5): error CS1585: Member modifier 'public' must precede the member type and nam
e
Singularity\Eventing\EvProcessor.cs(304,1): error CS1519: Invalid token '?' in class, struct, or interface member decla
ration
Singularity\Eventing\EvProcessor.cs(305,7): error CS1585: Member modifier 'public' must precede the member type and nam
e
Singularity\Eventing\EvProcessor.cs(306,5): error CS1519: Invalid token '}' in class, struct, or interface member decla
ration
M:\Singularity RDK 2.0 Source\base\Targets\SingSharp.targets(509,5): error MSB3073: The command ""M:\Singularity RDK 2.
0 Source\base\Build\csc.exe" /out:"M:\Singularity RDK 2.0 Source\base.obj\Kernel\Debug.x86.ApicMP.Min.Concurrent.msil\k
ernel.exe" /t:exe /nologo /debug /noconfig /d:SINGULARITY_KERNEL;ENDPOINT_STRUCT;_NEW_CLASSLOADER;SINGULARITY_STACK_CHE
CKS;CONCURRENT_MS_COLLECTOR /warn:2 /warnaserror+ /nowarn:444,465,1699,3019,3021,169,649,436 /unsafe /d:DEBUG;TRACING;W
AYPOINTS;CHANNEL_COUNT /d:ISA_IX;ISA_IX86;LITTLE_ENDIAN;PTR_SIZE_32 /nostdlib /d:SINGULARITY /d:SINGULARITY_MP /d:WAYPO
INTS /d:MONITORING /doc:"M:\Singularity RDK 2.0 Source\base.obj\Kernel\Debug.x86.ApicMP.Min.Concurrent.msil\kernel.xml"
  /debug @"M:\Singularity RDK 2.0 Source\base.obj\Kernel\Debug.x86.ApicMP.Min.Concurrent.msil\kernel.rsp"" exited with
code 1.
Wall time elapsed: 00:00:20 (User: 00:00:15, Kernel: 00:00:02)
Total processes:         61
Page faults:         135774
  M:\Singularity RDK 2.0 Source\base.obj\MSBuildLogs\20090325-01054539.log

Build FAILED

Mar 25, 2009 at 5:11 AM
By the way, just tried with the older version (1.1) of singularity.
Tiny succeeds.
Mar 25, 2009 at 5:40 AM
Guys, it works now.

There are some weird characters in the original source file of Singularity/Kernel/Eventing/EvProcessor.cs

Specifically, if you use an Emacs editor (rather than Notepad), you will see the underlined, undisplayable characters around line 303.
They are marked by red lines.
Delete them.

And the Tiny build works now. Trying with World.

Go to here to see what I am saying. 

http://mysbfiles.stonybrook.edu/~wang8/weird.jpg
Mar 25, 2009 at 6:15 AM
Follow-up: World build succeeds.
Mar 25, 2009 at 4:44 PM
Hi,

I would like to add that under some circumstances (like IE6 started) your build may fail.

All the best,
Alex.
Mar 25, 2009 at 4:47 PM
What do you mean by "IE6"? Does it have anything to do with the web browser?
Btw, I am using IE8 and my build succeeded, though I haven't yet figured out how to run it on VMware.

Thx.
Mar 25, 2009 at 6:28 PM
Edited Mar 25, 2009 at 6:29 PM
Hi,

I have no serious explanation for this but that I had .net 2.0 installed and IE6 started while doing a build and that build failed. If all IE6 instances were closed and reissued the build than everything was OK. I want to mention that this doesn't happen on .net 3.5 & IE7 instances running and cannot reproduce the problem as I don't have that environment anymore.

All the best,
Alex.

EDIT:
P.S.: I've updated the "running on vmware" thread. Take a look.
Coordinator
Mar 31, 2009 at 2:55 AM
Hi George - I've entered your build issue in our bug database. It's possible that that source file contains characters that the particular version of the compiler tools you're using can't deal with. I'll investigate for a subsequent release.
--
Derrick Coetzee
Microsoft Operating Systems Group developer
Coordinator
Mar 31, 2009 at 2:57 AM
Follow-up: George, it would be really helpful if I could ask you what version of the .NET Framework you have installed. Please let me know. Thanks!
Jan 29, 2010 at 9:24 AM
dcoetzee wrote:
Follow-up: George, it would be really helpful if I could ask you what version of the .NET Framework you have installed. Please let me know. Thanks!

 It has nothing to do with .Net Framework. I have the same problem in my desktop, I assume George had the similar build environment like mine: use double byte system as default locale (like chinese, japanese, etc). The file "Singularity\Eventing\EvProcessor.cs" uses MBCS character set, not Unicode, which means: under different locales(espetially like Chinese, Japanese, Thialand, etc), it has different meanings. In this special case: this used lots "0xA0" as space :), why? why not use the universal 0x20? I can't understand it. 

To solve this problem, the options are:

 1. remove all the 'BAD' characters, like replace all the 0xA0 to 0x20

2. Return to pure english environemnt ( set the default system locale to english, which will force you to restart your machine,  I hate that, but this is the most similar situation)

3. Convert the problem file to UNICODE

I used the second option, it works. I remember that in the visual c++, we can also use the #pragma setlocale ... to solve this, but I'm not sure whether we can find the similar way in c-sharp.

Oct 29, 2010 at 5:49 AM
george_wang wrote:
Guys, it works now.

There are some weird characters in the original source file of Singularity/Kernel/Eventing/EvProcessor.cs

Specifically, if you use an Emacs editor (rather than Notepad), you will see the underlined, undisplayable characters around line 303.
They are marked by red lines.
Delete them.

And the Tiny build works now. Trying with World.

Go to here to see what I am saying. 

http://mysbfiles.stonybrook.edu/~wang8/weird.jpg

 right, this resolve my problem.

May 9, 2011 at 11:57 AM

I had the same problem.

For some reason some of the developers inserted hard spaces (Ascii code 160) which are not recognized in many charsets.

But since its still a kind of whitespace, deleting it, would not affect anything.