Closed Bug 302550 Opened 19 years ago Closed 19 years ago

JSS library needs to be ported to Solaris/Linux on AMD64

Categories

(JSS Graveyard :: Library, defect)

Product:
JSS Graveyard
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: Sandeep.Konchady, Assigned: Sandeep.Konchady)

Details

Attachments

(1 file, 3 obsolete files)

Modifications as per Wan-Teh's suggestions
5.02 KB, patch
wtc
: superreview+
Details | Diff | Splinter Review 
Currently there is no libjss4.so on AMD64 for either Solaris or Linux.  Need to
port JSS on Solaris and Linux to AMD64 platform.  The library needs to be build
and tested using JDK 5.0 for AMD64 using both 32bit and 64bit JVM.  Also check
for regression and make sure that the modifications do not break any existing
platforms.
Status: NEW → ASSIGNED
Two modifications are included in this bug.
[1] Based on Glen's finding that compression with jar generates a smaller file
compared to zip, coreconf/import.pl and coreconf/release.pl has been
appropriately modified.  This is very minor modification and has been tested on
all supported platforms.
[2] Based on CPU and USE_64 information on AMD64, we are now able to compile
and build 32 or 64 bit libjss4.so.  This however does not make a difference to
jss4.jar that is generated.  This has been tested on all platforms for
regression.
Attachment #192522 - Flags: superreview?(glen.beasley)
Attachment #192522 - Flags: review?(christophe.ravel.bugs)
Target Milestone: --- → 4.1
Comment on attachment 192522 [details] [diff] [review]
Modified coreconf/jdk.mk, build_all.pl and all.sh to switch to 64 bit compilation for AMD64

Build tested on all platforms with these diffs.
Attachment #192522 - Flags: review?(christophe.ravel.bugs) → review+
(In reply to comment #2)
> (From update of attachment 192522 [details] [diff] [review] [edit])
> Build tested on all platforms with these diffs.
> 

I meant:
Solaris 8 Sparc
Solaris 8 x86
Solaris 10 amd64
HP-UX 11.11
AIX 5.1
Windows NT 4.0
RHEL 3

Comment on attachment 192522 [details] [diff] [review]
Modified coreconf/jdk.mk, build_all.pl and all.sh to switch to 64 bit compilation for AMD64

This patch modifies some coreconf files that are also
used by NSS, so it needs to be reviewed by the NSS team.

I haven't reviewed it yet.  I found some commented out
lines, like this

>Index: coreconf/import.pl
...
>+#$var{ZIP} = "zip";
>+$var{ZIP} = "$ENV{JAVA_HOME}/bin/jar";

>Index: coreconf/release.pl
...
>+        #print STDERR "zip $zipoptions $jarfile $filelist\n";
>+        print STDERR "$ZIP $zipoptions $jarfile $filelist\n";
>+        #system("zip $zipoptions $jarfile $filelist");
>+        system("$ZIP $zipoptions $jarfile $filelist");

These commented-out lines should be removed.

I encourage you to try very hard to imitate the use of spaces
and tabs in the coreconf makefiles you modify.	I know it's
hard, but it's important to maintain a consistent style in
a file, even if the style is bad.

I have a Perl question: what's the difference between $ZIP
and $var(ZIP)?
Updated coreconf/release.pl and coreconf/import.pl to comply with original
layout structure.
Attachment #192522 - Attachment is obsolete: true
Attachment #192550 - Flags: superreview?(wtchang)
Attachment #192550 - Flags: review?(christophe.ravel.bugs)
Attachment #192550 - Flags: review?(glen.beasley)
Comment on attachment 192550 [details] [diff] [review]
Modifications to release.pl and import.pl to comply with original layout

Patch looks good Christophe has tested on all platforms.
Attachment #192550 - Flags: review?(glen.beasley)
Attachment #192550 - Flags: review?(christophe.ravel.bugs)
Attachment #192550 - Flags: review+
Comment on attachment 192550 [details] [diff] [review]
Modifications to release.pl and import.pl to comply with original layout

This patch has some problems.  Most are minor, but one or two
are serious, hence the review-.

1. coreconf/import.pl

I found that this Perl script doesn't use  $var(ZIP) at all.  (When
we import .jar files from /share/builds/components, we only need to
unzip them.)   So the best fix is to simply remove the
    $var(ZIP) = "zip";
