This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: distutils should zap .o as well as .so
Type: Stage:
Components: Distutils Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: fdrake Nosy List: akuchling, fdrake, gvanrossum, python-dev, skip.montanaro
Priority: normal Keywords:

Created on 2001-09-04 11:26 by skip.montanaro, last changed 2022-04-10 16:04 by admin. This issue is now closed.

Messages (7)
msg6328 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2001-09-04 11:26
Just rebuilt from CVS and got this toward the end:

  skipping 'pyexpat' extension (up-to-date)
  WARNING: removing "pyexpat" since importing it failed

It would have been nice to know why the import failed.
Also, instead of just deleting the .so file it should
delete the .o file as well.  In this case, deleting the
.o file to force recompilation instead of just
relinking solved the problem.
msg6329 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2001-09-04 19:46
Logged In: YES 
user_id=11375

I'm not clear on the problem here; what did you use to 
clean up *.so files that didn't clean up *.o files?  "make 
clean" runs rm `find -name *.o`, and "python setup.py 
clean" blows away an entire directory under build/, so 
both of those seem to be correct.  What were you using?

msg6330 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2001-09-04 20:20
Logged In: YES 
user_id=44345

> what did you use to clean up *.so files that didn't clean
> up *.o files?

The usual:

    cvs up .
    cd build
    ../configure
    make

Maybe this won't be a problem for people who routinely
download tarballs and build afresh, but when working from
CVS it doesn't seem to me like I should always need to "make
clean", presuming the make dependencies are done right.

The only thing I'm suggesting is that if distutils performs
an import to see if the newly built .so file is okay and
finds that it isn't, it should delete both the .so file and
the .o file from which it was built.  The message it emits
indicates that it is already zapping the .so file.

Skip

msg6331 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-09-04 20:57
Logged In: YES 
user_id=6380

> when working from
> CVS it doesn't seem to me like I should always need
> to "make  clean",
> presuming the make dependencies are done right.

Unfortunately, setup doen't honor dependencies, and when a
header file has changed that affects the extensions, you
have to manually remove the build subdirectory (I do "rm -rf
build" :-) to get this to work.

I wish that this could be fixed too.
msg6332 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2001-09-05 03:41
Logged In: YES 
user_id=44345

> Unfortunately, setup doen't honor dependencies, ...

While Distutils is a very clever piece of software, I have
always had this sneaking suspicion that it was trying to do
too much, subsuming some or all of the roles of make,
autoconf, libtool, etc.  In this particular case, the more I
think about it, the more I think it has to delete the .o
file.  When import of the .so fails, setup.py has no idea
why it failed, just that something's amiss.  It might have
been overly aggressive compiler switches, missing shared
libraries, or other things, so to be on the safe side it
should delete the .so file and any .o files that were
compiled to create the module that failed to load. 

The GNU build tools have progressed quite a way in the past
couple years, including improvements in portability (I
believe some or all of them will run on Windows now, at
least in certain configurations, like cygwin).  While their
output can be hell to debug, they do a much more complete
job of dependency analysis than setup.py.

msg6333 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2001-12-06 23:01
Logged In: YES 
user_id=3066

The resolution should read "Fixed, painfully."

I've checked in a hackish solution as setup.py 1.69 and
Lib/distutils/command/build_ext.py 1.77.
msg227901 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-09-30 12:58
New changeset 94af1af93670 by Antoine Pitrou in branch 'default':
Remove pointless "vile hack" that can cause the build step to fail when some extension modules can't be imported.
https://hg.python.org/cpython/rev/94af1af93670
History
Date User Action Args
2022-04-10 16:04:24adminsetgithub: 35100
2014-09-30 12:58:50python-devsetnosy: + python-dev
messages: + msg227901
2001-09-04 11:26:32skip.montanarocreate