--- a/Symbian3/SDK/Source/GUID-F21A1ABE-4844-54E2-83E0-4AD25E867A72.dita Wed Mar 31 11:11:55 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-F21A1ABE-4844-54E2-83E0-4AD25E867A72.dita Fri Jun 11 12:39:03 2010 +0100
@@ -1,59 +1,59 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License
-"Eclipse Public License v1.0" which accompanies this distribution,
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
- Nokia Corporation - initial contribution.
-Contributors:
--->
-<!DOCTYPE concept
- PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept id="GUID-F21A1ABE-4844-54E2-83E0-4AD25E867A72" xml:lang="en"><title>ABIv1
-to ABIv2 toolchain changes</title><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>The principal task of Symbian platform build tools such as <filepath>abld/makmake</filepath> is
-to read the specified project (.mmp) files and then call the appropriate compiler
-and linker with the necessary inputs and option settings. The binaries output
-from commercial compiler and linkers, such as ARM's RVCT and GNU GCC, cannot
-however be directly used by Symbian platform. Symbian platform requires binaries
-to be in Symbian-specific format, known as the E32Image format. </p>
-<p>In order to create binaries in this format, the toolchain must perform
-additional steps on the compiler/linker output. How these steps are performed
-is considerably different between builds for the ABIv1 and ABIv2 targets.
-Essentially, a number of small tools used for ABIv1 targets, are replaced
-for ABIv2 targets by a single tool called the post-linker (file name <filepath>elf2e32.exe</filepath>).
-This redesign is intended to simplify the work needed to introduce support
-for a new ABIv2 compatible compiler into the toolchain. </p>
-<p>The following diagram shows the steps (somewhat simplified) performed by
-the toolchain for the creation of a DLL for ABIv1 and v2 respectively: </p>
-<fig id="GUID-F68AB795-A612-5202-A459-30B62663737F">
-<title> ABIv1 and v2 toolchains compared </title>
-<image href="GUID-09263C33-EE63-530C-A6B9-70806F0BC16D_d0e469621_href.png" placement="inline"/>
-</fig>
-<p>The <filepath>elf2e32</filepath> tool replaces the ABIv1 toolchain tools <filepath>def2dll.bat</filepath>, <filepath>elf2inf.pl</filepath>, <filepath>makedef.pl</filepath> and <filepath>elftran.exe</filepath>. </p>
-<section><title>.dso files </title><p>In the ABIv2 toolchain, <filepath> .lib</filepath> files
-are replaced by <filepath>.dso</filepath> files. These files are used in similar
-situations to <filepath>.lib</filepath> files. However, the format of these
-two files is completely different. A <filepath>.lib</filepath> file is an
-archive file created from stubs generated for each of the exported symbols.
-A <filepath>.dso</filepath> file is an ELF object similar to other objects
-created with the compiler. It has all the associated sections required for
-an ELF object, such as the symbol table, string table, etc. The <filepath>.dso</filepath> file
-also has the information required for the linker to link to the correct ordinals
-to the DLL. <filepath>.lib</filepath> files cannot be used by the ABIv2 toolchain,
-and <filepath>.dso</filepath> files cannot be used by the ABIv1 toolchain.</p></section>
-<section><title>Linked objects </title><p>The compiler toolchain that supports
-ABIv2 produces linked objects that are different to those produced by the
-ABIv1 toolchain. The linked objects produced are both ELF format, but they
-have extra information that can be used by a postlinker to create platform
-specific binaries. As the ELF produced by ABIv2 has more information, it is
-not necessary to perform the sort of manipulations performed by the many small
-tools in the ABIv1 toolchain. As the linked objects differ significantly in
-their content, it is not possible to mix ABIv1 and ABIv2 toolchain objects
-in the same build tree. </p></section>
-<section><title>E32Image format </title><p>The final E32image produced by
-the ABIv2 toolchain is in the same format as that of the ABIv1 toolchain.
-However, a byte by byte comparison of the same E32image file in ABIv1 and
-ABIv2 is not possible. The layout of the code produced by the linker is different,
-although the code is still binary compatible. </p></section>
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License
+"Eclipse Public License v1.0" which accompanies this distribution,
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+ Nokia Corporation - initial contribution.
+Contributors:
+-->
+<!DOCTYPE concept
+ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-F21A1ABE-4844-54E2-83E0-4AD25E867A72" xml:lang="en"><title>ABIv1
+to ABIv2 toolchain changes</title><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>The principal task of Symbian platform build tools such as <filepath>abld/makmake</filepath> is
+to read the specified project (.mmp) files and then call the appropriate compiler
+and linker with the necessary inputs and option settings. The binaries output
+from commercial compiler and linkers, such as ARM's RVCT and GNU GCC, cannot
+however be directly used by Symbian platform. Symbian platform requires binaries
+to be in Symbian-specific format, known as the E32Image format. </p>
+<p>In order to create binaries in this format, the toolchain must perform
+additional steps on the compiler/linker output. How these steps are performed
+is considerably different between builds for the ABIv1 and ABIv2 targets.
+Essentially, a number of small tools used for ABIv1 targets, are replaced
+for ABIv2 targets by a single tool called the post-linker (file name <filepath>elf2e32.exe</filepath>).
+This redesign is intended to simplify the work needed to introduce support
+for a new ABIv2 compatible compiler into the toolchain. </p>
+<p>The following diagram shows the steps (somewhat simplified) performed by
+the toolchain for the creation of a DLL for ABIv1 and v2 respectively: </p>
+<fig id="GUID-F68AB795-A612-5202-A459-30B62663737F">
+<title> ABIv1 and v2 toolchains compared </title>
+<image href="GUID-09263C33-EE63-530C-A6B9-70806F0BC16D_d0e469457_href.png" placement="inline"/>
+</fig>
+<p>The <filepath>elf2e32</filepath> tool replaces the ABIv1 toolchain tools <filepath>def2dll.bat</filepath>, <filepath>elf2inf.pl</filepath>, <filepath>makedef.pl</filepath> and <filepath>elftran.exe</filepath>. </p>
+<section><title>.dso files </title><p>In the ABIv2 toolchain, <filepath> .lib</filepath> files
+are replaced by <filepath>.dso</filepath> files. These files are used in similar
+situations to <filepath>.lib</filepath> files. However, the format of these
+two files is completely different. A <filepath>.lib</filepath> file is an
+archive file created from stubs generated for each of the exported symbols.
+A <filepath>.dso</filepath> file is an ELF object similar to other objects
+created with the compiler. It has all the associated sections required for
+an ELF object, such as the symbol table, string table, etc. The <filepath>.dso</filepath> file
+also has the information required for the linker to link to the correct ordinals
+to the DLL. <filepath>.lib</filepath> files cannot be used by the ABIv2 toolchain,
+and <filepath>.dso</filepath> files cannot be used by the ABIv1 toolchain.</p></section>
+<section><title>Linked objects </title><p>The compiler toolchain that supports
+ABIv2 produces linked objects that are different to those produced by the
+ABIv1 toolchain. The linked objects produced are both ELF format, but they
+have extra information that can be used by a postlinker to create platform
+specific binaries. As the ELF produced by ABIv2 has more information, it is
+not necessary to perform the sort of manipulations performed by the many small
+tools in the ABIv1 toolchain. As the linked objects differ significantly in
+their content, it is not possible to mix ABIv1 and ABIv2 toolchain objects
+in the same build tree. </p></section>
+<section><title>E32Image format </title><p>The final E32image produced by
+the ABIv2 toolchain is in the same format as that of the ABIv1 toolchain.
+However, a byte by byte comparison of the same E32image file in ABIv1 and
+ABIv2 is not possible. The layout of the code produced by the linker is different,
+although the code is still binary compatible. </p></section>
</conbody></concept>
\ No newline at end of file