statement.

2. coreconf/jdk.mk

> ifeq ($(USE_64), 1)
>+    ifeq ($(CPU_ARCH), x86_64)
>+	JAVA_CPU = amd64
>+    else
> 	JAVA_CPU = $(shell uname -p)v9
>+    endif
> else
> 	JAVA_CPU = $(shell uname -p)
> endif

Many coreconf files use tabs to indent.  So here it is best
to stick with that style.

Please take the opportunity to use := instead of = with
$(shell) function.

>@@ -163,8 +167,6 @@
> ifneq ($(JDK_VERSION), 1.1)
> ifeq ($(USE_64), 1)
> 	JAVA_LIBS += -L$(JAVA_HOME)/$(JAVA_LIBDIR)/server
>-else
>-	JAVA_LIBS += -L$(JAVA_HOME)/$(JAVA_LIBDIR)/classic
> endif

Do you know why we only want to use "server" when USE_64 is
1?  This change (removal of obsolete "classic") is fine.
I just don't understand what the original code tries to do.

>@@ -241,16 +243,20 @@
> 
> 	# (3) specify "linker" information
> 	JAVA_CPU = i386
>-
>+        if ($(CPU_ARCH) == "x86_64")
>+            ifeq ($(USE_64), 1)
>+                JAVA_CPU = amd64
>+            else
>+                JAVA_CPU = i386
>+            endif
> 	JAVA_LIBDIR = jre/lib/$(JAVA_CPU)

I don't understand how this could have worked.	This alone
is a review- problem.

First, it should be ifeq ($(CPU_ARCH),x86_64).	Second,
there is a missing endif.

3. coreconf/release.pl

>@@ -41,7 +41,14 @@
> 
> #######-- read in variables on command line into %var
> 
>+$use_jar = "true";
>+$ZIP     = "$ENV{JAVA_HOME}/bin/jar";
>+
>+if ( $ENV{JAVA_HOME} eq "" ) {
> $var{ZIP} = "zip";
>+$ZIP      = "zip";
>+$use_jar  = "false";
>+}

The code inside the if block should be indented.

I found that this Perl script doesn't use $var(ZIP), so please
remove the
    $var(ZIP) = "zip";
statement.

Nit: the code reads better if it first checks if the JAVA_HOME
environment variable is defined and then uses it.

>-    $zipoptions = "-T";
>-    if ($jaropts =~ /a/) {
>-	if ($var{OS_ARCH} eq 'WINNT') {
>-	    $zipoptions .= ' -ll';
>-	}
>+    if ( $use_jar eq "false" ) {
>+        $zipoptions = "-T -r";
>+        if ($jaropts =~ /a/) {
>+	    if ($var{OS_ARCH} eq 'WINNT') {
>+	        $zipoptions .= ' -ll -r';
>+	    }
>+        }
>+    } else {
>+	$zipoptions = "-cvf";
>     }

In the new code, remove -r from the WINNT case, otherwise
WINNT will end up with two -r's in $zipoptions.  (Note the
use of .=, as opposed to =, in the WINNT case.)

4. jss/build_java.pl

Please remove the two print statements that I believe you added
for debugging.

>+    #
>+    # Modifications for JDK on AMD64, both 32bit and 64bit
>+    # Identify if the system is amd64
>+    #
>+    $javac   = "$ENV{JAVA_HOME}/bin/javac";
>+    $javah   = "$ENV{JAVA_HOME}/bin/javah";
>     $javadoc = "$ENV{JAVA_HOME}/bin/javadoc";
>+    my $os   = `uname -s`;
>+    chop ($os);
>+    if ($os eq "SunOS") {
>+        my $cpu = `/usr/bin/isainfo -n`;
>+        chop ($cpu);
>+        if($ENV{USE_64}) {
>+            if($cpu eq "amd64") {
>+                $javac   = "$ENV{JAVA_HOME}/bin/amd64/javac";
>+                $javah   = "$ENV{JAVA_HOME}/bin/amd64/javah";
>+                $javadoc = "$ENV{JAVA_HOME}/bin/amd64/javadoc";
>+            }
>+        }
>+    }

I'm wondering why we don't also use the 64-bit javac, javah, and
javadoc on SPARC.

