From jafo at tummy.com  Mon Sep  6 06:01:53 2004
From: jafo at tummy.com (Sean Reifschneider)
Date: Mon Sep  6 06:02:08 2004
Subject: [Distutils] Feedback on a couple of patches for bdist_rpm.
Message-ID: <20040906040153.GA19705@tummy.com>

I've just been assigned a couple of patches related to bdist_rpm.  They
are from Anthony Tuininga (atuining), and I'd like to get feedback from
the Distutils SIG on them.

The first is:

   Summary: topdir calculated incorrectly in bdist_rpm
   URL: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022003&group_id=5470

   The _topdir directive to the bdist_rpm command is
   calculated incorrectly when the --bdist-base or
   --dist-dir options to the command use absolute path
   names. It should use os.path.abspath() instead, I
   believe. It would be nice if this patch was backported
   to earlier versions of Python as well but it is not
   critical for me. If you have further questions, let me
   know.

This patch changes the RPM command-line as:

             rpm_cmd.extend(['--define',
-                             '_topdir %s/%s' % (os.getcwd(), self.rpm_base),])
+                             '_topdir %s' % os.path.abspath(self.rpm_base)])

That looks good to me.

The next patch is:

   Summary: add support for the AutoReq flag in bdist_rpm
   URL: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022011&group_id=5470

   This patch supplies a new option to bdist_rpm to allow
   the setting of the AutoReq flag in RPM to false. This
   ensures that no dependencies are calculated
   automatically. If you have further questions or want
   the name of the option changed, please feel free to ask.

The option in this case is called "--no-autoreq".

I think these patches are both fine, but wanted to get feedback on them.
Any thoughts?

Thanks,
Sean
-- 
 I love the smell of napalm in the morning.  It smells like...  Victory.
               -- _Apocalypse_Now_
Sean Reifschneider, Member of Technical Staff <jafo@tummy.com>
tummy.com, ltd. - Linux Consulting since 1995.  Qmail, Python, SysAdmin
From brandon at ten22.rhodesmill.org  Fri Sep 10 10:20:52 2004
From: brandon at ten22.rhodesmill.org (Brandon Craig Rhodes)
Date: Fri Sep 10 10:30:20 2004
Subject: [Distutils] limiting symbols in C module
Message-ID: <87hdq6a61n.fsf@ten22.rhodesmill.org>

Python modules are often written as single .c files (sometimes quite
large) so that everything can be declared "static" except for the
init<module>() function; and though the Extending and Embedding
document is unfortunately rather quiet on the many issues that arise
during linking, the suggestion seems to be that minimizing the number
of symbols exported by the module is good.

As I update a Python module that provides an interface to an extensive
collection of existing C functions, I note that the process of linking
my module .o with all of the .o files produced by compiling the other
code produces a Python module with a huge number of symbols.

  1) Is this bad and should be avoided?

I note that running strip(1) with the "-K" option allows me to strip
all defined symbols from the module except for the one init<module>
symbol that I want to keep.

  2) Do the distutils know how to perform this operation?  This would
     even allow normal Python modules - that have all original code
     rather than being linked with existing .o files - to be written
     as several manageable .c files rather than one huge one.

  3) Can the distutils be induced to perform such a strip even if they
     do not quite know how themselves, or is the whole issue going to
     be different enough on, say, Windows, that it cannot be handled
     portably with the distutils in their current form?  Is there a
     portable way to put the strip command within a stanza that will
     only run on appropriately Unixish systems?

-- 
Brandon Craig Rhodes   brandon@rhodesmill.org   http://rhodesmill.org/brandon

From mal at egenix.com  Fri Sep 10 11:47:24 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Sep 10 11:47:27 2004
Subject: [Distutils] limiting symbols in C module
In-Reply-To: <87hdq6a61n.fsf@ten22.rhodesmill.org>
References: <87hdq6a61n.fsf@ten22.rhodesmill.org>
Message-ID: <4141782C.8070106@egenix.com>

Brandon Craig Rhodes wrote:
> Python modules are often written as single .c files (sometimes quite
> large) so that everything can be declared "static" except for the
> init<module>() function; and though the Extending and Embedding
> document is unfortunately rather quiet on the many issues that arise
> during linking, the suggestion seems to be that minimizing the number
> of symbols exported by the module is good.
> 
> As I update a Python module that provides an interface to an extensive
> collection of existing C functions, I note that the process of linking
> my module .o with all of the .o files produced by compiling the other
> code produces a Python module with a huge number of symbols.
> 
>   1) Is this bad and should be avoided?

There are probably a few cases where this may cause problems,
but in general, I don't see why distutils should try to strip
symbols from C extensions.

Is there a specific problem you are trying to solve ?

> I note that running strip(1) with the "-K" option allows me to strip
> all defined symbols from the module except for the one init<module>
> symbol that I want to keep.
> 
>   2) Do the distutils know how to perform this operation?  This would
>      even allow normal Python modules - that have all original code
>      rather than being linked with existing .o files - to be written
>      as several manageable .c files rather than one huge one.
> 
>   3) Can the distutils be induced to perform such a strip even if they
>      do not quite know how themselves, or is the whole issue going to
>      be different enough on, say, Windows, that it cannot be handled
>      portably with the distutils in their current form?  Is there a
>      portable way to put the strip command within a stanza that will
>      only run on appropriately Unixish systems?

You could write you own distutils extension to perform this
step in the linking phase. However, I'm not sure whether strip
is available on all Unix systems or whether the VCC compiler
on Windows has an option for this.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 10 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From brandon at rhodesmill.org  Fri Sep 10 13:22:24 2004
From: brandon at rhodesmill.org (Brandon Craig Rhodes)
Date: Fri Sep 10 13:30:20 2004
Subject: [Distutils] Re: limiting symbols in C module
References: <87hdq6a61n.fsf@ten22.rhodesmill.org> <4141782C.8070106@egenix.com>
Message-ID: <87sm9qfjwv.fsf@ten22.rhodesmill.org>

"M.-A. Lemburg" <mal@egenix.com> writes:

> There are probably a few cases where [a Python extension module
> defining hundreds of extra symbols] may cause problems, but in
> general, I don't see why distutils should try to strip symbols from
> C extensions.  Is there a specific problem you are trying to solve?

My "problem" is simply that my Python extension defines several
hundred symbols (some of which are not at all specific to its task,
like "range" and "start"), which violates section 1.12 of the
_Extending and Embedding_ document:

   ... all symbols in extension modules should be declared static,
   except for the module's initialization function, in order to avoid
   name clashes with other extension modules.

   http://docs.python.org/ext/using-cobjects.html

This made me concerned that, unless I took measures to remove the
extraneous symbols, I would be inviting lots of user complaints later
when "range" and "start" and so forth wound up conflicting with
symbols from other parts of Python on certain platforms.

I will happily ignore the issue if the Extending and Embedding
document is being overzealous; but if extraneous symbols are really
not much of a problem, I'm surprised that so many extension modules
are written as single huge .c files.

-- 
Brandon Craig Rhodes   brandon@rhodesmill.org   http://rhodesmill.org/brandon

