STLPort
and the EOCP

The EOCP was upgraded to run with STLPort, and thus be STL "compliant" (i.e.,
not including a bunch of hacked files to allow old Microsoft Compilers to
work).

Because the EOCP will be running on embedded platforms, it is necessary for us
to provide our own iostreams library implementation of STLPort, though this is
not usually required for windows. Thus, when downloading and installing
STLPort, we have to do some of those things that the documentation for STLPort
says we problably don't need to do. This is a little annoying in the
beginning, but will pay off.

Build & Installation Process

Cygwin

Follow the instructions in the INSTALL file. In addition, note
that cross compiling has thusfar been unsuccessful
with Cygwin and STLPort.

Unix/Linux

Follow the instructions in the INSTALL file.

Cross Compiling

This feature currenly ONLY works
for GNU-built, *-linux crosscompilers built on a true linux system. There has
not been success thusfar using Cygwin-built crosscompilers for building STLPort.
Note that we hope to still use Cygwin-built crosscompilers once we determine
STLPorts issues with Cygwin.

You must first build your crosscompiler. For EOCP, we use
this procedure.
Don't forget to add the ${BASECROSS}/bin/ directory to your path,
and export the appropriate environment variables by running the setup_crosscompiler script.

Once the crosscompiler it is built, environment variables
are exported, etc., you will be able to use
it by configuring STLPort to use that compiler.
For the gumstix crosscompilation, we have created
a special makefile and added it
to the CVS repository directory in which STLPort
is found:

Note that you must be building the Escher
CVS version of STLPort in order to make this work,
since the existing STLPort 5.0.0 release does not
correctly recognize that --target=arm-linux and --target=arm-unknown-linux should
be equivalent, and thus Makefiles in the build directory
are listed in
nonexisting directories. I have patched
this version to work, based on feedback from the
STLPort gurus and code managers. I have learned
that it will be rolled in to future releases.

Examine the file build.out for any
errors which may crop up, and you can address
them to us. Many errors may have already appeared
on the
Escher STLPort FAQ .

Making the STLPort libraries part of your normal, everyday,
compilation and linkage routine is necessary in order to
fully take advantage of the project. You have to put these
shared libraries in the critical path
of future
compilations,
as well as moving them to the destination platform. This
is done in the same spirit of Boris' README file (Hint
Hint, this is copied and cleverly pasted (for path correctness)
from that README file).

Now, all of the files are installed on our local filesystem.
Next, we must put them on the embedded linux machine.
We do not need to send the stlport/ directory
which would normally reside in the include path,
since we won't be building anything on that local machine.

Note that our machine name is gumstix2, and that we
are using an externally mounted memory card (MMC) in
order to have enough space for these libraries. You will
get annoying and difficult-to-decipher messages if you
do not have this directory on your embedded platform,
or if it is not mounted correctly.

The observant reader will not be surprised to see only our actual library,
and not the symbolic links to it; we did not request for
tar to create those links for us back on the crosscompiler
platform. However, even if we had, we would not be able
to take advantage of them, because we are going to have
to create new symbolic links in any case.

Now we should have the proper shared libraries in place for our crosscompiler's
benefit, as well as the final platform's benefit, there's
nothing to do but run some tests!!

Running the built in regression tests for STLPort. This
is where, as they say, we are at an impass. Tests compile,
but do not link, with the crosscompiler. We are working
on it (3/8).

The problem is that the arm-linux-gcc compiler is built
with the option --disable-__cxa_atexit,
which is required by STLPort. No word yet on whether
STLPort actually needs this, or it can be disabled somehow...

Conclusion

You are now ready to start building the EOCP. I find it EXTREMELY useful to
close and reopen Visual Studio before starting the build process. If you have
more than one instance open, you should make sure that the one you set the
paths in is the LAST one you close, since those settings are written to the
registry. Otherwise, you might think "why did the paths change?" "I set that, I
REMEMEBER setting that..."