Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

2.6.1 build issues on solaris with SunStudio 12 #49169

Closed
taverngeek mannequin opened this issue Jan 12, 2009 · 6 comments
Closed

2.6.1 build issues on solaris with SunStudio 12 #49169

taverngeek mannequin opened this issue Jan 12, 2009 · 6 comments
Labels
build The build process and cross-build

Comments

@taverngeek
Copy link
Mannequin

taverngeek mannequin commented Jan 12, 2009

BPO 4919
Nosy @mdickinson
Files
  • unnamed
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = <Date 2010-06-26.14:42:20.417>
created_at = <Date 2009-01-12.09:14:50.266>
labels = ['build']
title = '2.6.1 build issues on solaris with SunStudio 12'
updated_at = <Date 2010-06-26.14:42:20.416>
user = 'https://bugs.python.org/taverngeek'

    bugs.python.org fields:

    activity = <Date 2010-06-26.14:42:20.416>
actor = 'benjamin.peterson'
assignee = 'none'
closed = True
closed_date = <Date 2010-06-26.14:42:20.417>
closer = 'benjamin.peterson'
components = ['Build']
creation = <Date 2009-01-12.09:14:50.266>
creator = 'taverngeek'
dependencies = []
files = ['17777']
hgrepos = []
issue_num = 4919
keywords = []
message_count = 6.0
messages = ['79654', '108195', '108703', '108709', '108710', '108727']
nosy_count = 3.0
nosy_names = ['mark.dickinson', 'taverngeek', 'BreamoreBoy']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue4919'
versions = ['Python 2.6']
    @taverngeek
    Copy link
    Mannequin Author

    taverngeek mannequin commented Jan 12, 2009

    The HUGE_VAL aka infinity issue is solved if the LIB is -lsunmath -lm
    instead of just -lm

    Sun Studio 12 compiler also seems to choke on the PyByteArray_GET_SIZE
    and _AS_STRING because those macros use the ',' operator to stuff an
    assert before the pointer lookup. When I remove the assert portion of
    those macros then they compile fine.

    The assertions in those macros appear a bit silly because some places
    they are used already have prior assertions and I don't see the point of
    the macro which appears to be to crash due to an assertion one statement
    prior to the null pointer reference causing a crash.

    The configure process also appeared to make a few mistakes such as not
    finding uid_t because that is in <sys/types.h> and not in the presumed
    header file. If configure were to include the standard header files AND
    the file that it expects to find the definition then it would be better
    at finding what is defined. I don't know why Sun does that.

    @taverngeek taverngeek mannequin added the build The build process and cross-build label Jan 12, 2009
    @BreamoreBoy
    Copy link
    Mannequin

    BreamoreBoy mannequin commented Jun 19, 2010

    Can this be closed as out of date or is it still an issue with Python 2.7 or any of the Python 3 versions?

    @BreamoreBoy
    Copy link
    Mannequin

    BreamoreBoy mannequin commented Jun 26, 2010

    I got this in an email from the OP.

    "Hi,
    I don't even remember this issue any more, but it seems to me that it is completely irrelevant that the error occurred with software that now how has a newer version.

    That the essential fact is that the configure process makes mistakes creates a situation in which the includes fail to work properly. The only relevance of Python x.x is that version DEMONSTRATES the error.

    The philosophy that the apparent error need not be considered because right now it happens to a possibly obsolete version of software just means it will happen again. Presumably, it will be just another hassle for those that test compile against sunstudio. Using that sort of rationale to close issues is exactly how to make sunstudio into a piece of crap.

    sdw
    "

    Could somebody pick this up?

    @mdickinson
    Copy link
    Member

    The original report isn't very useful; without further constructive feedback from the OP I agree this issue should be closed. For example:

    The HUGE_VAL aka infinity issue is solved if the LIB is -lsunmath -lm
    instead of just -lm

    What is this mysterious 'HUGE_VAL aka infinity' issue---it's not made clear anywhere that I can see? A build failure, I assume (from the title). But at what stage of the build? What's the revelant error message (and surrounding context from the build output)? Exactly how was Python configured and built?

    Is there some context I'm missing, like an attachment containing a build log or something?

    @mdickinson
    Copy link
    Member

    BTW, if there *is* still a problem with building Python 2.6 then closing as 'out of date' wouldn't be appropriate (yet). 2.6 is still receiving bugfixes at this point.

    @taverngeek
    Copy link
    Mannequin Author

    taverngeek mannequin commented Jun 26, 2010

    You all take 7 months to first look at the issue and then decide that you'd
    like more information because the initial submission was incomplete?

    Oh well, Suit yourself. Doesn't matter to me. I've already stopped using
    sunstudio. That python build was one of the last things I did on Solaris
    which I had been actively using for 20 years, but some device driver issues
    have made it no longer worth the effort.

    sdw

    On Sat, Jun 26, 2010 at 4:39 AM, Mark Lawrence <report@bugs.python.org>wrote:

    Mark Lawrence <breamoreboy@yahoo.co.uk> added the comment:

    I got this in an email from the OP.

    "Hi,
    I don't even remember this issue any more, but it seems to me that it is
    completely irrelevant that the error occurred with software that now how has
    a newer version.

    That the essential fact is that the configure process makes mistakes
    creates a situation in which the includes fail to work properly. The only
    relevance of Python x.x is that version DEMONSTRATES the error.

    The philosophy that the apparent error need not be considered because right
    now it happens to a possibly obsolete version of software just means it will
    happen again. Presumably, it will be just another hassle for those that
    test compile against sunstudio. Using that sort of rationale to close
    issues is exactly how to make sunstudio into a piece of crap.

    sdw
    "

    Could somebody pick this up?

    ----------

    Python tracker <report@bugs.python.org>
    <http://bugs.python.org/issue4919\>

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    build The build process and cross-build
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    2 participants
    @benjaminp @mdickinson