From mal at egenix.com  Fri Sep 10 13:47:50 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Sep 10 13:47:55 2004
Subject: [Distutils] Re: limiting symbols in C module
In-Reply-To: <87sm9qfjwv.fsf@ten22.rhodesmill.org>
References: <87hdq6a61n.fsf@ten22.rhodesmill.org>	<4141782C.8070106@egenix.com>
	<87sm9qfjwv.fsf@ten22.rhodesmill.org>
Message-ID: <41419466.7010203@egenix.com>

Brandon Craig Rhodes wrote:
> "M.-A. Lemburg" <mal@egenix.com> writes:
> 
> 
>>There are probably a few cases where [a Python extension module
>>defining hundreds of extra symbols] may cause problems, but in
>>general, I don't see why distutils should try to strip symbols from
>>C extensions.  Is there a specific problem you are trying to solve?
> 
> 
> My "problem" is simply that my Python extension defines several
> hundred symbols (some of which are not at all specific to its task,
> like "range" and "start"), which violates section 1.12 of the
> _Extending and Embedding_ document:
> 
>    ... all symbols in extension modules should be declared static,
>    except for the module's initialization function, in order to avoid
>    name clashes with other extension modules.
> 
>    http://docs.python.org/ext/using-cobjects.html
> 
> This made me concerned that, unless I took measures to remove the
> extraneous symbols, I would be inviting lots of user complaints later
> when "range" and "start" and so forth wound up conflicting with
> symbols from other parts of Python on certain platforms.

In all the years I've been using Python with many different
extensions this issue has never come up.

> I will happily ignore the issue if the Extending and Embedding
> document is being overzealous; but if extraneous symbols are really
> not much of a problem, I'm surprised that so many extension modules
> are written as single huge .c files.

I think they only become a problem if one extension tries to
link to another extension dynamically and the linker find the
same symbol defined in multiple extensions. This doesn't work too
well in practice anyway, which is why the usual way to have
"linking" between extensions is to pass around a Python C object
holding the references to the API functions.

Could be wrong, though, or just lucky that the extensions pay
good attention to the quote from the docs you gave above.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 10 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From fdrake at acm.org  Fri Sep 10 15:42:53 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri Sep 10 15:43:02 2004
Subject: [Distutils] Re: limiting symbols in C module
In-Reply-To: <87sm9qfjwv.fsf@ten22.rhodesmill.org>
References: <87hdq6a61n.fsf@ten22.rhodesmill.org> <4141782C.8070106@egenix.com>
	<87sm9qfjwv.fsf@ten22.rhodesmill.org>
Message-ID: <200409100942.53660.fdrake@acm.org>

On Friday 10 September 2004 07:22 am, Brandon Craig Rhodes wrote:
 > "M.-A. Lemburg" <mal@egenix.com> writes:
 > > There are probably a few cases where [a Python extension module
 > > defining hundreds of extra symbols] may cause problems, but in
 > > general, I don't see why distutils should try to strip symbols from
 > > C extensions.  Is there a specific problem you are trying to solve?
 >
 > My "problem" is simply that my Python extension defines several
 > hundred symbols (some of which are not at all specific to its task,
 > like "range" and "start"), which violates section 1.12 of the
 > _Extending and Embedding_ document:

I think part of the issue is that the E&E manual was really describing the set 
of symbols introduced by the extension code, and had not really intended to 
reflect on the set of symbols provided by the external library.

That said, I don't think it *hurts* to avoid exporting more symbols than 
needed, but going to great lengths to change how distutils works is likely 
more pain than it's worth.

Also, how Python loads C extensions has changed a bit over time.  I think 
we're no longer using RTLD_GLOBAL on various Unix flavors, and I don't think 
there's a problem with this on Windows either (though I'm less sure of this).  
On Unix, you can use sys.getdlopenflags() to determine what flags are being 
use to load extensions; see the documentation for more information on this 
function.

 > This made me concerned that, unless I took measures to remove the
 > extraneous symbols, I would be inviting lots of user complaints later
 > when "range" and "start" and so forth wound up conflicting with
 > symbols from other parts of Python on certain platforms.
 >
 > I will happily ignore the issue if the Extending and Embedding
 > document is being overzealous; but if extraneous symbols are really
 > not much of a problem, I'm surprised that so many extension modules
 > are written as single huge .c files.

I think you'll live longer and more happily if you simply restrain the number 
of symbols you introduce in writing the binding to your C library.  If you 
only expose the symbols from the library and the init<module> function, 
you'll be doing as well as anyone else.  Think about it like this: if you 
were using the external library directly from C, you'd expect to have all the 
symbols from it available, right?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

From MAILsweeper at iena.com  Mon Sep 13 18:32:41 2004
From: MAILsweeper at iena.com (MAILsweeper@iena.com)
Date: Tue Sep 14 13:53:34 2004
Subject: [Distutils] RE:Re: approved screensaver
Message-ID: <20040914115332.E4E5F1E4005@bag.python.org>

Bonjour,

Ceci est une r?ponse automatique.

Le message de l'exp?diteur  distutils-sig@python.org et ? destination de
dirgen@journal-lunion.fr
 contient un virus.

LE VIRUS A ETE SUPPRIME.
From david at handysoftware.com  Thu Sep 16 16:53:14 2004
From: david at handysoftware.com (David Handy)
Date: Thu Sep 16 16:54:01 2004
Subject: [Distutils] Packaging with bdist_wininst on Python 2.3,
	installing on Python 2.4
Message-ID: <E1C7xdK-0000sk-Q5@arno2.handysoftware.com>

Packaging with bdist_wininst on Python 2.3, installing on Python 2.4

I decided to try installing a distutils package produced by bdist_wininst on
Python 2.3 on an alpha release of Python 2.4 (2.4a1). It's a pure python
package, designed for Python 2.3 and greater, so it should just work, right?

The good news is that the package .py files and data files got copied to the
right places.

The bad news is that the bdist_wininst message gave me an ugly error
message:

    *** Could not load Python ***

It did not run my post-install script, even though it said "Postinstall
script finished". (Also it did not compile .py files to .pyc)

Furthermore, it created an entry for my package in the "Add or Remove
Programs" control panel applet, but when I went to actually uninstall the
package, the package Remove*.exe program crashed. So I can't uninstall it
and I can't remove it from the list of installed programs (except by hacking
the registry.)

Is this all "expected behavior"? Am I hosed?

Do I have to produce separate bdist_wininst packages for Python 2.3 and
Python 2.4, and then try to document for my poor naive users (who are just
learning computer programming) which one to download and when?

What should I expect to happen if I produce a bdinst_wininst package with
Python 2.4 and then install it in Python 2.3?

Help!
David H.
From wfspotz at sandia.gov  Mon Sep 20 18:33:58 2004
From: wfspotz at sandia.gov (Bill Spotz)
Date: Mon Sep 20 18:34:13 2004
Subject: [Distutils] Query distutils for directory names
Message-ID: <DF3E39FC-0B22-11D9-98BE-000A95B950C4@sandia.gov>

