Use -O2 in the GCC examples as GCC defaults to not optimising at all.

Document using GCC's -fPIC option as the standard approach - x86 is the oddity
here and most architectures require it (or are always PIC), and on x86 it's
better to use it or else code pages from the library need relocations and can't
be shared.

Use "python2.5" rather than "python2.0" in paths in example commands.

Fix a typo.


git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@11334 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Olly Betts 2009-06-30 12:24:49 +00:00
commit 3c39833584

View file

@ -339,7 +339,7 @@ python that you run the command with. Taking apart the command line:
setup.py is the tradition) setup.py is the tradition)
<li> <tt>build_ext</tt> -- telling distutils to build extensions <li> <tt>build_ext</tt> -- telling distutils to build extensions
<li> <tt>--inplace</tt> -- this tells distutils to put the extension lib in the current dir. <li> <tt>--inplace</tt> -- this tells distutils to put the extension lib in the current dir.
Other wise, it will put it inside a build hierarchy, and you'd have to move it to use it. Otherwise, it will put it inside a build hierarchy, and you'd have to move it to use it.
</ul> </ul>
<p> <p>
@ -363,8 +363,8 @@ program using commands like this (shown for Linux):
<div class="shell"><pre> <div class="shell"><pre>
$ swig -python example.i $ swig -python example.i
$ gcc -c -fPIC example.c $ gcc -O2 -fPIC -c example.c
$ gcc -c -fPIC example_wrap.c -I/usr/local/include/python2.0 $ gcc -O2 -fPIC -c example_wrap.c -I/usr/local/include/python2.5
$ gcc -shared example.o example_wrap.o -o _example.so $ gcc -shared example.o example_wrap.o -o _example.so
</pre></div> </pre></div>
@ -654,26 +654,19 @@ compiler. For example:
<div class="shell"><pre> <div class="shell"><pre>
$ swig -c++ -python example.i $ swig -c++ -python example.i
$ g++ -c example.cxx $ g++ -O2 -fPIC -c example.cxx
$ g++ -c example_wrap.cxx -I/usr/local/include/python2.0 $ g++ -O2 -fPIC -c example_wrap.cxx -I/usr/local/include/python2.5
$ g++ -shared example.o example_wrap.o -o _example.so $ g++ -shared example.o example_wrap.o -o _example.so
</pre></div> </pre></div>
<p> <p>
On some platforms, you could also need to generate The -fPIC option tells GCC to generate position-independent code (PIC)
position-independent code (PIC), by using a compiler option such as -fPIC. which is required for most architectures (it's not vital on x86, but
Notably, the x86_64 (Opteron and EM64T) platform requires it, and when still a good idea as it allows code pages from the library to be shared between
using the GNU Compiler Suite, you will need to modify the previous example processes). Other compilers may need a different option specified instead of
as follows: -fPIC.
</p> </p>
<div class="shell"><pre>
$ swig -c++ -python example.i
$ g++ -fPIC -c example.cxx
$ g++ -fPIC -c example_wrap.cxx -I/usr/local/include/python2.0
$ g++ -shared example.o example_wrap.o -o _example.so
</pre></div>
<p> <p>
In addition to this, you may need to include additional library In addition to this, you may need to include additional library
files to make it work. For example, if you are using the Sun C++ compiler on files to make it work. For example, if you are using the Sun C++ compiler on
@ -683,7 +676,7 @@ Solaris, you often need to add an extra library <tt>-lCrun</tt> like this:
<div class="shell"><pre> <div class="shell"><pre>
$ swig -c++ -python example.i $ swig -c++ -python example.i
$ CC -c example.cxx $ CC -c example.cxx
$ CC -c example_wrap.cxx -I/usr/local/include/python2.0 $ CC -c example_wrap.cxx -I/usr/local/include/python2.5
$ CC -G example.o example_wrap.o -L/opt/SUNWspro/lib -o _example.so -lCrun $ CC -G example.o example_wrap.o -L/opt/SUNWspro/lib -o _example.so -lCrun
</pre></div> </pre></div>