<?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 xml:lang="en" id="GUID-3BB6E558-017D-584A-BCB7-AB1DD80C5A90"><title>deffile</title><prolog><metadata><keywords/></metadata></prolog><conbody><p> <codeph>deffile</codeph>  <varname>filename</varname>  </p> <p>Use the <codeph>deffile</codeph> statement to override the default linker definition file for the project. </p> <p>A <filepath>.def</filepath> file specifies associations between exported function names and their ordinal export number. It is used by the linker when constructing a DLL and (where applicable) when constructing its associated import library. </p> <p>The assignment of ordinals must be controlled by a <filepath>.def</filepath> file in two situations: </p> <ul><li id="GUID-8F33841B-EF81-59DA-A409-231032FA5606"><p>A polymorphic interface <filepath>DLL</filepath> must export a particular function as ordinal 1. In this case, the <filepath>.def</filepath> file is used to specify this association, while other exported functions may have a random order. </p> </li> <li id="GUID-C032173B-7997-5292-80F4-B1325C4CE9A6"><p>A re-released <filepath>DLL</filepath> must be used by clients built against the old version. In this case, the <filepath>.def</filepath> file is used to ensure that all functions exported by the old version of the <filepath>DLL</filepath> are exported with the same ordinal by the new version. </p> </li> </ul> <p>For many polymorphic <filepath>DLL</filepath> s, a special target type is provided so that the build tools can ensure that the correct function is exported as ordinal 1. Where a special target type is provided, the <filepath>.def</filepath> file can be dispensed with. </p> <p> <filepath>.def</filepath> files are sometimes colloquially referred to as freeze files, because they freeze the association between name and ordinal, for exported functions. </p> <p>The RVCT and Microsoft tool chains use different schemes for mangling the names of exported functions. This means that <filepath>.def</filepath> files of the same name must be differentiated by storing them in separate directories. </p> <p>Conventionally, </p> <p> <filepath>..\eabi\</filepath> is used for ARM <filepath>.def</filepath> files, </p> <p>while </p> <p> <filepath>..\bwins\</filepath> is used for WINSCW <filepath>.def</filepath> files. </p> <p>By default, the frozen <filepath>.def</filepath> file takes its basename from the basename of the target for the project. </p> <p>Where the default frozen <filepath>.def</filepath> file is overridden by the <codeph>deffile</codeph> statement, a path to the file can be specified as part of the filename. </p> <p>If no path is specified, the <filepath>.def</filepath> files are expected to be in: </p> <ul><li id="GUID-F592A3E3-2577-5146-B512-04CEADA760D7"><p>directory ..<filepath>\bwins\</filepath> for platforms WINSCW, CW_IDE, VS6 and VS2003 </p> </li> <li id="GUID-EE1052D2-87E9-5C0B-ABA9-492C0F9D302D"><p>directory ..<filepath>\eabi\</filepath> for the ARM platform. </p> </li> </ul> <p>If a path is specified, place the <codeph>deffile</codeph> statement within <codeph>#if defined(</codeph> <varname>identifier</varname> <codeph>)</codeph> so that the same file will not be used during both ARM and non-ARM builds. </p> <p>For example: </p> <codeblock id="GUID-06609D34-4569-555E-984D-6F688A45B3BA" xml:space="preserve">#if defined(WINS)

deffile-stmt

#else if defined(MARM)

deffile-stmt

#endif</codeblock> <p>Note that the platform name macros used with <codeph>#if

        defined(</codeph> <varname>identifier</varname> <codeph>)</codeph> must be in upper-case. </p> <p>In most cases, the functions exported from a DLL depend on the build variant. This is common because descriptor class names depend on whether the build is wide or narrow. For such DLLs, different <filepath>.def</filepath> files—differentiated by the <filepath>-u</filepath> suffix—are used. Although narrow builds are no longer supported, the <filepath>-u</filepath> suffix is still in use to maintain backward compatibility with previous versions of the build tools. This suffix behaviour can be removed by using <codeph>nostrictdef</codeph>. </p> <p>Note too that under WINSCW, when using an <codeph>exedll</codeph> target type, the first export is the one which will be called when the DLL is loaded, so you should use a <filepath>.def</filepath> file for the WINSCW variant. </p> <p>Makefiles create the import library associated with an executable (where applicable) directly from the frozen <filepath>.def</filepath> file, so only frozen exported functions will appear in the import library and only these exported functions can be linked against by other components. </p> <p>For ARM platforms, import libraries for compatible ABIs are also created. </p> <p>For example: </p> <ul><li id="GUID-AB341A8F-B9A0-5F01-A453-A99A9825EBF4"><p>if a project is built for <codeph>ARMv5</codeph>, then <codeph>ARMv5_ABIv1</codeph> import libraries will be created. </p> </li> <li id="GUID-58B657D6-0B87-59C3-BEA1-31F1AFA4C00C"><p>if a project is built for <codeph>ARMv5_ABIv2</codeph>, then <codeph>ARMv5_ABIv2</codeph> import libraries will be created. </p> </li> </ul> </conbody></concept>