Is there a way to query distutils to give me the name of the lib and/or 
temp directories (i.e., on my machine, 
build/lib.darwin-7.5.0-PowerMacintosh-2.3 and 
build/temp.darwin-7.5.0-PowerMacintosh-2.3) that distutils creates 
during its build process?  I can't find anything in the documentation.

This would be useful for telling test scripts where to find the local 
versions of the module(s), as well as for linking to SWIG runtime 
libraries that I would like to have distutils compile.

I wrote some usable python code that manually concatenates the pieces 
together, put I do not trust its portability.

Thanks

** Bill Spotz                                              **
** Sandia National Laboratories  Voice: (505)845-0170      **
** P.O. Box 5800                 Fax:   (505)284-5451      **
** Albuquerque, NM 87185-0316    Email: wfspotz@sandia.gov **


From PaulLambert at AirgoNetworks.Com  Tue Sep 21 01:26:38 2004
From: PaulLambert at AirgoNetworks.Com (Paul Lambert)
Date: Tue Sep 21 01:26:42 2004
Subject: [Distutils] Variations in packaging
Message-ID: <3FFBC907DD03A34CA4410C5C745DEB12046738AF@wnimail.WoodsideNet.Com>

 
Hello,


I'm trying to build three different distributions from the same set of
packages, with slight variations in the modules that are included.
What's the best way to accomplish these 'setup' variations?

Currently, since the setup.py needs to be in the root directory, I've
simply created three different setup's (with different names).  This is
problomatic given that they all share the same MANIFEST and MANIFEST.in
file. So, now I'm resorting to dynamically creating a MANIFEST.in ...
It seems like there should be an easier way...
  

Thanks in advance for your help,

Paul

From calvin at users.sourceforge.net  Thu Sep 23 13:40:04 2004
From: calvin at users.sourceforge.net (Bastian Kleineidam)
Date: Thu Sep 23 13:40:09 2004
Subject: [Distutils] Query distutils for directory names
In-Reply-To: <DF3E39FC-0B22-11D9-98BE-000A95B950C4@sandia.gov>
References: <DF3E39FC-0B22-11D9-98BE-000A95B950C4@sandia.gov>
Message-ID: <20040923114003.GA11425@treasure>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Bill,

On Mon, Sep 20, 2004 at 10:33:58AM -0600, Bill Spotz wrote:
> Is there a way to query distutils to give me the name of the lib and/or 
> temp directories (i.e., on my machine, 
> build/lib.darwin-7.5.0-PowerMacintosh-2.3 and 
> build/temp.darwin-7.5.0-PowerMacintosh-2.3) that distutils creates 
> during its build process?  I can't find anything in the documentation.
The distutils.command.build class has the following variables which
might help you:
        self.build_purelib
        self.build_platlib
        self.build_lib
        self.build_temp
        self.build_scripts

So you could make a subclass of the build class:

class mybuild (distutils.command.build, object):
    def run (self):
        super(mybuild, self).run()
        print "build dir for platform-neutral modules is", self.build_purelib


setup(...
      cmdclass = {'build': mybuild},
      ...
     ) 

This way, you always have the correct build dir available even when the
user changes it with command line options.

Regards,
  Bastian

- -- 
  ,''`.    Bastian Kleineidam  .  calvin (at) debian.org
 : :' :
 `. `'    GnuPG Schl?ssel http://kampfwurst.net/gpgkey.txt
   `-

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBUrYTeBwlBDLsbz4RAoiVAKDTJveuhEuzeX0+Q+K3S3uASrkLOQCgmsrS
hXo0/WTlgoZTiRobmA7iO9A=
=TKSj
-----END PGP SIGNATURE-----
From frostbite.adam at gmail.com  Sat Sep 25 14:18:18 2004
From: frostbite.adam at gmail.com (Adam McCarthy)
Date: Sat Sep 25 14:18:22 2004
Subject: [Distutils] Pyrex/Distutils Compile - Missing Symbols in Python
In-Reply-To: <39dc49320409241236755a5f64@mail.gmail.com>
References: <39dc49320409241236755a5f64@mail.gmail.com>
Message-ID: <39dc493204092505181c24a9b9@mail.gmail.com>

I'm trying to get a cross compiler working for arm-wince-pe.  This is
the output for the primes Pyrex example.  If I compile simple Hello,
World's etc, it works fine, but for some reason Python
libraries/headers seem to produce this.  I have libpython2.3.a in
/usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/../../../../arm-wince-pe/lib/
and /usr/lib/python2.3/config.  I've checked it using
arm-wince-pe-objdump.  I also extracted it with
arm-wince-pe-ar and it contains the symbols.

Below the following output, I've also pasted a debug output from the linker.

Any ideas?

