Update docs with missing example.c compilation - Bug 3545858
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@13514 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
parent
4305a3cef9
commit
a358958e72
5 changed files with 10 additions and 7 deletions
|
|
@ -326,12 +326,13 @@ The exact location may vary on your machine, but the above locations are typical
|
|||
|
||||
<p>
|
||||
The JNI code exists in a dynamic module or shared library (DLL on Windows) and gets loaded by the JVM.
|
||||
To build a shared library file, you need to compile your module in a manner similar to the following (shown for Solaris):</p>
|
||||
Assuming you have code you need to link to in a file called <tt>example.c</tt>, in order to build a shared library file, you need to compile your module in a manner similar to the following (shown for Solaris):</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
$ swig -java example.i
|
||||
$ gcc -c example_wrap.c -I/usr/java/include -I/usr/java/include/solaris
|
||||
$ ld -G example_wrap.o -o libexample.so
|
||||
$ gcc -c example.c
|
||||
$ ld -G example_wrap.o example.o -o libexample.so
|
||||
</pre></div>
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -236,7 +236,7 @@ More information on building and configuring eLua can be found here: <a href="ht
|
|||
|
||||
|
||||
<p>
|
||||
Most, but not all platforms support the dynamic loading of modules (Windows & Linux do). Refer to the Lua manual to determine if your platform supports it. For compiling a dynamically loaded module the same wrapper can be used. The commands will be something like this:
|
||||
Most, but not all platforms support the dynamic loading of modules (Windows & Linux do). Refer to the Lua manual to determine if your platform supports it. For compiling a dynamically loaded module the same wrapper can be used. Assuming you have code you need to link to in a file called <tt>example.c</tt>, the commands will be something like this:
|
||||
</p>
|
||||
<div class="shell"><pre>
|
||||
$ swig -lua example.i -o example_wrap.c
|
||||
|
|
|
|||
|
|
@ -170,8 +170,8 @@ $ perl -e 'use Config; print "$Config{archlib}\n";'
|
|||
|
||||
<p>
|
||||
The preferred approach to building an extension module is to compile it into
|
||||
a shared object file or DLL. To do this, you will need to compile your program
|
||||
using commands like this (shown for Linux):
|
||||
a shared object file or DLL. Assuming you have code you need to link to in a file called <tt>example.c</tt>,
|
||||
you will need to compile your program using commands like this (shown for Linux):
|
||||
</p>
|
||||
|
||||
<div class="code"><pre>
|
||||
|
|
|
|||
|
|
@ -398,7 +398,8 @@ can add this: </p>
|
|||
<p> to the end of the <tt>extconf.rb</tt> file. If
|
||||
for some reason you don't want to use the standard approach, you'll
|
||||
need to determine the correct compiler and linker flags for your build
|
||||
platform. For example, a typical sequence of commands for the Linux
|
||||
platform. For example, assuming you have code you need to link to in a file
|
||||
called <tt>example.c</tt>, a typical sequence of commands for the Linux
|
||||
operating system would look something like this: </p>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -132,7 +132,8 @@ header file.
|
|||
|
||||
<p>
|
||||
The preferred approach to building an extension module is to compile it into
|
||||
a shared object file or DLL. To do this, you will need to compile your program
|
||||
a shared object file or DLL. Assuming you have code you need to link to in a file
|
||||
called <tt>example.c</tt>, you will need to compile your program
|
||||
using commands like this (shown for Linux):
|
||||
</p>
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue