previously mentioned, <ProductName>Postgres</ProductName> loads your code at
runtime, as required. In order to allow your code to be
dynamically loaded, you may have to compile and
- linkedit it in a special way. This section briefly
+ link-edit it in a special way. This section briefly
describes how to perform the compilation and
- linkediting required before you can load your user-defined
+ link-editing required before you can load your user-defined
functions into a running <ProductName>Postgres</ProductName> server. Note that
this process has changed as of Version 4.2.
<Tip>
<Para>
It is very easy to build dynamically-loaded object
- files under ULTRIX. ULTRIX does not have any sharedlibrary
+ files under ULTRIX. ULTRIX does not have any shared library
mechanism and hence does not place any restrictions on
the dynamic loader interface. On the other
hand, we had to (re)write a non-portable dynamic loader
% cc -G 0 -c foo.c
</ProgramListing>
produces an object file called foo.o that can then be
- dynamically loaded into <ProductName>Postgres</ProductName>. No additional loading or link-editing must be performed.
+ dynamically loaded into <ProductName>Postgres</ProductName>.
+No additional loading or link-editing must be performed.
</Para>
</Sect1>
<Para>
Under DEC OSF/1, you can take any simple object file
- and produce a shared object file by running the ld command over it with the correct options. The commands to
+ and produce a shared object file by running the ld command
+ over it with the correct options. The commands to
do this look like:
<ProgramListing>
# simple DEC OSF/1 example
what you name the
file as long as it is a shared object file. If you prefer
to name your shared object files with the extension .o, this
-is fine with <ProductName>Postgres</ProductName> so long as you make sure that the correct
+is fine with <ProductName>Postgres</ProductName>
+ so long as you make sure that the correct
file name is given to the create function command. In
other words, you must simply be consistent. However, from a
pragmatic point of view, we discourage this practice because
very simple, since the commands to do it are just:
<ProgramListing>
# simple HP-UX example
- % cc +z +u -c foo.c
- % ld -b -o foo.sl foo.o
+% cc +z +u -c foo.c
+% ld -b -o foo.sl foo.o
</ProgramListing>
</Para>
Under SunOS 4.x, the commands look like:
<ProgramListing>
# simple SunOS 4.x example
- % cc -PIC -c foo.c
- % ld -dc -dp -Bdynamic -o foo.so foo.o
+% cc -PIC -c foo.c
+% ld -dc -dp -Bdynamic -o foo.so foo.o
</ProgramListing>
and the equivalent lines under Solaris 2.x are:
<ProgramListing>
# simple Solaris 2.x example
- % cc -K PIC -c foo.c
- or
- % gcc -fPIC -c foo.c
- % ld -G -Bdynamic -o foo.so foo.o
+% cc -K PIC -c foo.c
+% ld -G -Bdynamic -o foo.so foo.o
+</ProgramListing>
+ or
+<ProgramListing>
+# simple Solaris 2.x example
+% gcc -fPIC -c foo.c
+% ld -G -Bdynamic -o foo.so foo.o
</ProgramListing>
</Para>
projects / postgresql / commitdiff