$ python setup.py build_ext --inplace -c cygwin
running build_ext
building 'Primes' extension
creating build
creating build/temp.cygwin-1.5.11-i686-2.3
arm-wince-pe-gcc -O -Wall -I/usr/include/python2.3 -c primes.c -o build/temp.cyg
win-1.5.11-i686-2.3/primes.o
primes.c: In function `__pyx_f_6primes_primes':
primes.c:137: warning: label `__pyx_L4' defined but not used
primes.c:108: warning: label `__pyx_L6' defined but not used
primes.c:98: warning: label `__pyx_L5' defined but not used
primes.c:89: warning: label `__pyx_L3' defined but not used
primes.c: At top level:
primes.c:12: warning: `__Pyx_UnpackItem' declared `static' but never defined
primes.c:13: warning: `__Pyx_EndUnpack' declared `static' but never defined
primes.c:14: warning: `__Pyx_PrintItem' declared `static' but never defined
primes.c:15: warning: `__Pyx_PrintNewline' declared `static' but never defined
primes.c:16: warning: `__Pyx_Raise' declared `static' but never defined
primes.c:17: warning: `__Pyx_ReRaise' declared `static' but never defined
primes.c:18: warning: `__Pyx_Import' declared `static' but never defined
primes.c:19: warning: `__Pyx_GetExcValue' declared `static' but never defined
primes.c:20: warning: `__Pyx_ArgTypeTest' declared `static' but never defined
primes.c:21: warning: `__Pyx_TypeTest' declared `static' but never defined
primes.c:22: warning: `__Pyx_GetStarArgs' declared `static' but never defined
primes.c:23: warning: `__Pyx_WriteUnraisable' declared `static' but never define
d
primes.c:25: warning: `__Pyx_ImportType' declared `static' but never defined
primes.c:26: warning: `__Pyx_SetVtable' declared `static' but never defined
primes.c:27: warning: `__Pyx_GetVtable' declared `static' but never defined
primes.c:28: warning: `__Pyx_CreateClass' declared `static' but never defined
primes.c:30: warning: `__Pyx_InitStrings' declared `static' but never defined
primes.c:31: warning: `__Pyx_GetName' declared `static' but never defined
writing build/temp.cygwin-1.5.11-i686-2.3/Primes.def
arm-wince-pe-gcc -mdll -static -s build/temp.cygwin-1.5.11-i686-2.3/primes.o bui
ld/temp.cygwin-1.5.11-i686-2.3/Primes.def -L/usr/lib/python2.3/config -lpython2.
3 -o Primes.dll
Cannot export initPrimes (initPrimes): symbol not found
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x30):primes.c: undefined refer
ence to `PyArg_ParseTupleAndKeywords'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x54):primes.c: undefined refer
ence to `PyList_New'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x130):primes.c: undefined refe
rence to `PyObject_GetAttr'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x144):primes.c: undefined refe
rence to `PyInt_FromLong'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x158):primes.c: undefined refe
rence to `PyTuple_New'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x174):primes.c: undefined refe
rence to `PyObject_CallObject'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x2d0):primes.c: undefined refe
rence to `_Py_NoneStruct'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x308):primes.c: undefined refe
rence to `Py_InitModule4'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x320):primes.c: undefined refe
rence to `PyImport_AddModule'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x348):primes.c: undefined refe
rence to `PyObject_SetAttrString'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x3d4):primes.c: undefined refe
rence to `PyString_InternFromString'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x430):primes.c: undefined refe
rence to `PyString_FromString'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x444):primes.c: undefined refe
rence to `PyString_FromString'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x45c):primes.c: undefined refe
rence to `PyModule_GetDict'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x470):primes.c: undefined refe
rence to `PyTuple_New'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x484):primes.c: undefined refe
rence to `PyString_FromString'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x4d0):primes.c: undefined refe
rence to `PyCode_New'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x4e0):primes.c: undefined refe
rence to `PyThreadState_Get'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x4f0):primes.c: undefined refe
rence to `PyFrame_New'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x508):primes.c: undefined refe
rence to `PyTraceBack_Here'
/usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/../../../../arm-wince-pe/lib/crt0.o(.t
ext+0x6c): undefined reference to `WinMain'
collect2: ld returned 1 exit status
error: command 'arm-wince-pe-gcc' failed with exit status 1

================================================================================

$ arm-wince-pe-gcc -mdll -static -s build/temp.cygwin-1.5.11-i686-2.3/primes.o
build/temp.cygwin-1.5.11-i686-2.3/Primes.def -L/usr/lib/python2.3/config -lpythe
on2.3 -o Primes.dll -v -Wl,-debug
Reading specs from /usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/specsundefined refe
Configured with: ./configure --enable-languages=c,c++ --target=arm-wince-pe : (r
econfigured) ./configure --target=arm-wince-pe --host=arm-wince-pe --enable-lang

uages=c,c++ --enable-multilib=no : (reconfigured) ./configure --target=arm-wince
-pe --host=arm-wince-pe --enable-languages=c,c++ --enable-multilib=no : (reconfi
gured) ./configure --target=arm-pe --enable-languages=c,c++ --enable-multilib=no
 --with-newlib : (reconfigured) ./configure --target=arm-pe --enable-languages=c
,c++ --enable-multilib=no --with-newlib : (reconfigured) ./configure --target=ar
m-pe --enable-languages=c,c++ --enable-multilib=no --with-newlib : (reconfigured
) ./configure --target=arm-wince-pe --enable-languages=c,c++ --enable-multilib=n
o --with-newlib : (reconfigured) ./configure --target=arm-wince-pe --enable-lang
uages=c,c++ --enable-multilib=no --with-newlib
Thread model: single2.1
gcc version 3.3.3rned 1 exit status
 /usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/collect2.exe -X -o Primes.dll -s /usr
/local/lib/gcc-lib/arm-wince-pe/3.3.3/../../../../arm-wince-pe/lib/crt0.o -L/usr
/lib/python2.3/config -L/usr/local/lib/gcc-lib/arm-wince-pe/3.3.3 -L/usr/local/l
ib/gcc-lib/arm-wince-pe/3.3.3/../../../../arm-wince-pe/lib build/temp.cygwin-1.5
.11-i686-2.3/primes.o build/temp.cygwin-1.5.11-i686-2.3/Primes.def -lpython2.3 -
debug -lcdll -lcdllimp -lcoredll
Convert string '/usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/:/usr/local/lib/gcc-li
b/arm-wince-pe/3.3.3/:/usr/local/lib/gcc-lib/arm-wince-pe/:/usr/lib/gcc/arm-winc
e-pe/3.3.3/:/usr/lib/gcc/arm-wince-pe/:/usr/local/lib/gcc-lib/arm-wince-pe/3.3.3
/../../../../arm-wince-pe/bin/arm-wince-pe/3.3.3/:/usr/local/lib/gcc-lib/arm-win
ce-pe/3.3.3/../../../../arm-wince-pe/bin/' into prefixes, separator = ':'
  - add prefix: /usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/
  - add prefix: /usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/
  - add prefix: /usr/local/lib/gcc-lib/arm-wince-pe/
  - add prefix: /usr/lib/gcc/arm-wince-pe/3.3.3/
  - add prefix: /usr/lib/gcc/arm-wince-pe/
  - add prefix: /usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/../../../../arm-wince-
pe/bin/arm-wince-pe/3.3.3/
  - add prefix: /usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/../../../../arm-wince-
pe/bin/
Convert string '/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/
system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Progr
am Files/ATI Technologies/ATI Control Panel' into prefixes, separator = ':'
  - add prefix: /usr/local/bin/
  - add prefix: /usr/bin/
  - add prefix: /bin/
  - add prefix: /usr/X11R6/bin/
  - add prefix: /cygdrive/c/WINDOWS/system32/
  - add prefix: /cygdrive/c/WINDOWS/
  - add prefix: /cygdrive/c/WINDOWS/System32/Wbem/
  - add prefix: /cygdrive/c/Program Files/ATI Technologies/ATI Control Panel/
Looking for 'real-ld'
Looking for 'collect-ld'
Looking for 'ld'
Looking for 'gnm'
Looking for 'arm-wince-pe-gnm'
Looking for 'nm'
Looking for 'gstrip'
Looking for 'arm-wince-pe-gstrip'
Looking for 'strip'
Looking for 'arm-wince-pe-gcc'
Looking for 'arm-wince-pe-gcc'
collect2 version 3.3.3 (ARM/pe)
ld_file_name        = /usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/../../../../arm-
wince-pe/bin/ld
c_file_name         = /usr/local/bin/arm-wince-pe-gcc
nm_file_name        = /usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/../../../../arm-
wince-pe/bin/nm
strip_file_name     = /usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/../../../../arm-
wince-pe/bin/strip
c_file              = /cygdrive/c/DOCUME~1/adam/LOCALS~1/Temp/ccAiL4ml.c
o_file              = /cygdrive/c/DOCUME~1/adam/LOCALS~1/Temp/cc0qmZzw.o
COLLECT_GCC_OPTIONS = '-mdll' '-static' '-s' '-L/usr/lib/python2.3/config' '-o'
'Primes.dll' '-v'
COLLECT_GCC         = arm-wince-pe-gcc
COMPILER_PATH       = /usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/:/usr/local/lib/
gcc-lib/arm-wince-pe/3.3.3/:/usr/local/lib/gcc-lib/arm-wince-pe/:/usr/lib/gcc/ar
m-wince-pe/3.3.3/:/usr/lib/gcc/arm-wince-pe/:/usr/local/lib/gcc-lib/arm-wince-pe
/3.3.3/../../../../arm-wince-pe/bin/arm-wince-pe/3.3.3/:/usr/local/lib/gcc-lib/a
rm-wince-pe/3.3.3/../../../../arm-wince-pe/bin/
LIBRARY_PATH        = /usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/:/usr/lib/gcc/ar
m-wince-pe/3.3.3/:/usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/../../../../arm-winc
e-pe/lib/arm-wince-pe/3.3.3/:/usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/../../../
../arm-wince-pe/lib/

/usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/../../../../arm-wince-pe/bin/ld -X -o
Primes.dll -s /usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/../../../../arm-wince-pe

/lib/crt0.o -L/usr/lib/python2.3/config -L/usr/local/lib/gcc-lib/arm-wince-pe/3.
3.3 -L/usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/../../../../arm-wince-pe/lib bui
ld/temp.cygwin-1.5.11-i686-2.3/primes.o build/temp.cygwin-1.5.11-i686-2.3/Primes
.def -lpython2.3 -lcdll -lcdllimp -lcoredll
Cannot export initPrimes (initPrimes): symbol not found
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x30):primes.c: undefined refer
ence to `PyArg_ParseTupleAndKeywords'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x54):primes.c: undefined refer
ence to `PyList_New'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x130):primes.c: undefined refe
rence to `PyObject_GetAttr'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x144):primes.c: undefined refe
rence to `PyInt_FromLong'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x158):primes.c: undefined refe
rence to `PyTuple_New'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x174):primes.c: undefined refe
rence to `PyObject_CallObject'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x2d0):primes.c: undefined refe
rence to `_Py_NoneStruct'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x308):primes.c: undefined refe
rence to `Py_InitModule4'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x320):primes.c: undefined refe
rence to `PyImport_AddModule'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x348):primes.c: undefined refe
rence to `PyObject_SetAttrString'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x3d4):primes.c: undefined refe
rence to `PyString_InternFromString'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x430):primes.c: undefined refe
rence to `PyString_FromString'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x444):primes.c: undefined refe
rence to `PyString_FromString'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x45c):primes.c: undefined refe
rence to `PyModule_GetDict'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x470):primes.c: undefined refe
rence to `PyTuple_New'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x484):primes.c: undefined refe
rence to `PyString_FromString'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x4d0):primes.c: undefined refe
rence to `PyCode_New'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x4e0):primes.c: undefined refe
rence to `PyThreadState_Get'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x4f0):primes.c: undefined refe
rence to `PyFrame_New'
build/temp.cygwin-1.5.11-i686-2.3/primes.o(.text+0x508):primes.c: undefined refe
rence to `PyTraceBack_Here'
/usr/local/lib/gcc-lib/arm-wince-pe/3.3.3/../../../../arm-wince-pe/lib/crt0.o(.t
ext+0x6c): undefined reference to `WinMain'
collect2: ld returned 1 exit status
[Leaving /cygdrive/c/DOCUME~1/adam/LOCALS~1/Temp/ccAiL4ml.c]
[Leaving /cygdrive/c/DOCUME~1/adam/LOCALS~1/Temp/cc0qmZzw.o]
[Leaving /cygdrive/c/DOCUME~1/adam/LOCALS~1/Temp/ccqzXTMH.ld]
[Leaving Primes.dll]
From nobody at xara.com  Mon Sep 27 14:00:10 2004
From: nobody at xara.com (nobody@xara.com)
Date: Mon Sep 27 14:00:12 2004
Subject: [Distutils] Re: report
Message-ID: <20040927120010.A8A99682FB@relay.xara.com>

