Declare sethostname in socketmodule.c for SOLARIS

[r-bit-rry]

BPO	34288
Nosy	@r-bit-rry, @johngh

^{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

• gh-78469: Declare missing sethostname for Solaris 10 #109447
• [3.12] gh-78469: Declare missing sethostname for Solaris 10 (GH-109447) #110580
• [3.11] gh-78469: Declare missing sethostname for Solaris 10 (GH-109447) #110581

[r-bit-rry]

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]

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]

@kulikjak: In PR #108817 we did the opposite, remove gethostname() prototype. Is this issue about sethostname() still relevant in 2023 on Solaris?

[kulikjak]

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]

Can't you test the Solaris version in the preprocessor (#ifdef)? Feel free to propose a PR.

[kulikjak]

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]

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]

I looked into it and prepared #109447 - I was worried that more would be necessary, but I think it worked out pretty well.