[issue23895] [PATCH] python socket module fails to build on Solaris when -zignore is in LDFLAGS

2015-11-17 Thread Andrew Stormont
Changes by Andrew Stormont : -- title: python socket module fails to build on Solaris when -zignore is in LDFLAGS -> [PATCH] python socket module fails to build on Solaris when -zignore is in LDFLAGS ___ Python tracker <http://bugs.pyth

[issue23895] python socket module fails to build on Solaris when -zignore is in LDFLAGS

2015-11-17 Thread Andrew Stormont
Andrew Stormont added the comment: Bump. -- status: open -> languishing ___ Python tracker <http://bugs.python.org/issue23895> ___ ___ Python-bugs-list mai

[issue23895] python socket module fails to build on Solaris when -zignore is in LDFLAGS

2015-06-15 Thread Andrew Stormont
Andrew Stormont added the comment: Bump. -- ___ Python tracker <http://bugs.python.org/issue23895> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23895] python socket module fails to build on Solaris when -zignore is in LDFLAGS

2015-05-28 Thread Andrew Stormont
Andrew Stormont added the comment: The -z ignore option is actually exposing issues that could cause a problem at runtime. If the socket module were imported and libsocket/libnsl hadn't already been loaded (i.e pulled in by the loader as a dependency of another module) the loader would

[issue23895] PATCH: python socket module fails to build on Solaris when -zignore is in LDFLAGS

2015-05-12 Thread Andrew Stormont
Andrew Stormont added the comment: Bump. Would be nice to get this included in python 2.7.11. I also have a similar fix for the multiprocessing module but I won't bother submitting it if it will get ignored. -- status: open -> lan

[issue23895] PATCH: python socket module fails to build on Solaris when -zignore is in LDFLAGS

2015-04-09 Thread Andrew Stormont
New submission from Andrew Stormont: The socket module fails to build when -zignore is in LDFLAGS. This option changes the linker behaviour so it will only resolve against the libraries linked in explicitly instead of doing resolution recursively against their dependencies too

[issue17925] asynchat.async_chat.initiate_send : del deque[0] is not safe

2013-06-13 Thread Andrew Stormont
Andrew Stormont added the comment: I think you mean: self.producer_fifo.extendleft([data, first]) Instead of: self.producer_fifo.extendleft([first, data]) No? -- ___ Python tracker <http://bugs.python.org/issue17

[issue17925] asynchat.async_chat.initiate_send : del deque[0] is not safe

2013-06-03 Thread Andrew Stormont
Andrew Stormont added the comment: Great. Everybody's happy now, surely? -- ___ Python tracker <http://bugs.python.org/issue17925> ___ ___ Python-bugs-list m

[issue17925] asynchat.async_chat.initiate_send : del deque[0] is not safe

2013-05-29 Thread Andrew Stormont
Andrew Stormont added the comment: What about changing: self.producer_fifo.appendleft(first) self.producer_fifo.appendleft(data) To self.producer_fifo.extendleft([data, first]) Assuming deque's extendleft is actually thread safe. -- ___ P

[issue17925] asynchat.async_chat.initiate_send : del deque[0] is not safe

2013-05-28 Thread Andrew Stormont
Andrew Stormont added the comment: Looks like a reasonable fix to me. What needs to be done to get this integrated? -- nosy: +andy_js ___ Python tracker <http://bugs.python.org/issue17