This is an automated response to your email sent to Xara Technical Support (support@xara.com) which explains the various help resources available from Xara.

 *** Please note that your original email will not be read. ***
  
In order to offer a more efficient and timely level of technical support, 24 hours a day, 7 days a week we offer a range of online support services.  A list of Frequently Asked Questions and answers can be found on our website at http://www.xara.com/support/. We aim to add to the site over time so that it is always as up to date as possible. Helpful advice by experienced users is also available in the TalkGraphics Xara forums  (http://www.talkgraphics.com) and The XaraXone (http://www.xaraxone.com) website. 

These facilities are designed to enhance our existing email based support system, not to replace it. If you cannot find an answer to your question, the FAQ pages offer an e-mail link with which you can contact a member of the technical support staff. The FAQs answer all the common product, purchasing and account related questions and we urge you to check the FAQs first before contacting us directly, so that our experienced tech support staff can concentrate on giving a fast and effective service to those customers who require their help most.

The following are the top three commonly asked questions: 

Q.: I receive The message 'Invalid serial number, your program has not been unlocked' when entering my serial number
A.: The following information applies to customers that have purchased Xara 3D 5 between August 2002 and 31st September 2003 and are installing Xara 3D 5 from their CD.

1. Please install Xara 3D 5 from your CD and ensure it is not running. 

2. Download and execute Xara3dPatch.exe from http://downloads.xara.com/downloads/software/xara3dpatch.exe  

3. Run Xara 3d 5 and enter the serial number as displayed upon your CD.

This will resolve the unlocking difficulties you have encountered.  If problems persist, please run Xara 3D 5 and attempt to enter your serial number causing the error to be displayed prior to following the steps above.

  
Q.: 'My unlock-code does not work' or 'I need a new unlock-code for my Xara product'. 
A.: Click on the link 'Enter your unlock code' on the startup panel of
 Webstyle 2.1/3.0/3.1 or Xara3D 4/5 or Menu Maker and follow the instructions. 

In the case of Xara X or older versions of Xara3D or Webstyle click on 'Purchase', then follow the instructions. You will need your XaraClub user name and password. We have a password reminder hint page here:

https://secure.commerce.xara.com/registration/passwordhint.asp
  
Q.: My Xara product does not work properly on Windows NT4, 2000 or XP 
A.: You must install and unlock your Xara product whilst logged on to the computers 'Administrator' account. 
  
Q.: How do I insert a Navigation Bar (NavBar) created in Webstyle within my webpage designs? 
A.: Please refer to the Help file: Help - Index - Navbars - using on a webpage

From wfspotz at sandia.gov  Mon Sep 27 18:03:04 2004
From: wfspotz at sandia.gov (Bill Spotz)
Date: Mon Sep 27 18:04:05 2004
Subject: [Distutils] SWIG runtime libs/Python distutils combo on Mac
Message-ID: <B6E6E76A-109E-11D9-A16C-000A95B950C4@sandia.gov>

This problem concerns using distutils to compile a set of python 
modules that are generated by SWIG, so I am cross-posting to both SWIG 
and distutils mailing lists.

I use SWIG to wrap several packages that are intended to be both 
independent and interoperable.  So I am creating separate python 
extensions that link to the swig runtime libraries.

