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: install fails if build .so fails
Type: Stage:
Components: Distutils Versions: Python 2.2
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: nnorwitz Nosy List: loewis, mwh, nnorwitz, nobody
Priority: normal Keywords:

Created on 2002-03-20 18:09 by nnorwitz, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
t nnorwitz, 2002-03-20 18:09 full exception and patch
setup-patch nnorwitz, 2002-03-21 01:51 patch to setup.py to fix problem installing when .so module fails to work
Messages (11)
msg9800 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2002-03-20 18:09
This is when using purify, fpectl.so fails to build.
After this an exception is raised in distutils.

Here's some of the interesting bits.

The attached file should have everyhing:

Instrumenting: fpectl.so Done.
WARNING: removing "fpectl" since importing it failed
Traceback (most recent call last):
  File "./setup.py", line 796, in ?
    main()
  File "./setup.py", line 790, in main
    scripts = ['Tools/scripts/pydoc']
...
  File
"/space/purify/python/python/dist/2.2/Lib/distutils/cmd.py",
line 107, in __getattr__
    raise AttributeError, attr
AttributeError: _built_objects

In order to get this far, I also had to include this
patch to Python/dynload_shlib.c:93:


<    PyErr_SetString(PyExc_ImportError, dlerror());
---
>    const char* err = dlerror();
>    if (! err)
>        err = "";
>    PyErr_SetString(PyExc_ImportError, err);

This patch should not be applied.  It's just necessary
for purify, AFAIK.

This problem can be duplicated outside of purify with
the following steps (on Linux):

    configure
    make
    # stop make after fpectl.o
    chmod 000 build/*/fpe*
    make
    # exception should be raised

Purify version is 2002a.06.00 Proto 38 on 
Solaris 8/Sparc.
msg9801 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-03-20 18:45
Logged In: YES 
user_id=21627

I got crashes from loading fpectl.so, too. It seems to be
related to #530163: does the problem go away if you link
with -lsunmath?

This appears to be a duplicate of #472642, so I'm resolving
it tentatively as such. Unless further information is
expected, I recommend to close this report.

msg9802 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2002-03-20 19:07
Logged In: YES 
user_id=33168

Actually the bug report was more about the distutils
problem.  It should not be specific to fpectl, although
that was the problem when I noticed it.

Distutils will presumably always raise an exception if it
cannot open a dynamic library.

Also, in 530163 there is mention of -lsunmath, 
I cannot find any sunmath or ieee library on solaris.
The other report was for solaris 7, where this is solaris 8.
There is an ieee_handlers in -lc.
msg9803 - (view) Author: Nobody/Anonymous (nobody) Date: 2002-03-21 00:08
Logged In: NO 

for me, -lsunmath is in /opt/SUNWspro/lib. I don't
believe we have the sun compilers.

(Anthony here - stupid sf keeps telling me to log back
in)
msg9804 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2002-03-21 01:06
Logged In: YES 
user_id=33168

I don't have the directory /opt/SUNWspro.
I did a:  find /opt -name '*sunmath*' -print
and got nothing.  Also looked for *ieee*,
nm /usr/lib/lib*.a also yields nothing.

But there is fpsetmask() now.  And there's 
#include <floatingpoint.h> or <sys/ieeefp.h>
I think the code needs to be rewritten, but I'm
not sure what to do.  I think the whole code in
#ifdef sun, should be something like this (for solaris 8 only):

    #include <floatingpoint.h>
    sigfpe(FPE_FLTOVF, handler);
    sigfpe(FPE_FLTDIV, handler);
    sigfpe(FPE_FLTUBV, handler);

or

    #include <ieeefp.h>
    fpsetmask(FP_X_INV | FP_X_OFL | FP_X_DZ);   
PyOS_setsig(SIGFPE, handler);

But that's a guess from the man pages.
Are there any tests for fpectl?
msg9805 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2002-03-21 01:51
Logged In: YES 
user_id=33168

Ok, I did a little more searching and found the problem.
There is a generic problem with dist/src/setup.py.
I can't say I completely understand it, but the
attached patch fixes the problem.

This patch should also fix bug # 517704 :
http://sourceforge.net/tracker/index.php?func=detail&aid=517704&group_id=5470&atid=105470
At certain points, if a build fails, install will
also fail.
msg9806 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-03-21 09:16
Logged In: YES 
user_id=21627

SUNWspro is the unbundled compiler, an optional payware
package, see

http://www.sun.com/forte/cplusplus/index.html

If you don't have it, you can't find it :-)

I believe this package is the only way to obtain
libsunmath.so (it's actually SPROsmsx), and that libsunmath
is required for proper operation of fpectl on Solaris.

So if libsunmath is not found, this module should not be built.
msg9807 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2002-03-25 12:46
Logged In: YES 
user_id=33168

Changed the subject to more closely describe the problem.
The patch may be more treating the symptom, but I don't know
distutils well enough to know.  There is a big comment which
immediately above the code which seems related, but I'm not
sure how.

I think this patch (or another which fixes the problem)
should be applied to 2.2.1.  Note the problem is not
specific to any particular library or OS.

I'll try to get fpectl to work on Solaris 8, but that is a
different subject to the build/install failure which is the
problem addressed by the patch.
msg9808 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-03-25 13:56
Logged In: YES 
user_id=21627

The patch to setup.py itself is fine (although I'm not sure
what the Carbon chunk is doing there). It is not quite clear
to me why it is needed, though: When fpectl.so was first
built, an import was attempted. That import must have
succeeded, or else the built_objects would have been
removed, and 'make install' would have rebuilt them again.

One scenario where this can go wrong is that  Python crashes
during import of the extension module, in which case the
extension remains there, but is not built again. So assuming
something like that happened to you, please apply the patch.
msg9809 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2002-03-25 14:00
Logged In: YES 
user_id=6656

Hokay, checked in as revision 1.73.4.3 of setup.py.
msg9810 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2002-03-25 14:24
Logged In: YES 
user_id=33168

Checked in as setup.py 1.85 and 1.73.4.3.
The Carbon chunk was fixing whitespace.
It should not have been in the patch, but I didn't
notice until after your comment and Michaels checkin.
History
Date User Action Args
2022-04-10 16:05:07adminsetgithub: 36290
2002-03-20 18:09:47nnorwitzcreate