GeezerVison is showing github.com — Declare sethostname in socketmodule.c for SOLARIS · Issue #78469 · python/cpython
Declare sethostname in socketmodule.c for SOLARIS #78469Description
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 = None
created_at = <Date 2018-07-31.07:32:32.085>
labels = ['build', '3.7']
title = 'Declare sethostname in socketmodule.c for SOLARIS'
updated_at = <Date 2019-05-15.15:53:46.806>
user = 'https://github.com/r-bit-rry' bugs.python.org fields:
activity = <Date 2019-05-15.15:53:46.806>
actor = 'John Harrison'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Build']
creation = <Date 2018-07-31.07:32:32.085>
creator = 'rbelio'
dependencies = []
files = []
hgrepos = []
issue_num = 34288
keywords = []
message_count = 2.0
messages = ['322742', '342581']
nosy_count = 2.0
nosy_names = ['rbelio', 'John Harrison']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue34288'
versions = ['Python 3.7'] Linked PRs
Activityr-bit-rry commented on Jul 31, 2018 MannequinAuthor More actions Following issue 18259 which was solved by extern sethostname I managed to build python 3.7 on solaris only after patching away the ifdef for _AIX.
We need to add SOLARIS flag and check for that also in the same line of
#ifdef _AIX. This error only appears in 3.7 since a new CFLAG was turned on -Werror=no-implicit-declaration. and during build time it fails on sethostname function, not build _socket. johngh commented on May 15, 2019 On Solaris 10 i386 I successfully built _socket on 3.7.3 by patching *in* a Solaris test (by cloning the test for the INET_ADDRSTRLEN definition currently on line 268) rather than by patching away the _AIX ifdef
$ diff -u ../socketmodule.c Modules/socketmodule.c
--- ../socketmodule.c Wed May 15 16:36:32 2019
+++ Modules/socketmodule.c Wed May 15 15:34:50 2019
@@ -5212,6 +5212,10 @@
extern int sethostname(const char *, size_t);
#endif +#if (defined(__sun) && defined(__SVR4))
+extern int sethostname(const char *, size_t);
+#endif
+
if (!PyArg_ParseTuple(args, "S:sethostname", &hnobj)) {
PyErr_Clear();
if (!PyArg_ParseTuple(args, "O&:sethostname",vstinner commented on Sep 7, 2023 @kulikjak: In PR #108817 we did the opposite, remove gethostname() prototype. Is this issue about sethostname() still relevant in 2023 on Solaris? kulikjak commented on Sep 14, 2023 Hi, since this is reported in Solaris 10 (which is before Solaris was first opened, so only Sun/Oracle is affected here), I had to dive into history a little bit.
gethostname is available in Solaris 10 header files (at least in reasonably recent one), so no problem there.sethostname is indeed missing from Solaris 10 headers (and wasn't even available in Solaris 11 since the beginning illumos/illumos-gate@eec1faa - though that was fixed 17 years ago so we don't have to worry about that...)
I don't think it's a secret that we don't plan to release any new official Python 3.x package for Solaris 10 (which is in the extended support stage intended for critical fixes only), so this is not relevant to us. But that also means that those still using it might want to build newer Python for it themselves.
What's unfortunate is that simply adding the definition would cause at least redefinition warnings on current Solaris. vstinner commented on Sep 14, 2023 Can't you test the Solaris version in the preprocessor (#ifdef)? Feel free to propose a PR. kulikjak commented on Sep 14, 2023 Developer Studio compiler provides handy macros like __SunOS_5_10, but sadly, GCC doesn't.
I guess I can define something like that via configure with uname -r, though. Then it would be simple a #ifdef. vstinner commented on Sep 14, 2023
I guess I can define something like that via configure with uname -r, though. Then it would be simple a #ifdef.
Yeah, that should be good enough. kulikjak commented on Sep 15, 2023 I looked into it and prepared #109447 - I was worried that more would be necessary, but I think it worked out pretty well. erlend-aasland commented on Oct 10, 2023 Thanks for the report, @r-bit-rry, and thanks for the fix, @kulikjak, and thanks for the review, @vstinner.
Marking this as resolved; the backports are approved and queued for merging.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|