Previously, I linked to installed system runtime libraries, but this is 
not the preferred approach, and indeed, swig 1.3.22 does not support 
it.  Instead, I am supposed to generate my own local runtime library, 
and link to it.  Fine; this would seem to be more portable.

The SWIG documentation says to do the following (for Linux), with the 
caveat that compiling dynamic libraries is different on every system:

------------------
     % swig -runtime -python swigrun.i
     % gcc -fpic swigrun_wrap.c -o swigrun_wrap.o
     % gcc -shared swigrun_wrap.o -o libswigrunpy.so

Now, you compile all of the normal SWIG modules using the -noruntime 
option:

     % swig -noruntime -c++ -python A.i
     % swig -noruntime -c++ -python B.i

Finally, when linking the dynamically loadable modules, you need to 
link again the special runtime library above. For example (Linux) :

     % g++ -shared A_wrap.o -L. -lswigrunpy -o _A.so
     % g++ -shared B_wrap.o -L. -lswigrunpy -o _B.so
------------------

To get around the portability problem, I have decided to use python's 
distutils module to handle the compilation issues.  In my setup.py 
script, I define

   SwigRun = Extension("PyTrilinos.libswigrun", ["src/swigrun_wrap.c"])

and this works, as build/lib.blahblahblah/PyTrilinos/libswigrun.so gets 
created properly.  When I define real extensions in setup.py, they are 
created with keyword arguments

     library_dirs    = [..., "build/lib.blahblahblah/PyTrilinos", ...],
     libraries       = [..., "swigrun", ...],

which gives me the link command arguments I want: 
-Lbuild/lib.blahblahblah/PyTrilinons -lswigrun.  However, on my Mac, 
when the link command is invoked, I get

     ld: can't locate file for: -lswigrun

I strongly suspect that the Mac's ld command does not search for 
libswigrun.so when -lswigrun is given as a command line argument (the 
old system libraries have .la and .dylib extensions).  But I cannot 
figure out how to get setup.py to compile to a different suffix.

Any suggestions would be appreciated.

** Bill Spotz                                              **
** Sandia National Laboratories  Voice: (505)845-0170      **
** P.O. Box 5800                 Fax:   (505)284-5451      **
** Albuquerque, NM 87185-0316    Email: wfspotz@sandia.gov **


From bob at redivi.com  Mon Sep 27 18:19:28 2004
From: bob at redivi.com (Bob Ippolito)
Date: Mon Sep 27 18:20:02 2004
Subject: [Distutils] SWIG runtime libs/Python distutils combo on Mac
In-Reply-To: <B6E6E76A-109E-11D9-A16C-000A95B950C4@sandia.gov>
References: <B6E6E76A-109E-11D9-A16C-000A95B950C4@sandia.gov>
Message-ID: <01963C22-10A1-11D9-9F79-000A95686CD8@redivi.com>

On Sep 27, 2004, at 12:03 PM, Bill Spotz wrote:

> To get around the portability problem, I have decided to use python's 
> distutils module to handle the compilation issues.  In my setup.py 
> script, I define
>
>   SwigRun = Extension("PyTrilinos.libswigrun", ["src/swigrun_wrap.c"])
>
> and this works, as build/lib.blahblahblah/PyTrilinos/libswigrun.so 
> gets created properly.  When I define real extensions in setup.py, 
> they are created with keyword arguments
>
>     library_dirs    = [..., "build/lib.blahblahblah/PyTrilinos", ...],
>     libraries       = [..., "swigrun", ...],
>
> which gives me the link command arguments I want: 
> -Lbuild/lib.blahblahblah/PyTrilinons -lswigrun.  However, on my Mac, 
> when the link command is invoked, I get
>
>     ld: can't locate file for: -lswigrun
>
> I strongly suspect that the Mac's ld command does not search for 
> libswigrun.so when -lswigrun is given as a command line argument (the 
> old system libraries have .la and .dylib extensions).  But I cannot 
> figure out how to get setup.py to compile to a different suffix.

You can't do this on OS X.  You can link to two types of files in OS X, 
static libraries and dylibs.  Python extension modules are bundles 
(runtime loadable code) and can not be linked to at compile time.  You 
should either compile swigrun_wrap into every extension, or make it a 
static library (which is more or less the same thing).

-bob
From symbiont at berlios.de  Mon Sep 27 18:44:34 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Mon Sep 27 18:46:54 2004
Subject: [Distutils] Add RPM-friendly Record Option
Message-ID: <200409280044.34908.symbiont@berlios.de>

Hi:

I'm new here. I submitted a patch for your kind review that spews out an 
RPM-consumable list including %dir and %lang attributes.  The concept 
could be expanded further.

The patch link is here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1035576&group_id=5470&atid=305470

I know install.py is probably supposed to be RPM-agnostic, but I saw 
this as the easiest solution.  The --record option is still in-tact 
with a minor aesthetic improvement of using a list comprehension. 	

Critic away!

take care,
-- 
-jeff
From jafo at tummy.com  Wed Sep 29 19:25:29 2004
From: jafo at tummy.com (Sean Reifschneider)
Date: Wed Sep 29 19:25:46 2004
Subject: [Distutils] Add RPM-friendly Record Option
In-Reply-To: <200409280044.34908.symbiont@berlios.de>
References: <200409280044.34908.symbiont@berlios.de>
Message-ID: <20040929172529.GA19153@tummy.com>

On Tue, Sep 28, 2004 at 12:44:34AM +0800, Jeff Pitman wrote:
>I'm new here. I submitted a patch for your kind review that spews out an 
>RPM-consumable list including %dir and %lang attributes.  The concept 
>could be expanded further.

Any comments on this patch?  symbiont has been doing a lot of work with
RPMs, and has run into some issues where he needs some more features than
the normal record file provides.  Any objections to my accepting this
patch?

Sean
-- 
 Well son, a funny thing about regret is that it's better to regret something
 you HAVE done than regret something you haven't done.
Sean Reifschneider, Member of Technical Staff <jafo@tummy.com>
tummy.com, ltd. - Linux Consulting since 1995.  Qmail, Python, SysAdmin
From pje at telecommunity.com  Wed Sep 29 19:45:38 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed Sep 29 19:45:36 2004
Subject: [Distutils] Add RPM-friendly Record Option
In-Reply-To: <20040929172529.GA19153@tummy.com>
References: <200409280044.34908.symbiont@berlios.de>
	<200409280044.34908.symbiont@berlios.de>
Message-ID: <5.1.1.6.0.20040929134309.02dc6d10@mail.telecommunity.com>

At 11:25 AM 9/29/04 -0600, Sean Reifschneider wrote:
>On Tue, Sep 28, 2004 at 12:44:34AM +0800, Jeff Pitman wrote:
> >I'm new here. I submitted a patch for your kind review that spews out an
> >RPM-consumable list including %dir and %lang attributes.  The concept
> >could be expanded further.
>
>Any comments on this patch?  symbiont has been doing a lot of work with
>RPMs, and has run into some issues where he needs some more features than
>the normal record file provides.  Any objections to my accepting this
>patch?

Isn't distutils supposed to be compatible with older versions of Python, 
e.g. 1.5.2?  The list comprehension won't work, and it removes a minor 
optimization ('if self.root:').