Note that your comment explains the changes you made, rather
than the resulting code.  So people who only look at the resulting
code will be wondering what are the "modifications" you refer to.
Please replace the comment with one that describes the resulting
code.  For example, "Use 64-bit Java tools on AMD64."

>     $class_release_dir = $cmdline_vars{SOURCE_RELEASE_PREFIX};
>+    print "SOURCE_RELEASE_PREFIX=$class_release_dir";
>     if( $ENV{BUILD_OPT} ) {
>         $class_dir = "$dist_dir/classes";
>-        $class_jar = "$dist_dir/$cmdline_vars{XPCLASS_JAR}";
>+        $class_jar = "$class_release_dir/$cmdline_vars{XPCLASS_JAR}";
>         $class_release_dir .= "/$cmdline_vars{SOURCE_RELEASE_CLASSES_DIR}";
>         $javac_opt_flag = "-O";
>         $debug_source_file = "org/mozilla/jss/util/Debug_ship.jnot";
>     } else {
>         $class_dir = "$dist_dir/classes_DBG";
>-        $class_jar = "$dist_dir/$cmdline_vars{XPCLASS_DBG_JAR}";
>+        $class_jar = "$class_release_dir/$cmdline_vars{XPCLASS_DBG_JAR}";
>         $class_release_dir .= "/$cmdline_vars{SOURCE_RELEASE_CLASSES_DBG_DIR}";
>         $javac_opt_flag = "-g";
>         $debug_source_file = "org/mozilla/jss/util/Debug_debug.jnot";

The changes here are also problematic.	You use $class_release_dir
in the $class_jar assignment statement, and in the next statement
you append a string to $class_release_dir.  So $class_jar gets the
intermediate value of $class_release_dir.  Is that intentional?
I find that confusing.

5. jss/org/mozilla/jss/tests/all.pl

Please remove the two print statements that I believe you added
for debugging.

>+    #
>+    # AMD64 specific modifications to use 64bit or 32bit JVM
>+    #
>     $java = "$ENV{JAVA_HOME}/jre/bin/java$exe_suffix";
>-    (-f $java) or die "'$java' does not exist\n";
>     $java = $java . $ENV{NATIVE_FLAG};
>-
>-    if ($ENV{USE_64}) {
>-        $java = $java . " -d64";
>+    (-f $java) or die "'$java' does not exist\n";
>+    if ($osname eq "SunOS") {
>+        my $cpu = `/usr/bin/isainfo -n`;
>+        print "cpu=$cpu\n";
>+        if($ENV{USE_64}) {
>+            print "USE_64=1\n";
>+            if( $cpu == "amd64" ) {
>+                $java = "$ENV{JAVA_HOME}/jre/bin/amd64/java$exe_suffix";
>+            } else {
>+                $java = $java . " -d64 ";
>+            }
>+        }
>+    } else {
>+        if($ENV{USE_64}) {
>+            $java = $java . " -d64 ";
>+        }
>     }

Again, the comment in the code should describe the resulting code,
rather than the changes you made.

You are doing the (-f $java) test *after* we append $ENV{NATIVE_FLAG}
to $java.  This is wrong.  We should do the (-f $java) test when
the value of $java is still the pathname of the java executable.
(I don't know what $ENV{NATIVE_FLAG} is though.)
Attachment #192550 - Flags: superreview?(wtchang) → superreview-
Comment on attachment 192550 [details] [diff] [review]
Modifications to release.pl and import.pl to comply with original layout

In jss/build_java.pl, we have:

>     if( $ENV{BUILD_OPT} ) {
>         $class_dir = "$dist_dir/classes";
>-        $class_jar = "$dist_dir/$cmdline_vars{XPCLASS_JAR}";
>+        $class_jar = "$class_release_dir/$cmdline_vars{XPCLASS_JAR}";
>         $class_release_dir .= "/$cmdline_vars{SOURCE_RELEASE_CLASSES_DIR}";
>         $javac_opt_flag = "-O";
>         $debug_source_file = "org/mozilla/jss/util/Debug_ship.jnot";
>     } else {
>         $class_dir = "$dist_dir/classes_DBG";
>-        $class_jar = "$dist_dir/$cmdline_vars{XPCLASS_DBG_JAR}";
>+        $class_jar = "$class_release_dir/$cmdline_vars{XPCLASS_DBG_JAR}";
>         $class_release_dir .= "/$cmdline_vars{SOURCE_RELEASE_CLASSES_DBG_DIR}";
>         $javac_opt_flag = "-g";
>         $debug_source_file = "org/mozilla/jss/util/Debug_debug.jnot";

Please explain why you are changing the value of $class_jar (the
location of the JSS jar file).	It's not obvious how this change
is related to this bug.
Comment on attachment 192550 [details] [diff] [review]
Modifications to release.pl and import.pl to comply with original layout

In coreconf/release.pl, we have:

>+$use_jar = "true";
>+$ZIP     = "$ENV{JAVA_HOME}/bin/jar";
>+
>+if ( $ENV{JAVA_HOME} eq "" ) {
> $var{ZIP} = "zip";
>+$ZIP      = "zip";
>+$use_jar  = "false";
>+}
...
>+    if ( $use_jar eq "false" ) {
>+        $zipoptions = "-T -r";
>+        if ($jaropts =~ /a/) {
>+	    if ($var{OS_ARCH} eq 'WINNT') {
>+	        $zipoptions .= ' -ll -r';
>+	    }
>+        }
>+    } else {
>+	$zipoptions = "-cvf";
>     }

Instead of "true" and "false", you can use 1 and 0.
1. coreconf/import.pl
   Removed $var{ZIP}

2. coreconf/jdk.mk
   Replaced spaces with tabs to stick to the existing style.
   Used := in place of = for $(shell) function.
   For Solaris and Linux, we also link with $LIBDIR/server when using USE_64=1
because we want to use 64 bit libjvm.so and not 32 bit found under jre/lib.
   Also added the missing endif and used ifeq ($(CPU_ARCH),x86_64) instead of
ie (...)

3. coreconf/release.pl
   Removed reference to $var{ZIP} or using of zip.
   eliminated the variable $use_jar.

4. jss/build_java.pl
   Removed debug print statements.
   Removed 64bit java tools (javac, javah, and javadoc).  Note that javac
always uses the 64-bit server VM on some platforms (linux-amd64 (and ia64))
because there is no client VM anyway.  Since most javac invocations are small
compile jobs, you pay the higher startup costs with C2 and are unlikely to gain
much benefit.  It would take a really massive javac command line to produce a
workload that could take advantage of a 64-bit heap.
   New location of xpclass.jar and xpclass_dbg.jar.  These jars are now placed
under /mozilla/dist/release/no-policy by request from our RE.  This is done as
a first step to moving the generated jars to platform specific OBJ directories
as suggested by Wan-Teh.  This should help in generating 32 and 64 bit jars on
the same platform when doing RE builds.  Otherwise the jars get over written. 
I will open a separate bug to fix this issue.

5. jss/org/mozilla/jss/tests/all.pl
   Removed debug print statements.
   Checking for existence of java before adding $ENV{NATIVE_FLAG}.
Attachment #192550 - Attachment is obsolete: true
Attachment #193985 - Flags: superreview?(wtchang)
Attachment #193985 - Flags: review?(glen.beasley)
Attachment #193985 - Flags: review?(glen.beasley) → review+
Attachment #192522 - Flags: superreview?(glen.beasley)
Comment on attachment 193985 [details] [diff] [review]
Updated changes to files based on review feedback from Wan-Teh

Sandeep,

Some of the changes in this patch are wrong.

1. coreconf/import.pl

Just remove the $var{ZIP} assignment because $var{ZIP}
is not used.  Don't replace the assignment by a new
one.

2. coreconf/jdk.mk

The changes to this file are fine, so you may go ahead
and check them in first.  However, I have a question.
Should we simply remove the use of the JDK_VERSION
variable, now that we require JDK 1.4 as the minimum?

3. coreconf/release.pl

The changes to this file are wrong.  You removed the
support for zip completely.  We still need support for
zip in this file.  Our strategy should be "prefer jar
but allow zip".  At Red Hat we still build NSPR and NSS
as separate components, so we can't assume that jar is
available in the build environment for NSPR and NSS. I
know you can make that assumption at Sun because you are
building NSPR, NSS, and JSS as a single component.

4. jss/build_java.pl

You said this change is a first step to moving the
generated jars to platform specific OBJ directories
as suggested by me, but this change does not accomplish
that.  You changed $class_jar from one platform independent
directory ($cmdline_vars{SOURCE_PREFIX}, or mozilla/dist)
to another platform independent directory
($cmdline_vars{SOURCE_RELEASE_PREFIX}, or mozilla/dist/release/no-policy).
How will this change prevent the jars from getting overwritten
when we generate 32 and 64 bit jars on the same platform?

5. jss/org/mozilla/jss/tests/all.pl

Why do you change the initial value of $truncate_lib_path
from 1 to 0?  If you do this, you can simply remove all
uses of $truncate_lib_path because its value will be 0 on
all platforms.

     $java = "$ENV{JAVA_HOME}/jre/bin/java$exe_suffix";
     (-f $java) or die "'$java' does not exist\n";
     $java = $java . $ENV{NATIVE_FLAG};
+    if ($osname eq "SunOS") {
+	 my $cpu = `/usr/bin/isainfo -n`;
+	 if($ENV{USE_64}) {
+	     if( $cpu == "amd64" ) {
+		 $java = "$ENV{JAVA_HOME}/jre/bin/amd64/java$exe_suffix";
+	     } else {
+		 $java = $java . " -d64 ";
+	     }
+	 }
+    } else {
+	 if($ENV{USE_64}) {
+	     $java = $java . " -d64 ";
+	 }
     }

Nit: move the line
    my $cpu = `/usr/bin/isainfo -n`;
into the if($ENV{USE_64}) block because the $cpu variable is only
used in that block.

Does the value of $java for the $cpu == "amd64" case need
$ENV{NATIVE_FLAG}?  (I don't know what $ENV{NATIVE_FLAG} is.)

I suggest rewriting the above like this:

    $java = "$ENV{JAVA_HOME}/jre/bin/java$exe_suffix";
    my $java_64bit = 0;
    if ($osname eq "SunOS") {
	if ($ENV{USE_64}) {
	    my $cpu = `/usr/bin/isainfo -n`;
	    if ($cpu == "amd64") {
		$java = "$ENV{JAVA_HOME}/jre/bin/amd64/java$exe_suffix";
		$java_64bit = 1;
	    }
	}
    }
    (-f $java) or die "'$java' does not exist\n";
    $java = $java . $ENV{NATIVE_FLAG};

    if ($ENV{USE_64} && !$java_64bit) {
	$java = $java . " -d64";
    }
Attachment #193985 - Flags: superreview?(wtchang) → superreview-
1. coreconf/import.pl

Just remove the $var{ZIP} assignment because $var{ZIP}
is not used.  Don't replace the assignment by a new
one.

REMOVED

2. coreconf/jdk.mk

The changes to this file are fine, so you may go ahead
and check them in first.  However, I have a question.
Should we simply remove the use of the JDK_VERSION
variable, now that we require JDK 1.4 as the minimum?

I WOULD LEAVE IT FOR THIS RELEASE AND REMOVE IT FOR THE NEXT.
THIS WAY ALL PLATFORMA (HP-UX, AIX) CAN CATCH UP TO JDK 1.4.

3. coreconf/release.pl

The changes to this file are wrong.  You removed the
support for zip completely.  We still need support for
zip in this file.  Our strategy should be "prefer jar
but allow zip".  At Red Hat we still build NSPR and NSS
as separate components, so we can't assume that jar is
available in the build environment for NSPR and NSS. I
know you can make that assumption at Sun because you are
building NSPR, NSS, and JSS as a single component.

ADDED SUPPORT FOR ZIP BACK AGAIN ALONG WITH JAR WHERE
APPLICABLE.

4. jss/build_java.pl

You said this change is a first step to moving the
generated jars to platform specific OBJ directories
as suggested by me, but this change does not accomplish
that.  You changed $class_jar from one platform independent
directory ($cmdline_vars{SOURCE_PREFIX}, or mozilla/dist)
to another platform independent directory
($cmdline_vars{SOURCE_RELEASE_PREFIX}, or mozilla/dist/release/no-policy).
How will this change prevent the jars from getting overwritten
when we generate 32 and 64 bit jars on the same platform?

REMOVED THESE CHANGES.	I WILL FILE A NEW BUG AND FIX IT AFRESH.

5. jss/org/mozilla/jss/tests/all.pl

Why do you change the initial value of $truncate_lib_path
from 1 to 0?  If you do this, you can simply remove all
uses of $truncate_lib_path because its value will be 0 on
all platforms.

     $java = "$ENV{JAVA_HOME}/jre/bin/java$exe_suffix";
     (-f $java) or die "'$java' does not exist\n";
     $java = $java . $ENV{NATIVE_FLAG};
+    if ($osname eq "SunOS") {
+	 my $cpu = `/usr/bin/isainfo -n`;
+	 if($ENV{USE_64}) {
+	     if( $cpu == "amd64" ) {
+		 $java = "$ENV{JAVA_HOME}/jre/bin/amd64/java$exe_suffix";
+	     } else {
+		 $java = $java . " -d64 ";
+	     }
+	 }
+    } else {
+	 if($ENV{USE_64}) {
+	     $java = $java . " -d64 ";
+	 }
     }

Nit: move the line
    my $cpu = `/usr/bin/isainfo -n`;
into the if($ENV{USE_64}) block because the $cpu variable is only
used in that block.

Does the value of $java for the $cpu == "amd64" case need
$ENV{NATIVE_FLAG}?  (I don't know what $ENV{NATIVE_FLAG} is.)

I suggest rewriting the above like this:

    $java = "$ENV{JAVA_HOME}/jre/bin/java$exe_suffix";
    my $java_64bit = 0;
    if ($osname eq "SunOS") {
	if ($ENV{USE_64}) {
	    my $cpu = `/usr/bin/isainfo -n`;
	    if ($cpu == "amd64") {
		$java = "$ENV{JAVA_HOME}/jre/bin/amd64/java$exe_suffix";
		$java_64bit = 1;
	    }
	}
    }
    (-f $java) or die "'$java' does not exist\n";
    $java = $java . $ENV{NATIVE_FLAG};

    if ($ENV{USE_64} && !$java_64bit) {
	$java = $java . " -d64";
    }

RESET $truncate_lib_path TO 1 AND UPDATED AMD64 SWITCH AS
DESCRIBED BY YOU ABOVE.
Attachment #193985 - Attachment is obsolete: true
Attachment #195812 - Flags: superreview?(wtchang)
Comment on attachment 195812 [details] [diff] [review]
Modifications as per Wan-Teh's suggestions


r=wtc.

>@@ -241,16 +243,21 @@
> 
> 	# (3) specify "linker" information
> 	JAVA_CPU = i386
>-
>+	ifeq ($(CPU_ARCH),x86_64)
>+        	ifeq ($(USE_64), 1)
>+        		JAVA_CPU = amd64
>+        	else
>+        		JAVA_CPU = i386
>+        	endif
>+	endif

The "else JAVA_CPU = i386" part is not necessary because
i386 is the initial value for JAVA_CPU.

>+$use_jar = "1";
>+$ZIP     = "$ENV{JAVA_HOME}/bin/jar";
>+
>+if ( $ENV{JAVA_HOME} eq "" ) {
>+    $ZIP      = "zip";
>+    $use_jar  = "0";
>+}
>+

You can set $use_jar to 1 or 0, without the quotes ("").

>+    if ( $use_jar eq "0" ) {

This can be if (!$use_jar), or even better, say
if ($use_jar) and reverse the two blocks.

Thanks, Sandeep.
Attachment #195812 - Flags: superreview?(wtchang) → superreview+
Sandeep, I may not have been clear.  It is fine to
leave the "else JAVA_CPU = i386" part alone even
though it's not necessary.

Please consider making my other suggested changes
related to $use_jar.  Thanks a lot.
Commited changes made to these files.

Checking in coreconf/import.pl;
/cvsroot/mozilla/security/coreconf/import.pl,v  <--  import.pl
new revision: 1.3; previous revision: 1.2
done
Checking in coreconf/jdk.mk;
/cvsroot/mozilla/security/coreconf/jdk.mk,v  <--  jdk.mk
new revision: 1.15; previous revision: 1.14
done
Checking in coreconf/release.pl;
/cvsroot/mozilla/security/coreconf/release.pl,v  <--  release.pl
new revision: 1.4; previous revision: 1.3
done
Checking in jss/org/mozilla/jss/tests/all.pl;
/cvsroot/mozilla/security/jss/org/mozilla/jss/tests/all.pl,v  <--  all.pl
new revision: 1.23; previous revision: 1.22
done
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: