Author: Suresh Duddi

## Standalone XPCOM v 0.5

Version 0.5
15 May 2000
Suresh Duddi <dp@netscape.com>

### 1.0 Overview

Standalone XPCOM is a tree configuration, that when built, provides a minimal set of libraries (shared mostly) that can be used to get all features of XPCOM. The contents of this standalone XPCOM in general are:

- NSPR : mozilla/nsprpub
- Registry : mozilla/modules/libreg
- XPCOM : mozilla/xpcom

NOTE 1: xpcom apis are not frozen yet. By XPCOM 1.0 release they will be.
NOTE 2: xpcom standalone differs from the xpcom built with mozilla. Hence cannot be used with the mozilla browser.

### 2.0 Building Standalone XPCOM

Here are the instructions for building the Standalone XPCOM on unix:

Step 1 : Pull the sources
1. `cvs -z 3 co mozilla/client.mk`
2. `cd mozilla`
3. `gmake -f client.mk pull_all BUILD_MODULES=xpcom`

Step 2 : Build XPCOM Standalone (unix)
1. `configure --enable-modules=xpcom`
2. `gmake`

Thanks to Christopher Seawood <cls@seawood.org> for make this so simple.

### 3.0 Testing Standalone XPCOM

`xpcom/sample` contains a sample application and a component. This should get built by default.

- `nsTestSample` is the sample application. This should have been installed in your `bin/` directory.
- `libsample.so (unix)` is the sample component implementation that the sample application will try to instantiate. This should have been installed in your `bin/components` directory

To run the test,

1. cd to your `bin/` directory
2. setenv LD_LIBRARY_PATH .
3. `./nsTestSample`
`Warning: MOZILLA_FIVE_HOME not set.`
`nsNativeComponentLoader: autoregistering begins.`
`nsNativeComponentLoader: autoregistering succeeded`
`Inital print: initial value`
`Set value to: XPCOM defies gravity`
`Final print : XPCOM defies gravity`
`Test passed.`

### 4.0 Test FAILED: What went wrong ?

The most common case of why the sample would have failed if you didn't run it from the bin directory. Here are some error messsages and possible ways of fixing them.

1. `./nsTestSample: error in loading shared libraries: libxpcom.so: cannot open shared object file: No such file or directory`

LD_LIBRARY_PATH not set. To fix "`setenv LD_LIBRARY_PATH ."`

2. Link errors when building xpcom standalone

This is mostly due to the fact that probably xpcom is not being built standalone. Make sure you did "`configure --enable-modules=xpcom"`

### 5.0 Whats the difference between Standalone and non-Standalone XPCOM

Here is what we had to do to get a working standalone XPCOM

1. Disabled all forms of unicode conversion. nsString, nsCRT were using this in various forms. Only ASCII is expected to work. Other charsets including unicode are not guaranteed to work.
2. Disabled nsUnicharInputStream. This causes nsPersistentProperties to always fail.
3. Disabled control of XPT from preferences.
4. Disabled use of ZIP format of XPT files.

Until we fix these differences, the non-standalone xpcom will be the one used by the mozilla browser.

### 6.0 TODO for v 1.0

1. Enable XPCOM to work with unicode. Unicode, ASCII and ISO8859-1 will be the charset that will be self supported by XPCOM.
2. Optional exclusion of specific features into standalone XPCOM like unicode support, registry, xpconnect. Tweeking these options will cause reduction in memory requirements and size.
3. Get `xpcom/tests` directory upto date and documented.
4. Make standalone XPCOM the only deliverable from xpcom. No more `#ifndef XPCOM_STANDALONE`
5. Update this document for both Windows and Mac.
6. API freeze and documentation

### 7.0 Future (post v 1.0)

mmh! let me think...

Suresh Duddi <dp@netscape.com>