I don't see an issue with adding the feature, or in moving the write-record 
facility to a separate method, but the changes to existing feature(s) 
should be reversed, IMO.

From wfspotz at sandia.gov  Wed Sep 29 22:43:06 2004
From: wfspotz at sandia.gov (Bill Spotz)
Date: Wed Sep 29 22:43:22 2004
Subject: [Distutils] SWIG runtime libs/Python distutils combo on Mac
In-Reply-To: <01963C22-10A1-11D9-9F79-000A95686CD8@redivi.com>
References: <B6E6E76A-109E-11D9-A16C-000A95B950C4@sandia.gov>
	<01963C22-10A1-11D9-9F79-000A95686CD8@redivi.com>
Message-ID: <2A65279A-1258-11D9-A045-000A95B950C4@sandia.gov>

I'm pretty sure I cannot compile swigrun_wrap into every extension or 
make it a static library, since each extension will get its own copy 
and that will defeat the purpose of the runtime libraries.  Sounds like 
I need to create a dylib, that python distutils can't help me, and that 
I'll have to learn libtool if I want to make it portable.  Does that 
sound about right?

On Sep 27, 2004, at 10:19 AM, Bob Ippolito wrote:

> On Sep 27, 2004, at 12:03 PM, Bill Spotz wrote:
>
>> To get around the portability problem, I have decided to use python's 
>> distutils module to handle the compilation issues.  In my setup.py 
>> script, I define
>>
>>   SwigRun = Extension("PyTrilinos.libswigrun", ["src/swigrun_wrap.c"])
>>
>> and this works, as build/lib.blahblahblah/PyTrilinos/libswigrun.so 
>> gets created properly.  When I define real extensions in setup.py, 
>> they are created with keyword arguments
>>
>>     library_dirs    = [..., "build/lib.blahblahblah/PyTrilinos", ...],
>>     libraries       = [..., "swigrun", ...],
>>
>> which gives me the link command arguments I want: 
>> -Lbuild/lib.blahblahblah/PyTrilinons -lswigrun.  However, on my Mac, 
>> when the link command is invoked, I get
>>
>>     ld: can't locate file for: -lswigrun
>>
>> I strongly suspect that the Mac's ld command does not search for 
>> libswigrun.so when -lswigrun is given as a command line argument (the 
>> old system libraries have .la and .dylib extensions).  But I cannot 
>> figure out how to get setup.py to compile to a different suffix.
>
> You can't do this on OS X.  You can link to two types of files in OS 
> X, static libraries and dylibs.  Python extension modules are bundles 
> (runtime loadable code) and can not be linked to at compile time.  You 
> should either compile swigrun_wrap into every extension, or make it a 
> static library (which is more or less the same thing).
>
> -bob

** Bill Spotz                                              **
** Sandia National Laboratories  Voice: (505)845-0170      **
** P.O. Box 5800                 Fax:   (505)284-5451      **
** Albuquerque, NM 87185-0316    Email: wfspotz@sandia.gov **


From bob at redivi.com  Wed Sep 29 22:57:01 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Sep 29 22:57:07 2004
Subject: [Distutils] SWIG runtime libs/Python distutils combo on Mac
In-Reply-To: <2A65279A-1258-11D9-A045-000A95B950C4@sandia.gov>
References: <B6E6E76A-109E-11D9-A16C-000A95B950C4@sandia.gov>
	<01963C22-10A1-11D9-9F79-000A95686CD8@redivi.com>
	<2A65279A-1258-11D9-A045-000A95B950C4@sandia.gov>
Message-ID: <1C82E832-125A-11D9-ADA7-000A95686CD8@redivi.com>

On Sep 29, 2004, at 4:43 PM, Bill Spotz wrote:

> On Sep 27, 2004, at 10:19 AM, Bob Ippolito wrote:
>
>> On Sep 27, 2004, at 12:03 PM, Bill Spotz wrote:
>>
>>> To get around the portability problem, I have decided to use 
>>> python's distutils module to handle the compilation issues.  In my 
>>> setup.py script, I define
>>>
>>>   SwigRun = Extension("PyTrilinos.libswigrun", 
>>> ["src/swigrun_wrap.c"])
>>>
>>> and this works, as build/lib.blahblahblah/PyTrilinos/libswigrun.so 
>>> gets created properly.  When I define real extensions in setup.py, 
>>> they are created with keyword arguments
>>>
>>>     library_dirs    = [..., "build/lib.blahblahblah/PyTrilinos", 
>>> ...],
>>>     libraries       = [..., "swigrun", ...],
>>>
>>> which gives me the link command arguments I want: 
>>> -Lbuild/lib.blahblahblah/PyTrilinons -lswigrun.  However, on my Mac, 
>>> when the link command is invoked, I get
>>>
>>>     ld: can't locate file for: -lswigrun
>>>
>>> I strongly suspect that the Mac's ld command does not search for 
>>> libswigrun.so when -lswigrun is given as a command line argument 
>>> (the old system libraries have .la and .dylib extensions).  But I 
>>> cannot figure out how to get setup.py to compile to a different 
>>> suffix.
>>
>> You can't do this on OS X.  You can link to two types of files in OS 
>> X, static libraries and dylibs.  Python extension modules are bundles 
>> (runtime loadable code) and can not be linked to at compile time.  
>> You should either compile swigrun_wrap into every extension, or make 
>> it a static library (which is more or less the same thing).
> I'm pretty sure I cannot compile swigrun_wrap into every extension or 
> make it a static library, since each extension will get its own copy 
> and that will defeat the purpose of the runtime libraries.  Sounds 
> like I need to create a dylib, that python distutils can't help me, 
> and that I'll have to learn libtool if I want to make it portable.  
> Does that sound about right?

I don't think your assessment of swigrun_wrap is correct.

-bob
From bob at redivi.com  Wed Sep 29 23:27:35 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Sep 29 23:27:40 2004
Subject: [Distutils] SWIG runtime libs/Python distutils combo on Mac
In-Reply-To: <F8D9BE5A-125B-11D9-A045-000A95B950C4@sandia.gov>
References: <B6E6E76A-109E-11D9-A16C-000A95B950C4@sandia.gov>
	<01963C22-10A1-11D9-9F79-000A95686CD8@redivi.com>
	<2A65279A-1258-11D9-A045-000A95B950C4@sandia.gov>
	<1C82E832-125A-11D9-ADA7-000A95686CD8@redivi.com>
	<F8D9BE5A-125B-11D9-A045-000A95B950C4@sandia.gov>
Message-ID: <613E30CC-125E-11D9-8E8C-000A95686CD8@redivi.com>


On Sep 29, 2004, at 5:10 PM, Bill Spotz wrote:

