The great merge
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@4141 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Dave Beazley
parent
6fcc22a1f8
commit
516036631c
1508 changed files with 125983 additions and 44037 deletions
6
SWIG/Tools/.cvsignore
Normal file
6
SWIG/Tools/.cvsignore
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
config.log
|
||||
config.status
|
||||
configure
|
||||
libtool
|
||||
autom4te.cache
|
||||
install-sh
|
||||
|
|
@ -1,3 +1,7 @@
|
|||
WAD 0.3 - June 2, 2002
|
||||
|
||||
- Added to the SWIG distribution.
|
||||
|
||||
WAD 0.2 - June 24, 2001
|
||||
|
||||
- Minor changes. Added the wadtrace file
|
||||
|
|
|
|||
|
|
@ -1,8 +1,5 @@
|
|||
This directory contains papers and information about WAD.
|
||||
Papers about WAD can be obtained at:
|
||||
|
||||
http://systems.cs.uchicago.edu/wad
|
||||
|
||||
python.html - WAD paper from Python9.
|
||||
usenix2001.tex - USENIX 2001 Technical conference submission.
|
||||
This paper was accepted, but the text has not yet
|
||||
been updated to final copy.
|
||||
WADTalk.pdf - Slides from the WAD Talk at Python9.
|
||||
|
||||
|
|
|
|||
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 7.8 KiB |
|
|
@ -1,860 +0,0 @@
|
|||
<html>
|
||||
<head>
|
||||
<title>WAD: A Module for Converting Fatal Extension Errors into Python Exceptions</title>
|
||||
</head>
|
||||
<body bgcolor="#ffffff">
|
||||
<center>
|
||||
|
||||
<h2>WAD: A Module for Converting Fatal Extension Errors into Python Exceptions</h2>
|
||||
<h6>David M. Beazley <br>
|
||||
Department of Computer Science<br>
|
||||
University of Chicago<br>
|
||||
Chicago, IL 60637<br>
|
||||
beazley@cs.uchicago.edu<br>
|
||||
</h6>
|
||||
</center>
|
||||
|
||||
<h3>Abstract</h3>
|
||||
<em>
|
||||
One of the more popular uses of Python is as an extension language for
|
||||
applications written in compiled languages such as C, C++, and
|
||||
Fortran. Unfortunately, one of the biggest drawbacks of this approach
|
||||
is the lack of a useful debugging and error handling facility for
|
||||
identifying problems in extension code. In part, this limitation is
|
||||
due to the fact that Python does not know anything about the internal
|
||||
implementation of an extension module. A more difficult problem is
|
||||
that compiled extensions sometimes fail with catastrophic errors such
|
||||
as memory access violations, failed assertions, and floating point
|
||||
exceptions. These types of errors fall outside the realm of normal
|
||||
Python exception handling and are particularly difficult to identify
|
||||
and debug. Although traditional debuggers can find the location of a
|
||||
fatal error, they are unable to report the context in which such an
|
||||
error has occurred with respect to a Python script. This paper describes
|
||||
an experimental system that converts fatal extension errors
|
||||
into Python exceptions. In particular, a dynamically
|
||||
loadable module, WAD (Wrapped Application Debugger), has been developed which catches
|
||||
fatal errors, unwinds the call stack, and generates Python exceptions
|
||||
with debugging information. WAD requires no modifications to Python,
|
||||
works with all extension modules, and introduces no performance
|
||||
overhead. An initial implementation of the system is currently
|
||||
available for Sun SPARC Solaris and i386-Linux.
|
||||
|
||||
</em>
|
||||
|
||||
<h3>1. Introduction</h3>
|
||||
|
||||
One of the primary reasons C, C++, and Fortran programmers are
|
||||
attracted to Python is its ability to serve as an extension language
|
||||
for compiled programs. Furthermore, tools such as SIP, CXX, Pyfort, FPIG,
|
||||
and SWIG make it extremely easy for a programmer to ``wrap'' existing
|
||||
software into an extension module [1,2,3,4,5]. Although this approach is
|
||||
extremely attractive in terms of providing a highly usable and
|
||||
flexible environment for users, extension modules suffer from
|
||||
problems not normally associated with Python
|
||||
scripts---especially when they don't work.
|
||||
|
||||
<p>
|
||||
Normally, Python programming errors result in an exception like this:
|
||||
|
||||
<blockquote><pre>
|
||||
% python foo.py
|
||||
Traceback (innermost last):
|
||||
File "foo.py", line 11, in ?
|
||||
foo()
|
||||
File "foo.py", line 8, in foo
|
||||
bar()
|
||||
File "foo.py", line 5, in bar
|
||||
spam()
|
||||
File "foo.py", line 2, in spam
|
||||
doh()
|
||||
NameError: doh
|
||||
%
|
||||
</pre></blockquote>
|
||||
|
||||
Unfortunately for compiled extensions, the following situation sometimes occurs:
|
||||
|
||||
<blockquote><pre>
|
||||
% python foo.py
|
||||
Segmentation Fault (core dumped)
|
||||
%
|
||||
</pre></blockquote>
|
||||
|
||||
Needless to say, this isn't very informative--well,
|
||||
other than indicating that something ``very bad'' happened.
|
||||
|
||||
<p>
|
||||
In order to identify the source of a fatal error, a programmer can run a
|
||||
debugger on the Python executable or on a core file like this:
|
||||
|
||||
<blockquote><pre>
|
||||
% gdb /usr/local/bin/python
|
||||
(gdb) run foo.py
|
||||
Starting program: /usr/local/bin/python foo.py
|
||||
|
||||
Program received signal SIGSEGV, Segmentation fault.
|
||||
0xff060568 in doh () from /u0/beazley/Projects/WAD/Python/./libfoo.so
|
||||
(gdb) where
|
||||
#0 0xff060568 in doh () from /u0/beazley/Projects/WAD/Python/./libfoo.so
|
||||
#1 0xff082f34 in _wrap_doh ()
|
||||
from /u0/beazley/Projects/WAD/Python/./dohmodule.so
|
||||
#2 0x2777c in call_builtin (func=0x1984b8, arg=0x1a1ccc, kw=0x0)
|
||||
at ceval.c:2650
|
||||
#3 0x27648 in PyEval_CallObjectWithKeywords (func=0x1984b8, arg=0x1a1ccc,
|
||||
kw=0x0) at ceval.c:2618
|
||||
#4 0x25d18 in eval_code2 (co=0x19acf8, globals=0x0, locals=0x1c7844,
|
||||
args=0x1984b8, argcount=1625472, kws=0x0, kwcount=0, defs=0x0, defcount=0,
|
||||
owner=0x0) at ceval.c:1951
|
||||
#5 0x25954 in eval_code2 (co=0x199620, globals=0x0, locals=0x1984b8,
|
||||
args=0x196654, argcount=1862720, kws=0x197788, kwcount=0, defs=0x0,
|
||||
#6 0x25954 in eval_code2 (co=0x19ad38, globals=0x0, locals=0x196654,
|
||||
args=0x1962fc, argcount=1862800, kws=0x198e90, kwcount=0, defs=0x0,
|
||||
defcount=0, owner=0x0) at ceval.c:1850
|
||||
#7 0x25954 in eval_code2 (co=0x1b6c60, globals=0x0, locals=0x1962fc,
|
||||
args=0x1a1eb4, argcount=1862920, kws=0x0, kwcount=0, defs=0x0, defcount=0,
|
||||
owner=0x0) at ceval.c:1850
|
||||
#8 0x22da4 in PyEval_EvalCode (co=0x1b6c60, globals=0x1962c4, locals=0x1962c4)
|
||||
at ceval.c:319
|
||||
#9 0x3adb4 in run_node (n=0x18abf8, filename=0x1b6c60 "", globals=0x1962c4,
|
||||
locals=0x1962c4) at pythonrun.c:886
|
||||
#10 0x3ad64 in run_err_node (n=0x18abf8, filename=0x1b6c60 "",
|
||||
globals=0x1962c4, locals=0x1962c4) at pythonrun.c:874
|
||||
#11 0x3ad38 in PyRun_FileEx (fp=0x18a5a8, filename=0xffbefd7a "foo.py",
|
||||
start=1616888, globals=0x1962c4, locals=0x1962c4, closeit=1)
|
||||
at pythonrun.c:866
|
||||
#12 0x3a1d8 in PyRun_SimpleFileEx (fp=0x18a5a8, filename=0xffbefd7a "foo.py",
|
||||
closeit=1) at pythonrun.c:579
|
||||
#13 0x39d84 in PyRun_AnyFileEx (fp=0x18a5a8, filename=0xffbefd7a "foo.py",
|
||||
closeit=1) at pythonrun.c:459
|
||||
#14 0x1f498 in Py_Main (argc=2, argv=0xffbefc84) at main.c:289
|
||||
#15 0x1eec0 in main (argc=2, argv=0xffbefc84) at python.c:10
|
||||
</pre></blockquote>
|
||||
|
||||
Unfortunately, even though the debugger identifies the location where the fault occurred, it
|
||||
mostly provides information about the internals of the
|
||||
interpreter. The debugger certainly doesn't reveal anything about the Python
|
||||
program that led to the error (i.e., it doesn't reveal the
|
||||
same information that would be contained in a Python traceback). As a result,
|
||||
the debugger is of limited use when it comes to debugging an application that
|
||||
consists of both compiled and Python code.
|
||||
|
||||
<p>
|
||||
Normally, extension developers try to avoid catastrophic errors by
|
||||
adding error handling. If
|
||||
an application is small or customized for use with Python, it can be
|
||||
modified to raise Python exceptions.
|
||||
Automated tools such as SWIG can also convert C++
|
||||
exceptions and C-related error handling mechanisms into Python
|
||||
exceptions. However, no matter how much error checking is added,
|
||||
there is always a chance that an extension will fail in an unexpected
|
||||
manner. This is especially true for large applications that have been wrapped
|
||||
into an extension module. In addition, certain types of errors such as floating
|
||||
point exceptions (e.g., division by zero) are especially difficult to find
|
||||
and eliminate. Finally, rigorous error checking may be omitted to improve
|
||||
performance.
|
||||
|
||||
<p>
|
||||
To address these problems, an experimental module known as WAD (Wrapped
|
||||
Application Debugger) has been developed.
|
||||
WAD is able to
|
||||
convert fatal errors into Python exceptions that include information
|
||||
from the call stack as well as debugging
|
||||
information. By turning such errors into Python exceptions, fatal
|
||||
errors now result in a traceback that crosses the boundary between
|
||||
Python code and compiled extension code. This makes it much
|
||||
easier to identify and correct extension-related programming errors.
|
||||
WAD requires no modifications to Python and is compatible with all
|
||||
extension modules. However, it is also highly platform specific
|
||||
and currently only runs on Sun Sparc
|
||||
Solaris and i386-Linux. The primary goal of this paper is to motivate the problem
|
||||
and to describe one possible solution. In addition, many of the
|
||||
implementation issues
|
||||
associated with providing an integrated error reporting mechanism are described.
|
||||
|
||||
<h3>2. An Example</h3>
|
||||
|
||||
WAD can either be imported as a Python extension module or linked to an
|
||||
extension module. To illustrate, consider the earlier example:
|
||||
|
||||
<blockquote><pre>
|
||||
% python foo.py
|
||||
Segmentation Fault (core dumped)
|
||||
%
|
||||
</pre></blockquote>
|
||||
|
||||
To identify the problem, a programmer can run Python interactively and import WAD as follows:
|
||||
|
||||
<blockquote><pre>
|
||||
% python
|
||||
Python 2.0 (#1, Oct 27 2000, 14:34:45)
|
||||
[GCC 2.95.2 19991024 (release)] on sunos5
|
||||
Type "copyright", "credits" or "license" for more information.
|
||||
>>> import libwadpy
|
||||
WAD Enabled
|
||||
>>> execfile("foo.py")
|
||||
Traceback (most recent call last):
|
||||
File "<stdin>", line 1, in ?
|
||||
File "foo.py", line 16, in ?
|
||||
foo()
|
||||
File "foo.py", line 13, in foo
|
||||
bar()
|
||||
File "foo.py", line 10, in bar
|
||||
spam()
|
||||
File "foo.py", line 7, in spam
|
||||
doh.doh(a,b,c)
|
||||
SegFault: [ C stack trace ]
|
||||
|
||||
#2 0x00027774 in call_builtin(func=0x1c74f0,arg=0x1a1ccc,kw=0x0)
|
||||
#1 0xff022f7c in _wrap_doh(0x0,0x1a1ccc,0x160ef4,0x9c,0x56b44,0x1aa3d8)
|
||||
#0 0xfe7e0568 in doh(a=0x3,b=0x4,c=0x0) in 'foo.c', line 28
|
||||
|
||||
/u0/beazley/Projects/WAD/Python/foo.c, line 28
|
||||
|
||||
int doh(int a, int b, int *c) {
|
||||
=> *c = a + b;
|
||||
return *c;
|
||||
}
|
||||
|
||||
>>>
|
||||
</pre></blockquote>
|
||||
|
||||
In this case, we can
|
||||
see that the program has tried to assign a value to a
|
||||
NULL pointer (indicated by the value "c=0x0" in the last function call). Furthermore, we obtain a Python traceback that shows the
|
||||
entire sequence of functions leading to the problem. Finally, since
|
||||
control returned to the interpreter, it is possible to interactively
|
||||
inspect various aspects of the application or to continue with the computation
|
||||
(although this clearly depends on the severity of the error and the nature of the application).
|
||||
|
||||
<p>
|
||||
In certain applications, it may be difficult to run Python
|
||||
interactively or to modify the code to explicitly import a special
|
||||
debugging module. In these cases, WAD can be attached to an extension module with the
|
||||
linker. For example:
|
||||
|
||||
<blockquote><pre>
|
||||
% ld -G $(OBJS) -o dohmodule.so -lwadpy
|
||||
</pre></blockquote>
|
||||
|
||||
This requires no recompilation of any source code--only a relinking of the
|
||||
extension module. When Python loads the relinked extension module, WAD is automatically
|
||||
initialized before Python invokes the module initialization function.
|
||||
|
||||
<h3>3. Design Considerations for Embedded Error Recovery</h3>
|
||||
|
||||
The primary design goal of WAD is provide an error reporting mechanism
|
||||
for extension modules that is a natural extension of normal Python
|
||||
exception handling. There are two primary motivations for
|
||||
handling fatal errors in this manner: first, in the context of Python
|
||||
programming, it is simply unnatural to run a separate debugging
|
||||
application to identify a problem in an extension module when no such
|
||||
requirement exists for scripts. Thus, an embedded error reporting
|
||||
mechanism is simply more convenient. Second, the target users
|
||||
of an extension module may not know how to use a debugger or even have
|
||||
a development environment installed on their machine. Therefore,
|
||||
the ability to produce an informative traceback within the
|
||||
confines of the Python interpreter can be of tremendous value to an
|
||||
extension developer. This is because users who report a problem will
|
||||
be able to include an informative traceback as opposed to simply
|
||||
saying ``the code crashed.''
|
||||
|
||||
<p>
|
||||
A secondary design goal is to provide a system that is as non-invasive
|
||||
as possible. The system should not require modifications to Python or
|
||||
any extension modules and it should be easy to integrate
|
||||
into the runtime environment of an application. In addition, it shouldn't
|
||||
introduce any performance overhead.
|
||||
|
||||
<p>
|
||||
Finally, since WAD co-exists with the Python interpreter (i.e., in the same
|
||||
process), there are a number of technical issues that have to be
|
||||
addressed. First, fatal errors can theoretically occur anywhere in
|
||||
the interpreter as well as in extension modules. Therefore, WAD needs
|
||||
to know about Python's internal organization if it is going to provide
|
||||
a graceful recovery back to the interpreter. Second, in order to
|
||||
implement this recovery scheme, the system has to perform direct
|
||||
manipulation of the CPU context and call stack. Last, but not least,
|
||||
since the recovery code lives in the same address space as the
|
||||
interpreter and extension modules it should not depend on the process
|
||||
stack and heap (since both could have been corrupted by the faulting
|
||||
application).
|
||||
|
||||
<h3>4. Catching Fatal Errors</h3>
|
||||
|
||||
WAD catches catastrophic errors by installing a
|
||||
reliable signal handler for SIGSEGV, SIGBUS, SIGABRT, SIGILL, and SIGFPE [9]. Unlike the
|
||||
more familiar BSD-style signal interface (as provided by the Python
|
||||
signal module), reliable signal handlers are installed using the <tt>sigaction()</tt> system call and have a few notable properties:
|
||||
|
||||
<ul>
|
||||
<li> The signal handler can be configured to run on its own dedicated stack.
|
||||
|
||||
<p>
|
||||
<li> Handler functions can receive a structure containing the CPU context
|
||||
including the CPU registers, program counter, and stack pointer.
|
||||
|
||||
<p>
|
||||
<li> Changes to the CPU context take effect immediately after the signal handler returns.
|
||||
</ul>
|
||||
|
||||
Therefore, the high level implementation of WAD is relatively straightforward: when a fatal signal occurs,
|
||||
a handler function runs on an isolated signal handling stack.
|
||||
The CPU context is then used to unwind the call stack and to inspect the process state. Finally,
|
||||
if possible, the CPU context is modified in a manner that allows the signal handler to
|
||||
return to Python with a raised exception.
|
||||
|
||||
<h3>5. A Detailed Description of the Recovery Mechanism</h3>
|
||||
|
||||
In this section, a more detailed description of the error recovery
|
||||
scheme is presented. The precise implementation details of this are
|
||||
highly platform specific and involve a number of advanced topics including
|
||||
the Unix process file system (/proc), the ELF object file format, and the
|
||||
Stabs compiler debugging format [6,7,8]. The details of these topics are
|
||||
beyond the scope of this paper. However, this section hopes to
|
||||
give the reader a small taste of the steps involved in implementing the recovery mechanism.
|
||||
|
||||
<P>
|
||||
The services of WAD are only invoked upon the reception of a fatal
|
||||
signal. This triggers a signal handling function that results in a return to Python
|
||||
as illustrated in the following figure:
|
||||
|
||||
<center>
|
||||
<img src="fig1.png">
|
||||
<h6>Control flow of the error recovery mechanism</h6>
|
||||
</center>
|
||||
|
||||
<p>
|
||||
The steps required to implement this recovery are as follows:
|
||||
|
||||
<ol>
|
||||
<li> The values of the program counter and stack pointer are obtained from the CPU
|
||||
context structure passed to the WAD signal handler.
|
||||
|
||||
<p>
|
||||
<li> The virtual memory map of the process is inspected to identify all of
|
||||
the shared libraries, dynamically loaded modules, and valid memory regions.
|
||||
This information is obtained by reading from the Unix /proc filesystem.
|
||||
The following table illustrates the nature of this data:
|
||||
|
||||
|
||||
<blockquote><pre>
|
||||
Address Size Permissions File
|
||||
---------- ----- ----------------- ---------------------------------
|
||||
00010000 1264K read/exec /usr/local/bin/python
|
||||
0015A000 184K read/write/exec /usr/local/bin/python
|
||||
00188000 296K read/write/exec [ heap ]
|
||||
FE7C0000 32K read/exec /u0/beazley/Projects/dohmodule.so
|
||||
FE7D6000 8K read/write/exec /u0/beazley/Projects/dohmodule.so
|
||||
...
|
||||
FF100000 664K read/exec /usr/lib/libc.so.1
|
||||
FF1B6000 24K read/write/exec /usr/lib/libc.so.1
|
||||
FF1BC000 8K read/write/exec /usr/lib/libc.so.1
|
||||
FF2C0000 120K read/exec /usr/lib/libthread.so.1
|
||||
FF2EE000 8K read/write/exec /usr/lib/libthread.so.1
|
||||
FF2F0000 48K read/write/exec /usr/lib/libthread.so.1
|
||||
FF310000 40K read/exec /usr/lib/libsocket.so.1
|
||||
FF32A000 8K read/write/exec /usr/lib/libsocket.so.1
|
||||
FF330000 24K read/exec /usr/lib/libpthread.so.1
|
||||
FF346000 8K read/write/exec /usr/lib/libpthread.so.1
|
||||
FF350000 8K read/write/exec [ anon ]
|
||||
FF3B0000 8K read/exec /usr/lib/libdl.so.1
|
||||
FF3C0000 128K read/exec /usr/lib/ld.so.1
|
||||
FF3E0000 8K read/write/exec /usr/lib/ld.so.1
|
||||
FFBEA000 24K read/write/exec [ stack ]
|
||||
</pre></blockquote>
|
||||
|
||||
<p>
|
||||
<li> The call stack is unwound to produce a traceback of the
|
||||
calling sequence that led to the error. The unwinding process is just a simple
|
||||
loop that is similar to the following:
|
||||
|
||||
<blockquote><pre>
|
||||
long *pc = get_pc(context);
|
||||
long *sp = get_sp(context);
|
||||
while (sp) {
|
||||
/* Move to previous stack frame */
|
||||
pc = (long *) sp[15]; /* %i7 register on SPARC */
|
||||
sp = (long *) sp[14]; /* %i6 register on SPARC */
|
||||
}
|
||||
</pre></blockquote>
|
||||
|
||||
<li> For each stack frame, symbol table and debugging information
|
||||
is gathered and stored in a WAD exception frame object.
|
||||
Obtaining this information is the most complicated part of WAD and involves
|
||||
the following steps: first, the current program counter is mapped to an object file
|
||||
using the virtual memory map obtained in step 2. Next, the object file is loaded
|
||||
using mmap(). Once loaded, the ELF symbol table
|
||||
is searched for an address match. The symbol table contains a collection of records
|
||||
containing memory offsets, sizes, and names such as this:
|
||||
|
||||
<blockquote><pre>
|
||||
Offset Size Name
|
||||
-------- ------ ---------
|
||||
0x1280 324 wrap_foo
|
||||
0x1600 128 foo
|
||||
0x2408 192 bar
|
||||
...
|
||||
</pre></blockquote>
|
||||
|
||||
To find a match for a virtual memory address <em>addr</em>, WAD simply
|
||||
searches for a symbol <em>s</em> such that <em>base</em> +
|
||||
<em>s</em>.offset <= <em>addr</em> < <em>base</em> +
|
||||
<em>s</em>.offset + <em>s</em>.size, where <em>base</em> is the base
|
||||
virtual address of the object file in the virtual memory map.
|
||||
|
||||
<p>
|
||||
Debugging information, if available, is scanned to identify a source
|
||||
file, function name, and line number. This involves scanning object files for a
|
||||
table of debugging information stored in a format
|
||||
known as ``stabs.''. Stabs is a relatively simple, but highly extensible format that
|
||||
is language independent and capable of encoding almost every aspect of the
|
||||
original source code. For the purposes of WAD, only a small subset of this
|
||||
data is actually used.
|
||||
|
||||
<p>
|
||||
The following table shows a small fragment of relevant stabs data:
|
||||
<blockquote><pre>
|
||||
type desc value string description
|
||||
------ ----- --------- --------------------------- -----------
|
||||
0x64 0 0 /u0/beazley/Projects/foo/ Pathname
|
||||
0x64 0 0 foo.c Filename
|
||||
...
|
||||
0x24 0 0 foo:F(0,3);(0,3) Function
|
||||
0xa0 4 68 n:p(0,3) Parameter
|
||||
...
|
||||
0x44 6 8 Line number
|
||||
0x44 7 12 Line number
|
||||
0x44 8 44 Line number
|
||||
0x44 9 56 Line number
|
||||
...
|
||||
</pre></blockquote>
|
||||
|
||||
In the table, the type field indicates the type of debugging information. For
|
||||
example, 0x64 specifies the source file, 0x24 is a function
|
||||
definition, 0xa0 is a function parameter, and 0x44 is line number
|
||||
information. Associated with each stab is a collection of parameters
|
||||
and an optional string. The string usually contains symbol names and
|
||||
other information. The <tt>desc</tt> and <tt>value</tt> fields are numbers
|
||||
that usually contain byte offsets and line number data.
|
||||
Therefore, to collect debugging information, WAD simply walks through the debugging
|
||||
tables until it finds the function of interest. Once found, parameter and line
|
||||
number specifiers are inspected to determine the location and values of the function
|
||||
arguments as well the source line at which the error occurred.
|
||||
|
||||
<p>
|
||||
<li> After the complete traceback has been obtained, it is examined to see if
|
||||
there are any ``safe'' return points to which control can be returned.
|
||||
This is accomplished by maintaining an internal table of predefined symbolic return
|
||||
points as shown in the following table:
|
||||
|
||||
<blockquote><pre>
|
||||
Python symbol Return value
|
||||
----------------------------- ------------------
|
||||
call_builtin NULL
|
||||
_PyImport_LoadDynamicModule NULL
|
||||
PyObject_Repr NULL
|
||||
PyObject_Print -1
|
||||
PyObject_CallFunction NULL
|
||||
PyObject_CallMethod NULL
|
||||
PyObject_CallObject NULL
|
||||
PyObject_Cmp -1
|
||||
PyObject_Compare -1
|
||||
PyObject_DelAttrString -1
|
||||
PyObject_DelItem -1
|
||||
PyObject_GetAttrString NULL
|
||||
PyObject_GetItem NULL
|
||||
PyObject_HasAttrString -1
|
||||
PyObject_Hash -1
|
||||
PyObject_Length -1
|
||||
PyObject_SetAttrString -1
|
||||
PyObject_SetItem -1
|
||||
PyObject_Str NULL
|
||||
PyObject_Type NULL
|
||||
...
|
||||
PyEval_EvalCode NULL
|
||||
</pre></blockquote>
|
||||
|
||||
The symbols in this table correspond to functions within the Python interpreter that
|
||||
might execute extension code and include the parts of the interpreter that invoke builtin functions
|
||||
as well as the functions from the abstract object interface.
|
||||
If any of these symbols appear on the call stack,
|
||||
a handler function is invoked to raise a Python exception.
|
||||
This handler function
|
||||
is given a WAD-specific traceback object that contains a copy of the
|
||||
call stack and CPU registers as well as any symbolic and debugging
|
||||
information that was obtained. If none of the symbolic return points
|
||||
are encountered, WAD invokes a default handler that simply prints the
|
||||
full C stack trace and generates a core file.
|
||||
|
||||
<P>
|
||||
<li> If a return point is found, the CPU context is modified in a manner that allows the signal handler to return
|
||||
with a suitable Python error.
|
||||
This last step is the most tricky part of the recovery process, but the general
|
||||
idea is that CPU context is modified in a way that makes Python think that
|
||||
an extension function simply raised an exception and returned an error. Currently, this
|
||||
is implemented by having the signal handler return to a small
|
||||
handler function written in assembly language which arranges to return the
|
||||
desired value back to the specified return point.
|
||||
|
||||
<p>
|
||||
The most complicated part of modifying the CPU context is that of restoring
|
||||
previously saved CPU registers. By manually unwinding the call stack, the
|
||||
WAD exception handler effectively performs the same operation as a longjmp() call in C.
|
||||
However, unlike longjmp(), no previously saved set of CPU registers are available from which to resume
|
||||
execution in the Python interpreter. The solution to this problem depends entirely on the
|
||||
underlying architecture. On the SPARC, register values are saved in register windows
|
||||
which WAD manually unwinds to restore the proper state. On the Intel, the solution is much
|
||||
more interesting. To restore the register values, WAD must manually inspect the
|
||||
machine instructions of each function on the call stack in order to find out where the
|
||||
registers might have been saved. This information is then used to restore the registers from their
|
||||
saved locations before returning to the Python interpreter.
|
||||
|
||||
<p>
|
||||
<li> Python receives the exception and produces a traceback.
|
||||
</ol>
|
||||
|
||||
<h3>6. Initialization and Loading</h3>
|
||||
|
||||
In the earlier example, it was shown that WAD could be both
|
||||
loaded as an extension module or simply attached to an existing module
|
||||
with the linker. This latter case is implemented by
|
||||
wrapping the WAD initialization function inside the constructor of a
|
||||
statically allocated C++ object like this:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
class WadInit {
|
||||
public:
|
||||
WadInit() {
|
||||
wad_init(); /* Call the real initialization function */
|
||||
}
|
||||
};
|
||||
static WadInit wad_initializer;
|
||||
</pre></blockquote>
|
||||
|
||||
When the dynamic loader brings WAD into memory, it automatically
|
||||
executes the constructors of all statically allocated C++ objects.
|
||||
Therefore, this initialization code executes immediately after
|
||||
loading, but before Python actually calls the module initialization
|
||||
function. As a result, when an extension module is linked with WAD,
|
||||
the debugging capability is enabled before any other operations occur---this
|
||||
allows WAD to respond to fatal errors that might occur during module
|
||||
initialization.
|
||||
|
||||
The rest of the initialization process consists of the following:
|
||||
<ul>
|
||||
<li> The WAD signal handler is installed.
|
||||
<li> A collection of return symbols are registered with the signal handler (see the previous section).
|
||||
<li> Four new Python exception objects <tt>SegFault</tt>, <tt>BusError</tt>, <tt>AbortError</tt>,
|
||||
and <tt>IllegalInstruction</tt> are added
|
||||
to the <tt>__builtin__</tt> module.
|
||||
</ul>
|
||||
|
||||
Although the use of a C++ static constructor has the potential to
|
||||
conflict with C++ extension code that also uses static constructors,
|
||||
it is always possible to enable WAD prior to loading a C++ extension
|
||||
(e.g., WAD could be loaded separately).
|
||||
|
||||
<h3>7. Implementation Details</h3>
|
||||
|
||||
Currently, WAD is written in ANSI C with a small amount of C++,
|
||||
and a small amount of assembly code (to assist in the return to the interpreter).
|
||||
The entire implementation contains approximately 2000 semicolons and most of the code
|
||||
relates to the gathering of source code information (symbol tables,
|
||||
debugging information, etc.).
|
||||
|
||||
<p>
|
||||
Although there are libraries such as GNU bfd that can assist with the
|
||||
reading of object files, none of these are used in the implementation [10].
|
||||
First, these libraries tend to be quite large
|
||||
and are oriented more towards stand-alone tools such as debuggers,
|
||||
linkers, and compilers. Second, due to usual nature of the runtime
|
||||
environment and the restrictions on memory utilization (no heap, no
|
||||
stack), the behavior of these libraries is somewhat unclear and
|
||||
would require further study.
|
||||
Finally, given the small size of the prototype implementation, it didn't seem necessary to rely on a
|
||||
large general purpose library.
|
||||
|
||||
<h3>8. Discussion</h3>
|
||||
|
||||
The primary focus of this work is to provide a more useful error
|
||||
reporting mechanism to extension developers.
|
||||
However, this does not imply that
|
||||
WAD is appropriate as a general purpose exception
|
||||
handling mechanism. First, let's focus
|
||||
on the recovery mechanism:
|
||||
|
||||
<ul>
|
||||
<li> When WAD unwinds the call stack, objects allocated on the stack
|
||||
are lost. This may interact poorly with C++ extensions since the
|
||||
unwinding process does not invoke C++ destructors. It may be possible to fix
|
||||
this problem, but doing so would require coordination with the C++ runtime library.
|
||||
|
||||
<p>
|
||||
<li> Similarly, if a procedure allocates objects on the heap, stack unwinding
|
||||
may cause those objects to never be reclaimed.
|
||||
|
||||
<p>
|
||||
<li> Closely related to heap management, stack unwinding may result in
|
||||
open files, sockets, and other system resources. Furthermore, in a multithreaded
|
||||
environment, deadlock may occur if a procedure is holding a lock when an error occurs.
|
||||
|
||||
<p>
|
||||
<li> An application may fail by overwriting the process heap and corrupting
|
||||
memory. Although WAD can produce internal diagnostics even when the heap has been
|
||||
destroyed, Python may fail immediately upon return from the
|
||||
WAD signal handler or shortly thereafter.
|
||||
|
||||
<p>
|
||||
<li> If an application destroys the call stack (via buffer overflow), WAD will
|
||||
be unable to complete a stack trace and will be unable to return to
|
||||
Python.
|
||||
|
||||
<p>
|
||||
<li> Memory management problems such as double-freeing of memory are particularly
|
||||
difficult to identify. If an extension module corrupts the memory allocator
|
||||
in some manner, this may cause Python to fail in a completely unexpected location.
|
||||
WAD is usually able to produce a traceback in this situation, but
|
||||
it may not correspond to the real source of the problem.
|
||||
|
||||
</ul>
|
||||
|
||||
In addition, there are a number of issues that pertain to WAD's interaction with the
|
||||
Python interpreter:
|
||||
|
||||
<ul>
|
||||
<li> The recovery mechanism is entirely based on symbolic information stored
|
||||
in the Python executable. Therefore, the return points are simply specified
|
||||
as strings such as ``call_builtin'' as opposed to real memory addresses.
|
||||
Because of this, WAD is compatible with essentially any version of Python (provided
|
||||
it supports class-based exceptions).
|
||||
|
||||
<P>
|
||||
<li> WAD is unable to manage multiple return values to same procedure.
|
||||
For example, Python's <tt>eval_code2()</tt> procedure contains a huge
|
||||
case statement for executing byte codes. Within this procedure, certain
|
||||
function calls return NULL to indicate an error and others return -1. Since WAD
|
||||
is unable to determine which value to return, this particular procedure does not make a very
|
||||
good return point for error recovery.
|
||||
|
||||
<P>
|
||||
<li> An alternative approach to the symbolic recovery scheme would be to
|
||||
instrument Python with a collection of safe return points using setjmp()/longjmp().
|
||||
This approach is not used because it would require a significant number of changes to
|
||||
the interpreter and it would introduce an unacceptable amount of performance overhead.
|
||||
|
||||
<p>
|
||||
<li> WAD is generally safe to use with Python threads. However, if a
|
||||
compiled extension function manually releases the Python interpreter
|
||||
lock and subsequently faults, the return behavior is unspecified. In
|
||||
the future, it may be possible to use the interpreter lock to provide coordination
|
||||
between the interpreter and the error recovery mechanism.
|
||||
|
||||
<p>
|
||||
<li> Compiled extension code may perform an eval operation in which Python code is executed
|
||||
in the interpreter. This results in a situation where the complete call-stack of an
|
||||
application crosses the boundary between Python and C several times. WAD can
|
||||
still handle faults in this setting as long as an application is doing a reasonable amount of
|
||||
error checking. For example, a fatal error that occurs inside an eval operation could
|
||||
be caught by the extension code and propagated further up the call stack.
|
||||
|
||||
<p>
|
||||
<li> In certain cases, Python may be configured to handle the SIGFPE signal for floating point
|
||||
exceptions. The default Python handling of this error is to abort and dump core. However,
|
||||
with WAD, a complete stack traceback will be obtained when a SIGFPE occurs.
|
||||
|
||||
<p>
|
||||
<li> WAD is extremely inefficient. Due to restrictions on the heap and stack,
|
||||
WAD relies heavily on mmap() and a variety of other file
|
||||
operations as it handles errors. It also performs linear searches of symbol and
|
||||
debugging tables. As a result, WAD's generation of a
|
||||
Python exception is several orders of magnitude slower than an ordinary
|
||||
exception.
|
||||
</ul>
|
||||
|
||||
Finally, there are a number of application specific issues to note:
|
||||
|
||||
<ul>
|
||||
<li> Aggressive compiler optimization techniques may prevent WAD from
|
||||
accurately reporting locations within the original source code.
|
||||
This is particularly problematic with numerical applications where
|
||||
techniques such procedure inlining can make it impossible to obtain accurate
|
||||
debugging information. Since these types of problems also arise in
|
||||
full-featured debuggers, it is unlikely that they can be easily fixed in WAD (at least not
|
||||
without a considerable amount of work).
|
||||
|
||||
<p>
|
||||
<li> If an application implements its own exception handling,
|
||||
it may provide Python with less information than what would obtained with WAD.
|
||||
For example, a programmer might implement a function like this:
|
||||
|
||||
<blockquote><pre>
|
||||
void *Malloc(int size) {
|
||||
void *ptr;
|
||||
ptr = malloc(size);
|
||||
if (!ptr) throw("Out of memory");
|
||||
return ptr;
|
||||
}
|
||||
</pre></blockquote>
|
||||
|
||||
In this case, the ``throw'' function may initiate an internal
|
||||
exception handling mechanism that relies upon setjmp/longjmp or C++ exceptions.
|
||||
When the error eventually makes it back to the interpreter, the user will get an ``out
|
||||
of memory'' exception, but no additional information will be
|
||||
provided. In contrast, if the programmer simply used an <tt>assert()</tt> statement, WAD would produce a full stack trace leading to
|
||||
the error.
|
||||
</ul>
|
||||
|
||||
|
||||
Despite its various limitations, WAD is applicable to a wide range of
|
||||
extension-related errors. Furthermore, most of the errors that are
|
||||
likely to occur are of a more benign variety. For example, a
|
||||
segmentation fault may simply be the result of an uninitialized
|
||||
pointer (perhaps the user forgot to call an initialization procedure).
|
||||
Likewise, bus errors, failed assertions, and floating point exceptions
|
||||
rarely result in a situation where the WAD recovery mechanism would be
|
||||
unable to produce a meaningful Python traceback.
|
||||
|
||||
<h3>9. Related Work</h3>
|
||||
|
||||
There is a huge body of literature concerning the implementation of
|
||||
exception handling in various programming languages and environments.
|
||||
A detailed discussion of this work is clearly not possible here, but
|
||||
a general overview of various exception handling issues can be found in [11].
|
||||
In general, there are a few themes that seem to prevail.
|
||||
First,
|
||||
considerable attention has been given to exception handling mechanisms
|
||||
in specific languages such as efficient exception handling for C++.
|
||||
Second, a great deal of work has been given to the semantic aspects of
|
||||
exception handling such as exception hierarchies, finalization, and
|
||||
whether or not code is restartable after an exception has occurred.
|
||||
Finally, a fair amount of exception work has been done in the context
|
||||
of component frameworks and distributed systems. Most of this work
|
||||
tends to concentrate on explicit exception handling mechanisms. Very little
|
||||
work appears to have been done in the area of converting hardware generated errors
|
||||
into exceptions.
|
||||
|
||||
<p>
|
||||
With respect to debuggers, quite a lot of work has been done in
|
||||
creating advanced debugging support for specific languages and
|
||||
integrated development environments. However, very little of this work
|
||||
has concentrated on the problem of extensible systems and
|
||||
compiled-interpreted language integration. For instance, debuggers
|
||||
for Python are currently unable to cross over into C extensions whereas C
|
||||
debuggers aren't able to easily extract useful information from the
|
||||
internals of the Python interpreter.
|
||||
|
||||
<p>
|
||||
One system of possible interest is Rn which was developed in the
|
||||
mid-1980s at Rice University [12]. This system, primarily
|
||||
designed for working with large scientific applications written in
|
||||
Fortran, provided an execution monitor that consisted of a special
|
||||
debugging process with an embedded interpreter. When attached to
|
||||
compiled Fortran code, this monitor could dynamically patch
|
||||
the executable in a manner that allowed parts of the code to be executed in the
|
||||
interpreter. This was used to provide a debugging environment in which
|
||||
essentially any part of the compiled application could be modified at
|
||||
run-time by simply compiling the modified code (Fortran) to an
|
||||
interpreted form and inserting a breakpoint in the original executable
|
||||
that transferred control to the interpreter. Although this
|
||||
particular scheme is not directly related to the functionality
|
||||
of WAD, it is one of the few systems in which
|
||||
interpreted and compiled code have been tightly coupled within
|
||||
a debugging framework. Several aspects of the interpreted/compiled
|
||||
interface are closely related to way in which WAD operates. In addition,
|
||||
various aspects of this work may be useful should WAD be extended with
|
||||
new capabilities.
|
||||
|
||||
<h3>10. Future Directions</h3>
|
||||
|
||||
WAD is currently an experimental prototype. Although this paper has
|
||||
described its use with Python, the core of the system is generic and
|
||||
is easily extended to other programming environments. For example, when
|
||||
linked to C/C++ code, WAD will automatically produce stack
|
||||
traces for fatal errors. A module for generating Tcl exceptions has
|
||||
also been developed. Plans are underway to provide support for other
|
||||
extensible systems including Perl, Ruby, and Guile.
|
||||
|
||||
<p>
|
||||
Finally, a number of extensions to the WAD approach may be possible.
|
||||
For example, even though the current implementation only returns a
|
||||
traceback string to the Python interpreter, the WAD signal handler
|
||||
actually generates a full traceback of the C call stack including all
|
||||
of the CPU registers and a copy of the stack data. Therefore, with a
|
||||
little work, it may be possible to implement a diagnostic tool that
|
||||
allows the state of the C stack to be inspected from the Python
|
||||
interpreter after a crash has occurred. Similarly, it may be possible
|
||||
to integrate the capabilities of WAD with those provided by the Python
|
||||
debugger.
|
||||
|
||||
<h3>11. Conclusions and Availability</h3>
|
||||
|
||||
WAD provides a simple mechanism for converting fatal errors into
|
||||
Python exceptions that provide useful information to extension
|
||||
writers. In doing so, it solves one of the most frustrating aspects
|
||||
of working with compiled Python extensions--that of identifying program errors.
|
||||
Furthermore the system requires no code modifications to Python and introduces
|
||||
no performance overhead.
|
||||
Although the system is
|
||||
necessarily platform specific, the system does not involve a
|
||||
significant amount of code. As a result, it may be relatively
|
||||
straightforward to port to other Unix systems.
|
||||
|
||||
<p>
|
||||
As of this writing, WAD is still undergoing active development. However,
|
||||
the software is available for experimentation and download at
|
||||
at <tt>http://systems.cs.uchicago.edu/wad</tt>.
|
||||
|
||||
<h3>References</h3>
|
||||
|
||||
[1] D.M. Beazley, <em>Using SWIG to Control, Prototype, and Debug C Programs with Python</em>,
|
||||
4th International Python Conference, Livermore, CA. (1996).
|
||||
|
||||
<p>
|
||||
[2] P.F. Dubois, <em>Climate Data Analysis Software</em>, 8th International Python Conference,
|
||||
Arlington, VA. (2000).
|
||||
|
||||
<p>
|
||||
[3] P.F. Dubois, <em>A Facility for Creating Python Extensions in C++</em>, 7th International Python
|
||||
Conference, Houston, TX. (1998).
|
||||
|
||||
<p>
|
||||
[4] SIP. <tt>http://www.thekompany.com/projects/pykde/</tt>.
|
||||
|
||||
<p>
|
||||
[5] FPIG. <tt>http://cens.ioc.ee/projects/f2py2e/</tt>.
|
||||
|
||||
<p>
|
||||
[6] R. Faulkner and R. Gomes, <em>The Process File System and Process Model in UNIX System V</em>, USENIX Conference Proceedings,
|
||||
January 1991.
|
||||
|
||||
<p>
|
||||
[7] J.R. Levine, <em>Linkers & Loaders.</em> Morgan Kaufmann Publishers, 2000.
|
||||
|
||||
<p>
|
||||
[8] Free Software Foundation, <em>The "stabs" debugging format</em>. GNU info document.
|
||||
|
||||
<p>
|
||||
[9] W. Richard Stevens, <em>UNIX Network Programming: Interprocess Communication, Volume 2</em>. PTR
|
||||
Prentice-Hall, 1998.
|
||||
|
||||
<p>
|
||||
[10] S. Chamberlain. <em>libbfd: The Binary File Descriptor Library</em>. Cygnus Support, bfd version 3.0 edition, April 1991.
|
||||
|
||||
<p>
|
||||
[11] M.L. Scott. <em>Programming Languages Pragmatics</em>. Morgan Kaufmann Publishers, 2000.
|
||||
|
||||
<p>
|
||||
[12] A. Carle, D. Cooper, R. Hood, K. Kennedy, L. Torczon, S. Warren, <em>A Practical Environment for Scientific Programming.</em>
|
||||
IEEE Computer, Vol 20, No. 11, (1987). p. 75-89.
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -327,10 +327,13 @@ The scripts debug.py, debug.tcl, debug.pl can be used to test these extensions.
|
|||
|
||||
8. Documentation
|
||||
|
||||
No official documentation exists at this time. However, the Papers
|
||||
directory contains two conference papers that describe WAD's design
|
||||
and high-level operation. Slides from the Python9 talk are also
|
||||
included.
|
||||
No official documentation exists at this time. However, details
|
||||
of WAD's design and implementation can be found in papers presented
|
||||
at the Ninth International Python Conference and the 2000 USENIX
|
||||
Technical Conference. Both papers can be obtained at:
|
||||
|
||||
http://systems.cs.uchicago.edu/wad
|
||||
|
||||
|
||||
9. To-Do
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ dnl to nothing) and `test -z "$VAR"' or `test -n "$VAR"' as the
|
|||
dnl case may be. --ttn, 2000/08/04 12:11:26
|
||||
|
||||
AC_INIT(Include/wad.h)
|
||||
AC_PREREQ(2.0)
|
||||
AC_PREREQ(2.53)
|
||||
|
||||
# Set name for machine-dependent library files
|
||||
AC_SUBST(MACHDEP)
|
||||
|
|
|
|||
3704
SWIG/Tools/aclocal.m4
vendored
Normal file
3704
SWIG/Tools/aclocal.m4
vendored
Normal file
File diff suppressed because it is too large
Load diff
5
SWIG/Tools/capitalize
Executable file
5
SWIG/Tools/capitalize
Executable file
|
|
@ -0,0 +1,5 @@
|
|||
#!/bin/sh
|
||||
# usage: capitalize word
|
||||
# write word to stdout w/ first character upcased
|
||||
first_char=`echo $1 | sed 's/^\(.\).*/\1/' | tr a-z A-Z`
|
||||
echo ${first_char}`echo $1 | sed 's/^.//'`
|
||||
20
SWIG/Tools/check-include-path.pike
Normal file
20
SWIG/Tools/check-include-path.pike
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
/**
|
||||
* This is a helper script to identify the proper include path
|
||||
* for Pike header files. It should be run with the full path
|
||||
* to the Pike executable as its single argument, e.g.
|
||||
*
|
||||
* pike check-include-path.pike /usr/local/bin/pike
|
||||
*
|
||||
* and its output should be the correct path to the header
|
||||
* files, e.g.
|
||||
*
|
||||
* /usr/local/pike/7.2.239/include/pike
|
||||
*
|
||||
*/
|
||||
|
||||
int main(int argc, array(string) argv)
|
||||
{
|
||||
string prefix = replace(argv[1], "/bin/pike", "");
|
||||
write(prefix + "/pike/" + __MAJOR__ + "." + __MINOR__ + "." + __BUILD__ + "/include/pike");
|
||||
return 0;
|
||||
}
|
||||
994
SWIG/Tools/config.guess
vendored
994
SWIG/Tools/config.guess
vendored
File diff suppressed because it is too large
Load diff
510
SWIG/Tools/config.sub
vendored
510
SWIG/Tools/config.sub
vendored
|
|
@ -1,6 +1,10 @@
|
|||
#! /bin/sh
|
||||
# Configuration validation subroutine script, version 1.1.
|
||||
# Copyright (C) 1991, 92-97, 1998, 1999 Free Software Foundation, Inc.
|
||||
# Configuration validation subroutine script.
|
||||
# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
|
||||
# 2000, 2001, 2002 Free Software Foundation, Inc.
|
||||
|
||||
timestamp='2002-09-05'
|
||||
|
||||
# This file is (in principle) common to ALL GNU software.
|
||||
# The presence of a machine in this file suggests that SOME GNU software
|
||||
# can handle that machine. It does not imply ALL GNU software can.
|
||||
|
|
@ -25,6 +29,9 @@
|
|||
# configuration script generated by Autoconf, you may include it under
|
||||
# the same distribution terms that you use for the rest of that program.
|
||||
|
||||
# Please send patches to <config-patches@gnu.org>. Submit a context
|
||||
# diff and a properly formatted ChangeLog entry.
|
||||
#
|
||||
# Configuration subroutine to validate and canonicalize a configuration type.
|
||||
# Supply the specified configuration type as an argument.
|
||||
# If it is invalid, we print an error message on stderr and exit with code 1.
|
||||
|
|
@ -45,30 +52,73 @@
|
|||
# CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
|
||||
# It is wrong to echo any other type of specification.
|
||||
|
||||
if [ x$1 = x ]
|
||||
then
|
||||
echo Configuration name missing. 1>&2
|
||||
echo "Usage: $0 CPU-MFR-OPSYS" 1>&2
|
||||
echo "or $0 ALIAS" 1>&2
|
||||
echo where ALIAS is a recognized configuration type. 1>&2
|
||||
exit 1
|
||||
fi
|
||||
me=`echo "$0" | sed -e 's,.*/,,'`
|
||||
|
||||
# First pass through any local machine types.
|
||||
case $1 in
|
||||
*local*)
|
||||
echo $1
|
||||
exit 0
|
||||
;;
|
||||
*)
|
||||
;;
|
||||
usage="\
|
||||
Usage: $0 [OPTION] CPU-MFR-OPSYS
|
||||
$0 [OPTION] ALIAS
|
||||
|
||||
Canonicalize a configuration name.
|
||||
|
||||
Operation modes:
|
||||
-h, --help print this help, then exit
|
||||
-t, --time-stamp print date of last modification, then exit
|
||||
-v, --version print version number, then exit
|
||||
|
||||
Report bugs and patches to <config-patches@gnu.org>."
|
||||
|
||||
version="\
|
||||
GNU config.sub ($timestamp)
|
||||
|
||||
Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001
|
||||
Free Software Foundation, Inc.
|
||||
|
||||
This is free software; see the source for copying conditions. There is NO
|
||||
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
|
||||
|
||||
help="
|
||||
Try \`$me --help' for more information."
|
||||
|
||||
# Parse command line
|
||||
while test $# -gt 0 ; do
|
||||
case $1 in
|
||||
--time-stamp | --time* | -t )
|
||||
echo "$timestamp" ; exit 0 ;;
|
||||
--version | -v )
|
||||
echo "$version" ; exit 0 ;;
|
||||
--help | --h* | -h )
|
||||
echo "$usage"; exit 0 ;;
|
||||
-- ) # Stop option processing
|
||||
shift; break ;;
|
||||
- ) # Use stdin as input.
|
||||
break ;;
|
||||
-* )
|
||||
echo "$me: invalid option $1$help"
|
||||
exit 1 ;;
|
||||
|
||||
*local*)
|
||||
# First pass through any local machine types.
|
||||
echo $1
|
||||
exit 0;;
|
||||
|
||||
* )
|
||||
break ;;
|
||||
esac
|
||||
done
|
||||
|
||||
case $# in
|
||||
0) echo "$me: missing argument$help" >&2
|
||||
exit 1;;
|
||||
1) ;;
|
||||
*) echo "$me: too many arguments$help" >&2
|
||||
exit 1;;
|
||||
esac
|
||||
|
||||
# Separate what the user gave into CPU-COMPANY and OS or KERNEL-OS (if any).
|
||||
# Here we must recognize all the valid KERNEL-OS combinations.
|
||||
maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'`
|
||||
case $maybe_os in
|
||||
linux-gnu*)
|
||||
nto-qnx* | linux-gnu* | freebsd*-gnu* | storm-chaos* | os2-emx* | windows32-* | rtmk-nova*)
|
||||
os=-$maybe_os
|
||||
basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
|
||||
;;
|
||||
|
|
@ -94,7 +144,7 @@ case $os in
|
|||
-convergent* | -ncr* | -news | -32* | -3600* | -3100* | -hitachi* |\
|
||||
-c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \
|
||||
-harris | -dolphin | -highlevel | -gould | -cbm | -ns | -masscomp | \
|
||||
-apple)
|
||||
-apple | -axis)
|
||||
os=
|
||||
basic_machine=$1
|
||||
;;
|
||||
|
|
@ -108,6 +158,14 @@ case $os in
|
|||
os=-vxworks
|
||||
basic_machine=$1
|
||||
;;
|
||||
-chorusos*)
|
||||
os=-chorusos
|
||||
basic_machine=$1
|
||||
;;
|
||||
-chorusrdb)
|
||||
os=-chorusrdb
|
||||
basic_machine=$1
|
||||
;;
|
||||
-hiux*)
|
||||
os=-hiuxwe2
|
||||
;;
|
||||
|
|
@ -166,27 +224,60 @@ esac
|
|||
case $basic_machine in
|
||||
# Recognize the basic CPU types without company name.
|
||||
# Some are omitted here because they have special meanings below.
|
||||
tahoe | i860 | ia64 | m32r | m68k | m68000 | m88k | ns32k | arc | arm \
|
||||
| arme[lb] | pyramid | mn10200 | mn10300 | tron | a29k \
|
||||
| 580 | i960 | h8300 \
|
||||
| hppa | hppa1.0 | hppa1.1 | hppa2.0 | hppa2.0w | hppa2.0n \
|
||||
| alpha | alphaev[4-7] | alphaev56 | alphapca5[67] \
|
||||
| we32k | ns16k | clipper | i370 | sh | powerpc | powerpcle \
|
||||
| 1750a | dsp16xx | pdp11 | mips16 | mips64 | mipsel | mips64el \
|
||||
| mips64orion | mips64orionel | mipstx39 | mipstx39el \
|
||||
| mips64vr4300 | mips64vr4300el | mips64vr4100 | mips64vr4100el \
|
||||
| mips64vr5000 | miprs64vr5000el | mcore \
|
||||
| sparc | sparclet | sparclite | sparc64 | sparcv9 | v850 | c4x \
|
||||
| thumb | d10v | fr30)
|
||||
1750a | 580 \
|
||||
| a29k \
|
||||
| alpha | alphaev[4-8] | alphaev56 | alphaev6[78] | alphapca5[67] \
|
||||
| alpha64 | alpha64ev[4-8] | alpha64ev56 | alpha64ev6[78] | alpha64pca5[67] \
|
||||
| arc | arm | arm[bl]e | arme[lb] | armv[2345] | armv[345][lb] | avr \
|
||||
| clipper \
|
||||
| d10v | d30v | dlx | dsp16xx \
|
||||
| fr30 | frv \
|
||||
| h8300 | h8500 | hppa | hppa1.[01] | hppa2.0 | hppa2.0[nw] | hppa64 \
|
||||
| i370 | i860 | i960 | ia64 \
|
||||
| ip2k \
|
||||
| m32r | m68000 | m68k | m88k | mcore \
|
||||
| mips | mipsbe | mipseb | mipsel | mipsle \
|
||||
| mips16 \
|
||||
| mips64 | mips64el \
|
||||
| mips64vr | mips64vrel \
|
||||
| mips64orion | mips64orionel \
|
||||
| mips64vr4100 | mips64vr4100el \
|
||||
| mips64vr4300 | mips64vr4300el \
|
||||
| mips64vr5000 | mips64vr5000el \
|
||||
| mipsisa32 | mipsisa32el \
|
||||
| mipsisa64 | mipsisa64el \
|
||||
| mipsisa64sb1 | mipsisa64sb1el \
|
||||
| mipsisa64sr71k | mipsisa64sr71kel \
|
||||
| mipstx39 | mipstx39el \
|
||||
| mn10200 | mn10300 \
|
||||
| ns16k | ns32k \
|
||||
| openrisc | or32 \
|
||||
| pdp10 | pdp11 | pj | pjl \
|
||||
| powerpc | powerpc64 | powerpc64le | powerpcle | ppcbe \
|
||||
| pyramid \
|
||||
| sh | sh[1234] | sh3e | sh[34]eb | shbe | shle | sh[1234]le | sh3ele \
|
||||
| sh64 | sh64le \
|
||||
| sparc | sparc64 | sparc86x | sparclet | sparclite | sparcv9 | sparcv9b \
|
||||
| strongarm \
|
||||
| tahoe | thumb | tic80 | tron \
|
||||
| v850 | v850e \
|
||||
| we32k \
|
||||
| x86 | xscale | xstormy16 | xtensa \
|
||||
| z8k)
|
||||
basic_machine=$basic_machine-unknown
|
||||
;;
|
||||
m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | z8k | v70 | h8500 | w65 | pj | pjl)
|
||||
m6811 | m68hc11 | m6812 | m68hc12)
|
||||
# Motorola 68HC11/12.
|
||||
basic_machine=$basic_machine-unknown
|
||||
os=-none
|
||||
;;
|
||||
m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | v70 | w65 | z8k)
|
||||
;;
|
||||
|
||||
# We use `pc' rather than `unknown'
|
||||
# because (1) that's what they normally are, and
|
||||
# (2) the word "unknown" tends to confuse beginning users.
|
||||
i[34567]86)
|
||||
i*86 | x86_64)
|
||||
basic_machine=$basic_machine-pc
|
||||
;;
|
||||
# Object if more than one company name word.
|
||||
|
|
@ -195,24 +286,56 @@ case $basic_machine in
|
|||
exit 1
|
||||
;;
|
||||
# Recognize the basic CPU types with company name.
|
||||
# FIXME: clean up the formatting here.
|
||||
vax-* | tahoe-* | i[34567]86-* | i860-* | ia64-* | m32r-* | m68k-* | m68000-* \
|
||||
| m88k-* | sparc-* | ns32k-* | fx80-* | arc-* | arm-* | c[123]* \
|
||||
| mips-* | pyramid-* | tron-* | a29k-* | romp-* | rs6000-* \
|
||||
| power-* | none-* | 580-* | cray2-* | h8300-* | h8500-* | i960-* \
|
||||
| xmp-* | ymp-* \
|
||||
| hppa-* | hppa1.0-* | hppa1.1-* | hppa2.0-* | hppa2.0w-* | hppa2.0n-* \
|
||||
| alpha-* | alphaev[4-7]-* | alphaev56-* | alphapca5[67]-* \
|
||||
| we32k-* | cydra-* | ns16k-* | pn-* | np1-* | xps100-* \
|
||||
| clipper-* | orion-* \
|
||||
| sparclite-* | pdp11-* | sh-* | powerpc-* | powerpcle-* \
|
||||
| sparc64-* | sparcv9-* | sparc86x-* | mips16-* | mips64-* | mipsel-* \
|
||||
| mips64el-* | mips64orion-* | mips64orionel-* \
|
||||
| mips64vr4100-* | mips64vr4100el-* | mips64vr4300-* | mips64vr4300el-* \
|
||||
| mipstx39-* | mipstx39el-* | mcore-* \
|
||||
| f301-* | armv*-* | t3e-* \
|
||||
| m88110-* | m680[01234]0-* | m683?2-* | m68360-* | z8k-* | d10v-* \
|
||||
| thumb-* | v850-* | d30v-* | tic30-* | c30-* | fr30-* )
|
||||
580-* \
|
||||
| a29k-* \
|
||||
| alpha-* | alphaev[4-8]-* | alphaev56-* | alphaev6[78]-* \
|
||||
| alpha64-* | alpha64ev[4-8]-* | alpha64ev56-* | alpha64ev6[78]-* \
|
||||
| alphapca5[67]-* | alpha64pca5[67]-* | arc-* \
|
||||
| arm-* | armbe-* | armle-* | armeb-* | armv*-* \
|
||||
| avr-* \
|
||||
| bs2000-* \
|
||||
| c[123]* | c30-* | [cjt]90-* | c4x-* | c54x-* \
|
||||
| clipper-* | cydra-* \
|
||||
| d10v-* | d30v-* | dlx-* \
|
||||
| elxsi-* \
|
||||
| f30[01]-* | f700-* | fr30-* | frv-* | fx80-* \
|
||||
| h8300-* | h8500-* \
|
||||
| hppa-* | hppa1.[01]-* | hppa2.0-* | hppa2.0[nw]-* | hppa64-* \
|
||||
| i*86-* | i860-* | i960-* | ia64-* \
|
||||
| ip2k-* \
|
||||
| m32r-* \
|
||||
| m68000-* | m680[012346]0-* | m68360-* | m683?2-* | m68k-* \
|
||||
| m88110-* | m88k-* | mcore-* \
|
||||
| mips-* | mipsbe-* | mipseb-* | mipsel-* | mipsle-* \
|
||||
| mips16-* \
|
||||
| mips64-* | mips64el-* \
|
||||
| mips64vr-* | mips64vrel-* \
|
||||
| mips64orion-* | mips64orionel-* \
|
||||
| mips64vr4100-* | mips64vr4100el-* \
|
||||
| mips64vr4300-* | mips64vr4300el-* \
|
||||
| mips64vr5000-* | mips64vr5000el-* \
|
||||
| mipsisa32-* | mipsisa32el-* \
|
||||
| mipsisa64-* | mipsisa64el-* \
|
||||
| mipsisa64sb1-* | mipsisa64sb1el-* \
|
||||
| mipsisa64sr71k-* | mipsisa64sr71kel-* \
|
||||
| mipstx39 | mipstx39el \
|
||||
| none-* | np1-* | ns16k-* | ns32k-* \
|
||||
| orion-* \
|
||||
| pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \
|
||||
| powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* | ppcbe-* \
|
||||
| pyramid-* \
|
||||
| romp-* | rs6000-* \
|
||||
| sh-* | sh[1234]-* | sh3e-* | sh[34]eb-* | shbe-* \
|
||||
| shle-* | sh[1234]le-* | sh3ele-* | sh64-* | sh64le-* \
|
||||
| sparc-* | sparc64-* | sparc86x-* | sparclet-* | sparclite-* \
|
||||
| sparcv9-* | sparcv9b-* | strongarm-* | sv1-* | sx?-* \
|
||||
| tahoe-* | thumb-* | tic30-* | tic4x-* | tic54x-* | tic80-* | tron-* \
|
||||
| v850-* | v850e-* | vax-* \
|
||||
| we32k-* \
|
||||
| x86-* | x86_64-* | xps100-* | xscale-* | xstormy16-* \
|
||||
| xtensa-* \
|
||||
| ymp-* \
|
||||
| z8k-*)
|
||||
;;
|
||||
# Recognize the various machine names and aliases which stand
|
||||
# for a CPU type and a company and sometimes even an OS.
|
||||
|
|
@ -249,14 +372,14 @@ case $basic_machine in
|
|||
os=-sysv
|
||||
;;
|
||||
amiga | amiga-*)
|
||||
basic_machine=m68k-cbm
|
||||
basic_machine=m68k-unknown
|
||||
;;
|
||||
amigaos | amigados)
|
||||
basic_machine=m68k-cbm
|
||||
basic_machine=m68k-unknown
|
||||
os=-amigaos
|
||||
;;
|
||||
amigaunix | amix)
|
||||
basic_machine=m68k-cbm
|
||||
basic_machine=m68k-unknown
|
||||
os=-sysv4
|
||||
;;
|
||||
apollo68)
|
||||
|
|
@ -275,6 +398,10 @@ case $basic_machine in
|
|||
basic_machine=ns32k-sequent
|
||||
os=-dynix
|
||||
;;
|
||||
c90)
|
||||
basic_machine=c90-cray
|
||||
os=-unicos
|
||||
;;
|
||||
convex-c1)
|
||||
basic_machine=c1-convex
|
||||
os=-bsd
|
||||
|
|
@ -295,27 +422,30 @@ case $basic_machine in
|
|||
basic_machine=c38-convex
|
||||
os=-bsd
|
||||
;;
|
||||
cray | ymp)
|
||||
basic_machine=ymp-cray
|
||||
os=-unicos
|
||||
;;
|
||||
cray2)
|
||||
basic_machine=cray2-cray
|
||||
os=-unicos
|
||||
;;
|
||||
[ctj]90-cray)
|
||||
basic_machine=c90-cray
|
||||
cray | j90)
|
||||
basic_machine=j90-cray
|
||||
os=-unicos
|
||||
;;
|
||||
crds | unos)
|
||||
basic_machine=m68k-crds
|
||||
;;
|
||||
cris | cris-* | etrax*)
|
||||
basic_machine=cris-axis
|
||||
;;
|
||||
da30 | da30-*)
|
||||
basic_machine=m68k-da30
|
||||
;;
|
||||
decstation | decstation-3100 | pmax | pmax-* | pmin | dec3100 | decstatn)
|
||||
basic_machine=mips-dec
|
||||
;;
|
||||
decsystem10* | dec10*)
|
||||
basic_machine=pdp10-dec
|
||||
os=-tops10
|
||||
;;
|
||||
decsystem20* | dec20*)
|
||||
basic_machine=pdp10-dec
|
||||
os=-tops20
|
||||
;;
|
||||
delta | 3300 | motorola-3300 | motorola-delta \
|
||||
| 3300-motorola | delta-motorola)
|
||||
basic_machine=m68k-motorola
|
||||
|
|
@ -357,6 +487,10 @@ case $basic_machine in
|
|||
basic_machine=tron-gmicro
|
||||
os=-sysv
|
||||
;;
|
||||
go32)
|
||||
basic_machine=i386-pc
|
||||
os=-go32
|
||||
;;
|
||||
h3050r* | hiux*)
|
||||
basic_machine=hppa1.1-hitachi
|
||||
os=-hiuxwe2
|
||||
|
|
@ -432,19 +566,19 @@ case $basic_machine in
|
|||
basic_machine=i370-ibm
|
||||
;;
|
||||
# I'm not sure what "Sysv32" means. Should this be sysv3.2?
|
||||
i[34567]86v32)
|
||||
i*86v32)
|
||||
basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
|
||||
os=-sysv32
|
||||
;;
|
||||
i[34567]86v4*)
|
||||
i*86v4*)
|
||||
basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
|
||||
os=-sysv4
|
||||
;;
|
||||
i[34567]86v)
|
||||
i*86v)
|
||||
basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
|
||||
os=-sysv
|
||||
;;
|
||||
i[34567]86sol2)
|
||||
i*86sol2)
|
||||
basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
|
||||
os=-solaris2
|
||||
;;
|
||||
|
|
@ -456,17 +590,6 @@ case $basic_machine in
|
|||
basic_machine=i386-unknown
|
||||
os=-vsta
|
||||
;;
|
||||
i386-go32 | go32)
|
||||
basic_machine=i386-unknown
|
||||
os=-go32
|
||||
;;
|
||||
i386-mingw32 | mingw32)
|
||||
basic_machine=i386-unknown
|
||||
os=-mingw32
|
||||
;;
|
||||
i386-qnx | qnx)
|
||||
basic_machine=i386-qnx
|
||||
;;
|
||||
iris | iris4d)
|
||||
basic_machine=mips-sgi
|
||||
case $os in
|
||||
|
|
@ -492,6 +615,10 @@ case $basic_machine in
|
|||
basic_machine=ns32k-utek
|
||||
os=-sysv
|
||||
;;
|
||||
mingw32)
|
||||
basic_machine=i386-pc
|
||||
os=-mingw32
|
||||
;;
|
||||
miniframe)
|
||||
basic_machine=m68000-convergent
|
||||
;;
|
||||
|
|
@ -499,26 +626,26 @@ case $basic_machine in
|
|||
basic_machine=m68k-atari
|
||||
os=-mint
|
||||
;;
|
||||
mipsel*-linux*)
|
||||
basic_machine=mipsel-unknown
|
||||
os=-linux-gnu
|
||||
;;
|
||||
mips*-linux*)
|
||||
basic_machine=mips-unknown
|
||||
os=-linux-gnu
|
||||
;;
|
||||
mips3*-*)
|
||||
basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`
|
||||
;;
|
||||
mips3*)
|
||||
basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`-unknown
|
||||
;;
|
||||
mmix*)
|
||||
basic_machine=mmix-knuth
|
||||
os=-mmixware
|
||||
;;
|
||||
monitor)
|
||||
basic_machine=m68k-rom68k
|
||||
os=-coff
|
||||
;;
|
||||
morphos)
|
||||
basic_machine=powerpc-unknown
|
||||
os=-morphos
|
||||
;;
|
||||
msdos)
|
||||
basic_machine=i386-unknown
|
||||
basic_machine=i386-pc
|
||||
os=-msdos
|
||||
;;
|
||||
mvs)
|
||||
|
|
@ -582,13 +709,24 @@ case $basic_machine in
|
|||
basic_machine=i960-intel
|
||||
os=-mon960
|
||||
;;
|
||||
nonstopux)
|
||||
basic_machine=mips-compaq
|
||||
os=-nonstopux
|
||||
;;
|
||||
np1)
|
||||
basic_machine=np1-gould
|
||||
;;
|
||||
nsr-tandem)
|
||||
basic_machine=nsr-tandem
|
||||
;;
|
||||
op50n-* | op60c-*)
|
||||
basic_machine=hppa1.1-oki
|
||||
os=-proelf
|
||||
;;
|
||||
or32 | or32-*)
|
||||
basic_machine=or32-unknown
|
||||
os=-coff
|
||||
;;
|
||||
OSE68000 | ose68000)
|
||||
basic_machine=m68000-ericsson
|
||||
os=-ose
|
||||
|
|
@ -611,45 +749,59 @@ case $basic_machine in
|
|||
pbb)
|
||||
basic_machine=m68k-tti
|
||||
;;
|
||||
pc532 | pc532-*)
|
||||
pc532 | pc532-*)
|
||||
basic_machine=ns32k-pc532
|
||||
;;
|
||||
pentium | p5 | k5 | k6 | nexen)
|
||||
pentium | p5 | k5 | k6 | nexgen | viac3)
|
||||
basic_machine=i586-pc
|
||||
;;
|
||||
pentiumpro | p6 | 6x86)
|
||||
pentiumpro | p6 | 6x86 | athlon | athlon_*)
|
||||
basic_machine=i686-pc
|
||||
;;
|
||||
pentiumii | pentium2)
|
||||
basic_machine=i786-pc
|
||||
basic_machine=i686-pc
|
||||
;;
|
||||
pentium-* | p5-* | k5-* | k6-* | nexen-*)
|
||||
pentium-* | p5-* | k5-* | k6-* | nexgen-* | viac3-*)
|
||||
basic_machine=i586-`echo $basic_machine | sed 's/^[^-]*-//'`
|
||||
;;
|
||||
pentiumpro-* | p6-* | 6x86-*)
|
||||
pentiumpro-* | p6-* | 6x86-* | athlon-*)
|
||||
basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'`
|
||||
;;
|
||||
pentiumii-* | pentium2-*)
|
||||
basic_machine=i786-`echo $basic_machine | sed 's/^[^-]*-//'`
|
||||
basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'`
|
||||
;;
|
||||
pn)
|
||||
basic_machine=pn-gould
|
||||
;;
|
||||
power) basic_machine=rs6000-ibm
|
||||
power) basic_machine=power-ibm
|
||||
;;
|
||||
ppc) basic_machine=powerpc-unknown
|
||||
;;
|
||||
;;
|
||||
ppc-*) basic_machine=powerpc-`echo $basic_machine | sed 's/^[^-]*-//'`
|
||||
;;
|
||||
ppcle | powerpclittle | ppc-le | powerpc-little)
|
||||
basic_machine=powerpcle-unknown
|
||||
;;
|
||||
;;
|
||||
ppcle-* | powerpclittle-*)
|
||||
basic_machine=powerpcle-`echo $basic_machine | sed 's/^[^-]*-//'`
|
||||
;;
|
||||
ppc64) basic_machine=powerpc64-unknown
|
||||
;;
|
||||
ppc64-*) basic_machine=powerpc64-`echo $basic_machine | sed 's/^[^-]*-//'`
|
||||
;;
|
||||
ppc64le | powerpc64little | ppc64-le | powerpc64-little)
|
||||
basic_machine=powerpc64le-unknown
|
||||
;;
|
||||
ppc64le-* | powerpc64little-*)
|
||||
basic_machine=powerpc64le-`echo $basic_machine | sed 's/^[^-]*-//'`
|
||||
;;
|
||||
ps2)
|
||||
basic_machine=i386-ibm
|
||||
;;
|
||||
pw32)
|
||||
basic_machine=i586-unknown
|
||||
os=-pw32
|
||||
;;
|
||||
rom68k)
|
||||
basic_machine=m68k-rom68k
|
||||
os=-coff
|
||||
|
|
@ -660,10 +812,22 @@ case $basic_machine in
|
|||
rtpc | rtpc-*)
|
||||
basic_machine=romp-ibm
|
||||
;;
|
||||
s390 | s390-*)
|
||||
basic_machine=s390-ibm
|
||||
;;
|
||||
s390x | s390x-*)
|
||||
basic_machine=s390x-ibm
|
||||
;;
|
||||
sa29200)
|
||||
basic_machine=a29k-amd
|
||||
os=-udi
|
||||
;;
|
||||
sb1)
|
||||
basic_machine=mipsisa64sb1-unknown
|
||||
;;
|
||||
sb1el)
|
||||
basic_machine=mipsisa64sb1el-unknown
|
||||
;;
|
||||
sequent)
|
||||
basic_machine=i386-sequent
|
||||
;;
|
||||
|
|
@ -671,7 +835,7 @@ case $basic_machine in
|
|||
basic_machine=sh-hitachi
|
||||
os=-hms
|
||||
;;
|
||||
sparclite-wrs)
|
||||
sparclite-wrs | simso-wrs)
|
||||
basic_machine=sparclite-wrs
|
||||
os=-vxworks
|
||||
;;
|
||||
|
|
@ -729,20 +893,44 @@ case $basic_machine in
|
|||
sun386 | sun386i | roadrunner)
|
||||
basic_machine=i386-sun
|
||||
;;
|
||||
sv1)
|
||||
basic_machine=sv1-cray
|
||||
os=-unicos
|
||||
;;
|
||||
symmetry)
|
||||
basic_machine=i386-sequent
|
||||
os=-dynix
|
||||
;;
|
||||
t3e)
|
||||
basic_machine=t3e-cray
|
||||
t3d)
|
||||
basic_machine=alpha-cray
|
||||
os=-unicos
|
||||
;;
|
||||
t3e)
|
||||
basic_machine=alphaev5-cray
|
||||
os=-unicos
|
||||
;;
|
||||
t90)
|
||||
basic_machine=t90-cray
|
||||
os=-unicos
|
||||
;;
|
||||
tic4x | c4x*)
|
||||
basic_machine=tic4x-unknown
|
||||
os=-coff
|
||||
;;
|
||||
tic54x | c54x*)
|
||||
basic_machine=tic54x-unknown
|
||||
os=-coff
|
||||
;;
|
||||
tx39)
|
||||
basic_machine=mipstx39-unknown
|
||||
;;
|
||||
tx39el)
|
||||
basic_machine=mipstx39el-unknown
|
||||
;;
|
||||
toad1)
|
||||
basic_machine=pdp10-xkl
|
||||
os=-tops20
|
||||
;;
|
||||
tower | tower-32)
|
||||
basic_machine=m68k-ncr
|
||||
;;
|
||||
|
|
@ -767,8 +955,8 @@ case $basic_machine in
|
|||
os=-vms
|
||||
;;
|
||||
vpp*|vx|vx-*)
|
||||
basic_machine=f301-fujitsu
|
||||
;;
|
||||
basic_machine=f301-fujitsu
|
||||
;;
|
||||
vxworks960)
|
||||
basic_machine=i960-wrs
|
||||
os=-vxworks
|
||||
|
|
@ -789,13 +977,17 @@ case $basic_machine in
|
|||
basic_machine=hppa1.1-winbond
|
||||
os=-proelf
|
||||
;;
|
||||
xmp)
|
||||
basic_machine=xmp-cray
|
||||
os=-unicos
|
||||
windows32)
|
||||
basic_machine=i386-pc
|
||||
os=-windows32-msvcrt
|
||||
;;
|
||||
xps | xps100)
|
||||
xps | xps100)
|
||||
basic_machine=xps100-honeywell
|
||||
;;
|
||||
ymp)
|
||||
basic_machine=ymp-cray
|
||||
os=-unicos
|
||||
;;
|
||||
z8k-*-coff)
|
||||
basic_machine=z8k-unknown
|
||||
os=-sim
|
||||
|
|
@ -816,13 +1008,6 @@ case $basic_machine in
|
|||
op60c)
|
||||
basic_machine=hppa1.1-oki
|
||||
;;
|
||||
mips)
|
||||
if [ x$os = x-linux-gnu ]; then
|
||||
basic_machine=mips-unknown
|
||||
else
|
||||
basic_machine=mips-mips
|
||||
fi
|
||||
;;
|
||||
romp)
|
||||
basic_machine=romp-ibm
|
||||
;;
|
||||
|
|
@ -832,16 +1017,26 @@ case $basic_machine in
|
|||
vax)
|
||||
basic_machine=vax-dec
|
||||
;;
|
||||
pdp10)
|
||||
# there are many clones, so DEC is not a safe bet
|
||||
basic_machine=pdp10-unknown
|
||||
;;
|
||||
pdp11)
|
||||
basic_machine=pdp11-dec
|
||||
;;
|
||||
we32k)
|
||||
basic_machine=we32k-att
|
||||
;;
|
||||
sparc | sparcv9)
|
||||
sh3 | sh4 | sh3eb | sh4eb | sh[1234]le | sh3ele)
|
||||
basic_machine=sh-unknown
|
||||
;;
|
||||
sh64)
|
||||
basic_machine=sh64-unknown
|
||||
;;
|
||||
sparc | sparcv9 | sparcv9b)
|
||||
basic_machine=sparc-sun
|
||||
;;
|
||||
cydra)
|
||||
cydra)
|
||||
basic_machine=cydra-cydrome
|
||||
;;
|
||||
orion)
|
||||
|
|
@ -856,9 +1051,8 @@ case $basic_machine in
|
|||
pmac | pmac-mpw)
|
||||
basic_machine=powerpc-apple
|
||||
;;
|
||||
c4x*)
|
||||
basic_machine=c4x-none
|
||||
os=-coff
|
||||
*-unknown)
|
||||
# Make sure to match an already-canonicalized machine name.
|
||||
;;
|
||||
*)
|
||||
echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2
|
||||
|
|
@ -916,14 +1110,31 @@ case $os in
|
|||
| -lynxos* | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \
|
||||
| -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \
|
||||
| -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \
|
||||
| -chorusos* | -chorusrdb* \
|
||||
| -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \
|
||||
| -mingw32* | -linux-gnu* | -uxpv* | -beos* | -mpeix* | -udk* \
|
||||
| -interix* | -uwin* | -rhapsody* | -opened* | -openstep* | -oskit*)
|
||||
| -interix* | -uwin* | -rhapsody* | -darwin* | -opened* \
|
||||
| -openstep* | -oskit* | -conix* | -pw32* | -nonstopux* \
|
||||
| -storm-chaos* | -tops10* | -tenex* | -tops20* | -its* \
|
||||
| -os2* | -vos* | -palmos* | -uclinux* | -nucleus* \
|
||||
| -morphos* | -superux* | -rtmk* | -rtmk-nova* | -windiss* | -powermax*)
|
||||
# Remember, each alternative MUST END IN *, to match a version number.
|
||||
;;
|
||||
-qnx*)
|
||||
case $basic_machine in
|
||||
x86-* | i*86-*)
|
||||
;;
|
||||
*)
|
||||
os=-nto$os
|
||||
;;
|
||||
esac
|
||||
;;
|
||||
-nto*)
|
||||
os=-nto-qnx
|
||||
;;
|
||||
-sim | -es1800* | -hms* | -xray | -os68k* | -none* | -v88r* \
|
||||
| -windows* | -osx | -abug | -netware* | -os9* | -beos* \
|
||||
| -macos* | -mpw* | -magic* | -mon960* | -lnews*)
|
||||
| -macos* | -mpw* | -magic* | -mmixware* | -mon960* | -lnews*)
|
||||
;;
|
||||
-mac*)
|
||||
os=`echo $os | sed -e 's|mac|macos|'`
|
||||
|
|
@ -940,6 +1151,9 @@ case $os in
|
|||
-opened*)
|
||||
os=-openedition
|
||||
;;
|
||||
-wince*)
|
||||
os=-wince
|
||||
;;
|
||||
-osfrose*)
|
||||
os=-osfrose
|
||||
;;
|
||||
|
|
@ -955,14 +1169,23 @@ case $os in
|
|||
-acis*)
|
||||
os=-aos
|
||||
;;
|
||||
-atheos*)
|
||||
os=-atheos
|
||||
;;
|
||||
-386bsd)
|
||||
os=-bsd
|
||||
;;
|
||||
-ctix* | -uts*)
|
||||
os=-sysv
|
||||
;;
|
||||
-nova*)
|
||||
os=-rtmk-nova
|
||||
;;
|
||||
-ns2 )
|
||||
os=-nextstep2
|
||||
os=-nextstep2
|
||||
;;
|
||||
-nsk*)
|
||||
os=-nsk
|
||||
;;
|
||||
# Preserve the version number of sinix5.
|
||||
-sinix5.*)
|
||||
|
|
@ -977,9 +1200,6 @@ case $os in
|
|||
-oss*)
|
||||
os=-sysv3
|
||||
;;
|
||||
-qnx)
|
||||
os=-qnx4
|
||||
;;
|
||||
-svr4)
|
||||
os=-sysv4
|
||||
;;
|
||||
|
|
@ -1001,8 +1221,8 @@ case $os in
|
|||
-xenix)
|
||||
os=-xenix
|
||||
;;
|
||||
-*mint | -*MiNT)
|
||||
os=-mint
|
||||
-*mint | -mint[0-9]* | -*MiNT | -MiNT[0-9]*)
|
||||
os=-mint
|
||||
;;
|
||||
-none)
|
||||
;;
|
||||
|
|
@ -1035,7 +1255,11 @@ case $basic_machine in
|
|||
arm*-semi)
|
||||
os=-aout
|
||||
;;
|
||||
pdp11-*)
|
||||
# This must come before the *-dec entry.
|
||||
pdp10-*)
|
||||
os=-tops20
|
||||
;;
|
||||
pdp11-*)
|
||||
os=-none
|
||||
;;
|
||||
*-dec | vax-*)
|
||||
|
|
@ -1062,6 +1286,9 @@ case $basic_machine in
|
|||
mips*-*)
|
||||
os=-elf
|
||||
;;
|
||||
or32-*)
|
||||
os=-coff
|
||||
;;
|
||||
*-tti) # must be before sparc entry or we get the wrong os.
|
||||
os=-sysv3
|
||||
;;
|
||||
|
|
@ -1125,25 +1352,25 @@ case $basic_machine in
|
|||
*-next)
|
||||
os=-nextstep3
|
||||
;;
|
||||
*-gould)
|
||||
*-gould)
|
||||
os=-sysv
|
||||
;;
|
||||
*-highlevel)
|
||||
*-highlevel)
|
||||
os=-bsd
|
||||
;;
|
||||
*-encore)
|
||||
os=-bsd
|
||||
;;
|
||||
*-sgi)
|
||||
*-sgi)
|
||||
os=-irix
|
||||
;;
|
||||
*-siemens)
|
||||
*-siemens)
|
||||
os=-sysv4
|
||||
;;
|
||||
*-masscomp)
|
||||
os=-rtu
|
||||
;;
|
||||
f301-fujitsu)
|
||||
f30[01]-fujitsu | f700-fujitsu)
|
||||
os=-uxpv
|
||||
;;
|
||||
*-rom68k)
|
||||
|
|
@ -1209,7 +1436,7 @@ case $basic_machine in
|
|||
-ptx*)
|
||||
vendor=sequent
|
||||
;;
|
||||
-vxsim* | -vxworks*)
|
||||
-vxsim* | -vxworks* | -windiss*)
|
||||
vendor=wrs
|
||||
;;
|
||||
-aux*)
|
||||
|
|
@ -1221,12 +1448,23 @@ case $basic_machine in
|
|||
-mpw* | -macos*)
|
||||
vendor=apple
|
||||
;;
|
||||
-*mint | -*MiNT)
|
||||
-*mint | -mint[0-9]* | -*MiNT | -MiNT[0-9]*)
|
||||
vendor=atari
|
||||
;;
|
||||
-vos*)
|
||||
vendor=stratus
|
||||
;;
|
||||
esac
|
||||
basic_machine=`echo $basic_machine | sed "s/unknown/$vendor/"`
|
||||
;;
|
||||
esac
|
||||
|
||||
echo $basic_machine$os
|
||||
exit 0
|
||||
|
||||
# Local variables:
|
||||
# eval: (add-hook 'write-file-hooks 'time-stamp)
|
||||
# time-stamp-start: "timestamp='"
|
||||
# time-stamp-format: "%:y-%02m-%02d"
|
||||
# time-stamp-end: "'"
|
||||
# End:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,49 @@
|
|||
AC_INIT(ltmain.sh)
|
||||
AC_PREREQ(2.53)
|
||||
|
||||
AC_OUTPUT_COMMANDS([$srcdir/ltconfig --enable-dlopen $srcdir/ltmain.sh],
|
||||
[srcdir=$srcdir])
|
||||
##-----------------------------------------------------------------------------
|
||||
## libtool configuration
|
||||
## (bug reports to ttn)
|
||||
|
||||
## The command "libtoolize --copy --force" is used to create files:
|
||||
## config.guess
|
||||
## config.sub
|
||||
## ltmain.sh
|
||||
## The following lines make libtoolize place them in this directory
|
||||
## rather than in the parent (where it finds install-sh). But this
|
||||
## means at configure time, install-sh actually does need to be in
|
||||
## this directory, so we copy it from the parent, *before* the decl.
|
||||
## (The alternative is to check into cvs and consequently distribute
|
||||
## another copy of install-sh, but that way lies madness.)
|
||||
|
||||
cp ${srcdir}/../install-sh ${srcdir}
|
||||
chmod +x ${srcdir}/install-sh
|
||||
AC_CONFIG_AUX_DIR(.)
|
||||
|
||||
## Apparently libtool configuration (now) assumes libtool is installed
|
||||
## in the top builddir, congruent w/ automake expectations. Because we
|
||||
## don't use automake, we need to set this variable manaully. Because
|
||||
## we don't install libtool in the top builddir, we must use an absolute
|
||||
## path instead of the relative path ".". See footnote in info node
|
||||
## "(libtool)AC_PROG_LIBTOOL".
|
||||
##
|
||||
## Actually, at this time we hardcode makefile var LIBTOOL to DTRT, so
|
||||
## it's ok to subvert the top_builddir requirement (and desirable, to
|
||||
## flush out bugs faster). The following lines can be commented in should
|
||||
## we change our minds in the future.
|
||||
|
||||
##+ top_builddir="`pwd`" # libtool is here, not in parent dir
|
||||
##+ AC_SUBST(top_builddir)
|
||||
|
||||
## These two configure libtool, including dlopen facilities, by adding
|
||||
## --{enable,disable}-{shared,static} options and setting var LIBTOOL,
|
||||
## which uses top_builddir (see above). Note that at this time, this
|
||||
## var is completely ignored; we set LIBTOOL directly in the Makefiles.
|
||||
|
||||
AC_LIBTOOL_DLOPEN
|
||||
AC_PROG_LIBTOOL
|
||||
|
||||
## libtool configuration ends here
|
||||
##-----------------------------------------------------------------------------
|
||||
|
||||
AC_OUTPUT()
|
||||
|
|
|
|||
3078
SWIG/Tools/ltconfig
3078
SWIG/Tools/ltconfig
File diff suppressed because it is too large
Load diff
2738
SWIG/Tools/ltmain.sh
2738
SWIG/Tools/ltmain.sh
File diff suppressed because it is too large
Load diff
|
|
@ -19,11 +19,11 @@ os.system("rm -rf "+dirname)
|
|||
# Do a CVS export on the directory name
|
||||
|
||||
print "Checking out SWIG"
|
||||
os.system("cvs export -D now -d "+dirname+ " SWIG")
|
||||
os.system("cvs export -D now -r rel-1-3 -d "+dirname+ " SWIG")
|
||||
|
||||
# Now clean the source directory
|
||||
|
||||
SOURCES = ['DOH','Swig','Preprocessor','SWIG1.1','Modules1.1', 'Modules', 'Include']
|
||||
SOURCES = ['DOH','Swig','Preprocessor','CParse','Modules1.1', 'Modules', 'Include']
|
||||
|
||||
srcs = [ ]
|
||||
for d in SOURCES:
|
||||
|
|
@ -58,10 +58,9 @@ f = open(dirname+"/configure.in","w")
|
|||
f.write(s)
|
||||
f.close()
|
||||
|
||||
# Clean the documentation directory
|
||||
# Remove the debian directory -- it's not official
|
||||
|
||||
print "Cleaning the Doc directory"
|
||||
os.system("rm -rf "+dirname+"/Doc/*")
|
||||
os.system("rm -Rf "+dirname+"/debian");
|
||||
|
||||
# Blow away all .cvsignore files
|
||||
|
||||
|
|
@ -73,8 +72,17 @@ os.system("find "+dirname+" -name .cvsignore -exec rm {} \\;");
|
|||
os.system("cd "+dirname+"; autoconf")
|
||||
os.system("cd "+dirname+"/Source/DOH; autoconf")
|
||||
os.system("cd "+dirname+"/Tools; autoconf")
|
||||
os.system("cd "+dirname+"/Source/SWIG1.1; bison -y -d parser.yxx; mv y.tab.c parser.cxx; mv y.tab.h parser.h")
|
||||
os.system("cd "+dirname+"/Examples/GIFPlot; autoconf")
|
||||
os.system("cd "+dirname+"/Tools/WAD; autoconf")
|
||||
os.system("cd "+dirname+"/Source/CParse; bison -y -d parser.y; mv y.tab.c parser.c; mv y.tab.h parser.h")
|
||||
|
||||
# Remove autoconf files
|
||||
os.system("find "+dirname+" -name autom4te.cache -exec rm -rf {} \\;");
|
||||
|
||||
# Build documentation
|
||||
os.system("cd "+dirname+"/Doc/Manual; python maketoc.py; rm *.bak")
|
||||
|
||||
# Build the tar-ball
|
||||
os.system("tar -cf "+string.lower(dirname)+".tar "+dirname)
|
||||
os.system("gzip "+string.lower(dirname)+".tar")
|
||||
|
||||
|
|
|
|||
139
SWIG/Tools/setup.py.tmpl
Normal file
139
SWIG/Tools/setup.py.tmpl
Normal file
|
|
@ -0,0 +1,139 @@
|
|||
#!@PYTHON@
|
||||
'''A setup.py script with better SWIG support. To use it, either
|
||||
rename it to setup.py.in and have it pe processed by your configure
|
||||
script (you will need to define @PYTHON@), or replace the @*@ strings
|
||||
by hand.
|
||||
|
||||
Copyright 2001, Anthony Joseph Seward'''
|
||||
|
||||
|
||||
from distutils.core import setup, Extension
|
||||
|
||||
###############################################################################
|
||||
## Start of better Swig support
|
||||
###############################################################################
|
||||
from distutils.command.build_ext import build_ext
|
||||
import os
|
||||
import string
|
||||
class build_swig_ext(build_ext):
|
||||
'''Better swig support for Distutils'''
|
||||
|
||||
## __ Tell Distutils about the options
|
||||
user_options = build_ext.user_options
|
||||
boolean_options = build_ext.boolean_options
|
||||
|
||||
user_options.append(
|
||||
('swig-doc=', None,
|
||||
'what type of documentation should SWIG produce (default: none)')
|
||||
)
|
||||
user_options.append(
|
||||
('swig-inc=', None,
|
||||
'a list of directories to add to the SWIG include path'
|
||||
+ "(separated by ':')(default: SWIG)")
|
||||
)
|
||||
user_options.append(
|
||||
('swig-shadow', None,
|
||||
'have SWIG create shadow classes'
|
||||
+ ' (also adds docstrings to the shadow classes')
|
||||
)
|
||||
|
||||
boolean_options.append('swig-shadow')
|
||||
|
||||
def initialize_options(self):
|
||||
'''Initialize the new options after the inherited ones'''
|
||||
build_ext.initialize_options(self)
|
||||
self.swig_doc = 'none'
|
||||
self.swig_inc = 'SWIG'
|
||||
self.swig_shadow = None
|
||||
|
||||
def swig_sources(self, sources):
|
||||
"""Override the definition of 'swig_sources' in build_ext. This
|
||||
is essentially the same function but with better swig support.
|
||||
I will now quote the original docstring:
|
||||
|
||||
Walk the list of source files in 'sources', looking for SWIG
|
||||
interface (.i) files. Run SWIG on all that are found, and
|
||||
return a modified 'sources' list with SWIG source files replaced
|
||||
by the generated C (or C++) files.
|
||||
"""
|
||||
|
||||
new_sources = []
|
||||
swig_sources = []
|
||||
swig_targets = {}
|
||||
|
||||
# XXX this drops generated C/C++ files into the source tree, which
|
||||
# is fine for developers who want to distribute the generated
|
||||
# source -- but there should be an option to put SWIG output in
|
||||
# the temp dir.
|
||||
|
||||
if self.swig_cpp:
|
||||
target_ext = '.cpp'
|
||||
else:
|
||||
target_ext = '.c'
|
||||
|
||||
for source in sources:
|
||||
(base, ext) = os.path.splitext(source)
|
||||
if ext == ".i": # SWIG interface file
|
||||
new_sources.append(base + target_ext)
|
||||
swig_sources.append(source)
|
||||
swig_targets[source] = new_sources[-1]
|
||||
else:
|
||||
new_sources.append(source)
|
||||
|
||||
if not swig_sources:
|
||||
return new_sources
|
||||
|
||||
includes = self.swig_inc
|
||||
if type(includes) is type(''):
|
||||
includes = string.split(includes, ':')
|
||||
includes = map(lambda x: '-I'+x, includes)
|
||||
includes = string.join(includes)
|
||||
|
||||
swig = self.find_swig()
|
||||
## swig_cmd = [swig, "-python", "-d%s" % self.swig_doc, includes]
|
||||
swig_cmd = [swig, '-v', '-python', '-d%s' % self.swig_doc, includes]
|
||||
if self.swig_cpp:
|
||||
swig_cmd.append('-c++')
|
||||
|
||||
if self.swig_shadow:
|
||||
swig_cmd.append('-shadow')
|
||||
## swig1.1 swig_cmd.append('-docstring')
|
||||
|
||||
for source in swig_sources:
|
||||
target = swig_targets[source]
|
||||
self.announce('swigging %s to %s' % (source, target))
|
||||
self.spawn(swig_cmd + ['-o', target, source])
|
||||
|
||||
return new_sources
|
||||
|
||||
# swig_sources ()
|
||||
###############################################################################
|
||||
## End of improved swig support
|
||||
###############################################################################
|
||||
|
||||
package = '@PACKAGE@'
|
||||
version = '@VERSION@'
|
||||
include_dirs = ['@top_srcdir@']
|
||||
lib_dirs = ['@top_srcdir@/@PACKAGE@']
|
||||
libraries = ['@PACKAGE@', 'stdc++']
|
||||
|
||||
setup(name = package,
|
||||
version = version,
|
||||
description = '',
|
||||
author = '',
|
||||
author_email = '',
|
||||
url = 'http://',
|
||||
|
||||
cmdclass = {'build_ext': build_swig_ext},
|
||||
ext_modules = [Extension(package+'cmodule',
|
||||
[package+'.i'],
|
||||
include_dirs=include_dirs,
|
||||
library_dirs=lib_dirs,
|
||||
libraries=libraries,
|
||||
)],
|
||||
options = {'build_ext':
|
||||
{'swig_doc': 'html',
|
||||
'swig_cpp': not None,
|
||||
'swig_shadow': not None}
|
||||
}
|
||||
)
|
||||
|
|
@ -1,83 +0,0 @@
|
|||
# Preamble
|
||||
Summary: Simplified Wrapper and Interface Generator
|
||||
Name: swig
|
||||
Version: 1.3a3
|
||||
Release: 1
|
||||
Copyright: BSD
|
||||
URL: http://www.swig.org
|
||||
Group: System Environment/Daemons
|
||||
Source0: http://download.sourceforge.net/swig/swig1.3a3.tar.gz
|
||||
Packager: Dustin Mitchell <dustin@cs.uchicago.edu>
|
||||
%description
|
||||
SWIG is an interface compiler that connects programs written in C,
|
||||
C++, and Objective-C with scripting languages including Perl, Python,
|
||||
and Tcl/Tk. It works by taking the declarations commonly found in
|
||||
C/C++ header files and using them to generate the glue code (wrappers)
|
||||
that scripting languages need to access the underlying C/C++ code
|
||||
|
||||
# PREP
|
||||
%prep
|
||||
rm -rf $RPM_BUILD_DIR/swig1.3a3
|
||||
zcat $RPM_SOURCE_DIR/swig1.3a3.tar.gz | tar -xvvf -
|
||||
mv $RPM_BUILD_DIR/SWIG1.3a3 $RPM_BUILD_DIR/swig1.3a3
|
||||
|
||||
# BUILD
|
||||
%build
|
||||
cd $RPM_BUILD_DIR/swig1.3a3
|
||||
./configure --prefix=/usr
|
||||
make
|
||||
|
||||
# INSTALL
|
||||
%install
|
||||
cd $RPM_BUILD_DIR/swig1.3a3
|
||||
make install
|
||||
|
||||
# FILES
|
||||
%files
|
||||
/usr/lib/swig1.3/tcl/constarray.i
|
||||
/usr/lib/swig1.3/tcl/consthash.i
|
||||
/usr/lib/swig1.3/tcl/ptrlang.i
|
||||
/usr/lib/swig1.3/tcl/tclsh.i
|
||||
/usr/lib/swig1.3/tcl/typemaps.i
|
||||
/usr/lib/swig1.3/tcl/wish.i
|
||||
/usr/lib/swig1.3/tcl/object.swg
|
||||
/usr/lib/swig1.3/tcl/swigtcl8.swg
|
||||
/usr/lib/swig1.3/array.i
|
||||
/usr/lib/swig1.3/autodoc.i
|
||||
/usr/lib/swig1.3/carray.i
|
||||
/usr/lib/swig1.3/constraints.i
|
||||
/usr/lib/swig1.3/ctype.i
|
||||
/usr/lib/swig1.3/exception.i
|
||||
/usr/lib/swig1.3/malloc.i
|
||||
/usr/lib/swig1.3/math.i
|
||||
/usr/lib/swig1.3/memory.i
|
||||
/usr/lib/swig1.3/objc.i
|
||||
/usr/lib/swig1.3/pointer.i
|
||||
/usr/lib/swig1.3/stdlib.i
|
||||
/usr/lib/swig1.3/timers.i
|
||||
/usr/lib/swig1.3/perl5/perlmain.i
|
||||
/usr/lib/swig1.3/perl5/ptrlang.i
|
||||
/usr/lib/swig1.3/perl5/typemaps.i
|
||||
/usr/lib/swig1.3/perl5/headers.swg
|
||||
/usr/lib/swig1.3/perl5/perl5.swg
|
||||
/usr/lib/swig1.3/perl5/perl5mg.swg
|
||||
/usr/lib/swig1.3/perl5/Makefile.pl
|
||||
/usr/lib/swig1.3/python/embed.i
|
||||
/usr/lib/swig1.3/python/embed13.i
|
||||
/usr/lib/swig1.3/python/embed14.i
|
||||
/usr/lib/swig1.3/python/embed15.i
|
||||
/usr/lib/swig1.3/python/ptrlang.i
|
||||
/usr/lib/swig1.3/python/typemaps.i
|
||||
/usr/lib/swig1.3/python/typemaps_old.i
|
||||
/usr/lib/swig1.3/python/defarg.swg
|
||||
/usr/lib/swig1.3/python/python.swg
|
||||
/usr/lib/swig1.3/guile/guilemain.i
|
||||
/usr/lib/swig1.3/guile/interpreter.i
|
||||
/usr/lib/swig1.3/guile/typemaps.i
|
||||
/usr/lib/swig1.3/guile/guile.swg
|
||||
/usr/lib/swig1.3/guile/guiledec.swg
|
||||
/usr/lib/swig1.3/java/typemaps.i
|
||||
/usr/lib/swig1.3/java/java.swg
|
||||
/usr/lib/swig1.3/mzscheme/typemaps.i
|
||||
/usr/lib/swig1.3/mzscheme/mzscheme.swg
|
||||
/usr/bin/swig
|
||||
|
|
@ -1,88 +0,0 @@
|
|||
%define ver 1.3a4
|
||||
%define prefix /usr
|
||||
|
||||
# Preamble
|
||||
Summary: Simplified Wrapper and Interface Generator
|
||||
Name: swig
|
||||
Version: %ver
|
||||
Prefix: %prefix
|
||||
BuildRoot: /usr/src/redhat/BUILD
|
||||
Release: 1
|
||||
Copyright: BSD
|
||||
URL: http://www.swig.org
|
||||
Group: System Environment/Daemons
|
||||
Source0: http://download.sourceforge.net/swig/swig1.3a4.tar.gz
|
||||
Packager: Dustin Mitchell <dustin@cs.uchicago.edu>
|
||||
%description
|
||||
SWIG is an interface compiler that connects programs written in C,
|
||||
C++, and Objective-C with scripting languages including Perl, Python,
|
||||
and Tcl/Tk. It works by taking the declarations commonly found in
|
||||
C/C++ header files and using them to generate the glue code (wrappers)
|
||||
that scripting languages need to access the underlying C/C++ code
|
||||
|
||||
# PREP
|
||||
%prep
|
||||
rm -rf $RPM_BUILD_DIR/swig-%{ver}
|
||||
zcat $RPM_SOURCE_DIR/swig-%{ver}.tar.gz | tar -xvvf -
|
||||
mv $RPM_BUILD_DIR/SWIG-%{ver} $RPM_BUILD_DIR/swig-%{ver}
|
||||
|
||||
# BUILD
|
||||
%build
|
||||
cd $RPM_BUILD_DIR/swig-%{ver}
|
||||
./configure --prefix=%{prefix}
|
||||
make
|
||||
|
||||
# INSTALL
|
||||
%install
|
||||
cd $RPM_BUILD_DIR/swig-%{ver}
|
||||
make prefix=$RPM_BUILD_DIR%{prefix} install
|
||||
|
||||
# FILES
|
||||
%files
|
||||
%{prefix}/lib/swig1.3/tcl/constarray.i
|
||||
%{prefix}/lib/swig1.3/tcl/consthash.i
|
||||
%{prefix}/lib/swig1.3/tcl/ptrlang.i
|
||||
%{prefix}/lib/swig1.3/tcl/tclsh.i
|
||||
%{prefix}/lib/swig1.3/tcl/typemaps.i
|
||||
%{prefix}/lib/swig1.3/tcl/wish.i
|
||||
%{prefix}/lib/swig1.3/tcl/object.swg
|
||||
%{prefix}/lib/swig1.3/tcl/swigtcl8.swg
|
||||
%{prefix}/lib/swig1.3/array.i
|
||||
%{prefix}/lib/swig1.3/autodoc.i
|
||||
%{prefix}/lib/swig1.3/carray.i
|
||||
%{prefix}/lib/swig1.3/constraints.i
|
||||
%{prefix}/lib/swig1.3/ctype.i
|
||||
%{prefix}/lib/swig1.3/exception.i
|
||||
%{prefix}/lib/swig1.3/malloc.i
|
||||
%{prefix}/lib/swig1.3/math.i
|
||||
%{prefix}/lib/swig1.3/memory.i
|
||||
%{prefix}/lib/swig1.3/objc.i
|
||||
%{prefix}/lib/swig1.3/pointer.i
|
||||
%{prefix}/lib/swig1.3/stdlib.i
|
||||
%{prefix}/lib/swig1.3/timers.i
|
||||
%{prefix}/lib/swig1.3/perl5/perlmain.i
|
||||
%{prefix}/lib/swig1.3/perl5/ptrlang.i
|
||||
%{prefix}/lib/swig1.3/perl5/typemaps.i
|
||||
#%{prefix}/lib/swig1.3/perl5/headers.swg # doesn't seem to exist
|
||||
%{prefix}/lib/swig1.3/perl5/perl5.swg
|
||||
#%{prefix}/lib/swig1.3/perl5/perl5mg.swg # doesn't seem to exist
|
||||
%{prefix}/lib/swig1.3/perl5/Makefile.pl
|
||||
%{prefix}/lib/swig1.3/python/embed.i
|
||||
%{prefix}/lib/swig1.3/python/embed13.i
|
||||
%{prefix}/lib/swig1.3/python/embed14.i
|
||||
%{prefix}/lib/swig1.3/python/embed15.i
|
||||
%{prefix}/lib/swig1.3/python/ptrlang.i
|
||||
%{prefix}/lib/swig1.3/python/typemaps.i
|
||||
%{prefix}/lib/swig1.3/python/typemaps_old.i
|
||||
%{prefix}/lib/swig1.3/python/defarg.swg
|
||||
%{prefix}/lib/swig1.3/python/python.swg
|
||||
%{prefix}/lib/swig1.3/guile/guilemain.i
|
||||
%{prefix}/lib/swig1.3/guile/interpreter.i
|
||||
%{prefix}/lib/swig1.3/guile/typemaps.i
|
||||
%{prefix}/lib/swig1.3/guile/guile.swg
|
||||
%{prefix}/lib/swig1.3/guile/guiledec.swg
|
||||
%{prefix}/lib/swig1.3/java/typemaps.i
|
||||
%{prefix}/lib/swig1.3/java/java.swg
|
||||
%{prefix}/lib/swig1.3/mzscheme/typemaps.i
|
||||
%{prefix}/lib/swig1.3/mzscheme/mzscheme.swg
|
||||
%{prefix}/bin/swig
|
||||
42
SWIG/Tools/swig.spec.1
Normal file
42
SWIG/Tools/swig.spec.1
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
%define version 1.3.7
|
||||
%define release 1
|
||||
|
||||
# Preamble
|
||||
Summary: Simplified Wrapper and Interface Generator
|
||||
Name: swig
|
||||
Version: %{version}
|
||||
Release: %{release}
|
||||
Copyright: BSD
|
||||
URL: http://www.swig.org
|
||||
Group: System Environment/Daemons
|
||||
Source0: http://download.sourceforge.net/swig/swig-%{version}.tar.gz
|
||||
Packager: Dustin Mitchell <dustin@cs.uchicago.edu>
|
||||
BuildRoot: /var/tmp/rpm/swig-root
|
||||
Prefix: /usr
|
||||
|
||||
%description
|
||||
SWIG is an interface compiler that connects programs written in C,
|
||||
C++, and Objective-C with scripting languages including Perl, Python,
|
||||
and Tcl/Tk. It works by taking the declarations commonly found in
|
||||
C/C++ header files and using them to generate the glue code (wrappers)
|
||||
that scripting languages need to access the underlying C/C++ code
|
||||
|
||||
# PREP
|
||||
%prep
|
||||
%setup -n SWIG-%{version}
|
||||
|
||||
# BUILD
|
||||
%build
|
||||
./configure --prefix=%prefix
|
||||
make
|
||||
|
||||
# INSTALL
|
||||
%install
|
||||
rm -rf ${RPM_BUILD_ROOT}
|
||||
install -d -m 755 ${RPM_BUILD_ROOT}
|
||||
make prefix=${RPM_BUILD_ROOT}%prefix install
|
||||
|
||||
# FILES
|
||||
%files
|
||||
%prefix/lib/*
|
||||
%prefix/bin/swig
|
||||
Loading…
Add table
Add a link
Reference in a new issue