>
> On Sep 29, 2004, at 2:57 PM, Bob Ippolito wrote:
>
>> On Sep 29, 2004, at 4:43 PM, Bill Spotz wrote:
>>
>>> On Sep 27, 2004, at 10:19 AM, Bob Ippolito wrote:
>>>
>>>> On Sep 27, 2004, at 12:03 PM, Bill Spotz wrote:
>>>>
>>>>> To get around the portability problem, I have decided to use 
>>>>> python's distutils module to handle the compilation issues.  In my 
>>>>> setup.py script, I define
>>>>>
>>>>>   SwigRun = Extension("PyTrilinos.libswigrun", 
>>>>> ["src/swigrun_wrap.c"])
>>>>>
>>>>> and this works, as build/lib.blahblahblah/PyTrilinos/libswigrun.so 
>>>>> gets created properly.  When I define real extensions in setup.py, 
>>>>> they are created with keyword arguments
>>>>>
>>>>>     library_dirs    = [..., "build/lib.blahblahblah/PyTrilinos", 
>>>>> ...],
>>>>>     libraries       = [..., "swigrun", ...],
>>>>>
>>>>> which gives me the link command arguments I want: 
>>>>> -Lbuild/lib.blahblahblah/PyTrilinons -lswigrun.  However, on my 
>>>>> Mac, when the link command is invoked, I get
>>>>>
>>>>>     ld: can't locate file for: -lswigrun
>>>>>
>>>>> I strongly suspect that the Mac's ld command does not search for 
>>>>> libswigrun.so when -lswigrun is given as a command line argument 
>>>>> (the old system libraries have .la and .dylib extensions).  But I 
>>>>> cannot figure out how to get setup.py to compile to a different 
>>>>> suffix.
>>>>
>>>> You can't do this on OS X.  You can link to two types of files in 
>>>> OS X, static libraries and dylibs.  Python extension modules are 
>>>> bundles (runtime loadable code) and can not be linked to at compile 
>>>> time.  You should either compile swigrun_wrap into every extension, 
>>>> or make it a static library (which is more or less the same thing).
>>> I'm pretty sure I cannot compile swigrun_wrap into every extension 
>>> or make it a static library, since each extension will get its own 
>>> copy and that will defeat the purpose of the runtime libraries.  
>>> Sounds like I need to create a dylib, that python distutils can't 
>>> help me, and that I'll have to learn libtool if I want to make it 
>>> portable.  Does that sound about right?
>>
>> I don't think your assessment of swigrun_wrap is correct.
>
> I base my assessment on a couple of passages from the SWIG manual:
>
>> (15.1) By default, the runtime functions are private to each 
>> SWIG-generated module. That is, the runtime functions are declared 
>> with "static" linkage and are visible only to the wrapper functions 
>> defined in that module. If two completely different SWIG modules are 
>> loaded, this presents no problem---each module uses its own private 
>> runtime code. The only problem with this approach is that when more 
>> than one SWIG module is used in the same application, those modules 
>> often need to share type information. This is especially true for C++ 
>> programs where SWIG must collect and share information about 
>> inheritance relationships that cross module boundaries.

I'm not really sure this applies, try it and see what happens.

>> (15.3) When working with multiple SWIG modules, you should take care 
>> not to use static libraries. For example, if you have a static 
>> library libfoo.a and you link a collection of SWIG modules with that 
>> library, each module will get its own private copy of the library 
>> code inserted into it. This is very often NOT what you want and it 
>> can lead to unexpected or bizarre program behavior. When working with 
>> dynamically loadable modules, you should try to work exclusively with 
>> shared libaries.
>
> I am definitely trying to create multiple modules that need to share 
> type information for inheritance purposes.

It sure sounds as if they're talking about the library you're wrapping, 
not swigrun, in this paragraph.

-bob
From anthony at interlink.com.au  Thu Sep 30 05:04:27 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Thu Sep 30 05:05:38 2004
Subject: [Distutils] Add RPM-friendly Record Option
In-Reply-To: <5.1.1.6.0.20040929134309.02dc6d10@mail.telecommunity.com>
References: <200409280044.34908.symbiont@berlios.de>	<200409280044.34908.symbiont@berlios.de>
	<5.1.1.6.0.20040929134309.02dc6d10@mail.telecommunity.com>
Message-ID: <415B77BB.8040604@interlink.com.au>

Phillip J. Eby wrote:
> Isn't distutils supposed to be compatible with older versions of Python, 
> e.g. 1.5.2?  The list comprehension won't work, and it removes a minor 
> optimization ('if self.root:').

1.5.2 compatibility is so last release. I think it's targetted at 2.1
now (although PEP 291 needs an update).

Anthony
-- 
Anthony Baxter     <anthony@interlink.com.au>
It's never too late to have a happy childhood.
From symbiont at berlios.de  Thu Sep 30 13:05:41 2004
From: symbiont at berlios.de (Jeff Pitman)
Date: Thu Sep 30 13:08:25 2004
Subject: [Distutils] Add RPM-friendly Record Option
In-Reply-To: <5.1.1.6.0.20040929134309.02dc6d10@mail.telecommunity.com>
References: <200409280044.34908.symbiont@berlios.de>
	<5.1.1.6.0.20040929134309.02dc6d10@mail.telecommunity.com>
Message-ID: <200409301905.41922.symbiont@berlios.de>

On Thursday 30 September 2004 01:45, Phillip J. Eby wrote:
> At 11:25 AM 9/29/04 -0600, Sean Reifschneider wrote:
> >On Tue, Sep 28, 2004 at 12:44:34AM +0800, Jeff Pitman wrote:
> > >I'm new here. I submitted a patch for your kind review that spews
> > > out an RPM-consumable list including %dir and %lang attributes. 
> > > The concept could be expanded further.
> >
> >Any comments on this patch?  
>
> Isn't distutils supposed to be compatible with older versions of
> Python, e.g. 1.5.2?  

I used the list comprehension for two reasons:

1) already used in build_py.py 
2) matches what i did in write_record_rpm() (code's cleaner)

> The list comprehension won't work, and it 
> removes a minor optimization ('if self.root:').

I've updated the patch on sf.net to include this opt.

Thanks for taking a look!

take care,
-- 
-jeff
From mutex-request at gmd.de  Thu Sep 30 20:17:39 2004
From: mutex-request at gmd.de (mutex-request@gmd.de)
Date: Thu Sep 30 20:15:21 2004
Subject: [Distutils] Axmwgde dfykujxnz
Message-ID: <200409301815.i8UIF4q27604@homail.ho.lucent.com>

------------------  Virus Warning Message (on the network)

Found virus WORM_MYDOOM.M in file file.exe
The file file.exe is moved to /var/quarantine/virus/virXLY._dvCN.

This is a machine-generated message, please do not reply via e-mail. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770.

---------------------------------------------------------
-------------- next part --------------
The original message was received at Thu, 30 Sep 2004 14:17:39 -0400
from gmd.de [96.5.137.89]

----- The following addresses had permanent fatal errors -----
<distutils-sig@python.org>

----- Transcript of session follows -----
... while talking to host python.org.:
554 5.0.0 Service unavailable; [193.4.76.180] blocked using bl.spamcop.net
Session aborted, reason: lost connection

-------------- next part --------------

------------------  Virus Warning Message (on the network)

file.exe is removed from here because it contains a virus.

---------------------------------------------------------