SO_REUSEPORT is not defined for some linux targets

[pinskia]

Forwarded from https://gcc.gnu.org/PR118438.

The following targets seems to be missing a definition of SO_REUSEPORT from core/sys/posix/sys/socket.d :
s390*-linux-gnu loongarch64-linux-gnu hppa*-linux-gnu mips*-linux-gnu sparc*-*-linux-gnu

This definition is now needed to compile libphobos/src/std/socket.d too.

[pinskia]

Note libphobos change which introduced this depedency is dlang/phobos@9aa794c

[thewilsonator]

There are existing version branches for HPPA, LoongArch64, MIPS and SPARC in https://github.com/dlang/dmd/blob/caf0e12e0c220be042b73d12a8843d2d5e66f661/druntime/src/core/sys/posix/sys/socket.d that do indeed lack a definition of SO_REUSEPORT.

I'm guessing that s390 is SystemZ and also has a branch that lacks that definition.

If you could point me to where those values are defined in the system's headers I can put a PR together, or if you would like to do that yourself, a PR to the stable branch of this repository would be appreciated.

[thewilsonator]

also cc @ibuclaw for forwarding this to GDC/GCC

[pinskia]

also cc @ibuclaw for forwarding this to GDC/GCC

This bug report was originally forwarded from GCC/GDC in the first place :)

[ibuclaw]

If you could point me to where those values are defined in the system's headers I can put a PR together, or if you would like to do that yourself, a PR to the stable branch of this repository would be appreciated.

You'd have to look in the Linux source code.

https://github.com/search?q=repo%3Atorvalds%2Flinux+SO_REUSEPORT+language%3AC+path%3A**%2Fsocket.h

[thewilsonator]

This bug report was originally forwarded from GCC/GDC in the first place :)

Bad wording on my part, I meant the resultant PR to fix the issue.

[ibuclaw]

If you could point me to where those values are defined in the system's headers I can put a PR together, or if you would like to do that yourself, a PR to the stable branch of this repository would be appreciated.

You'd have to look in the Linux source code.

https://github.com/search?q=repo%3Atorvalds%2Flinux+SO_REUSEPORT+language%3AC+path%3A**%2Fsocket.h

tl;dr

Alpha => 0x0200 (though, no D compiler support code for that target)
HPPA_Any => 0x200
MIPS_Any => 0x200
SPARC_Any => 0x200
Everything else => 15

There are existing version branches for HPPA, LoongArch64, MIPS and SPARC in https://github.com/dlang/dmd/blob/caf0e12e0c220be042b73d12a8843d2d5e66f661/druntime/src/core/sys/posix/sys/socket.d that do indeed lack a definition of SO_REUSEPORT.

It's also missing at the top:

version (HPPA64)  version = HPPA_Any;

[ibuclaw]

a PR to the stable branch of this repository would be appreciated.

FWIW, this only affects master.

[thewilsonator]

SPARC_Any => 0x200

It seems that all of the current SPARC ones are wrong. Druntime seems to assume that SPARC uses[uapi/asm-generic/socket.h](https://github.com/torvalds/linux/blob/5bc55a333a2f7316b58edc7573e8e893f7acb532/include/uapi/asm-generic/socket.h#L27) (with SO_REUSEPORT = 15;) Could you please verify that.

[thewilsonator]

#20689

[ibuclaw]

SPARC_Any => 0x200

It seems that all of the current SPARC ones are wrong. Druntime seems to assume that SPARC uses[uapi/asm-generic/socket.h](https://github.com/torvalds/linux/blob/5bc55a333a2f7316b58edc7573e8e893f7acb532/include/uapi/asm-generic/socket.h#L27) (with SO_REUSEPORT = 15;) Could you please verify that.

Maybe you're mixing up SPARC and PPC?

[thewilsonator]

Yes and no. I think I put it in the wrong place in the PR but
arch/sparc/include/uapi/asm/socket.h

#define SO_PEERCRED	0x0040
#define SO_LINGER	0x0080
#define SO_OOBINLINE	0x0100
#define SO_REUSEPORT	0x0200
#define SO_BSDCOMPAT    0x0400
#define SO_RCVLOWAT     0x0800
#define SO_SNDLOWAT     0x1000

https://github.com/dlang/dmd/blob/master/druntime/src/core/sys/posix/sys/socket.d#L463-L496

[ibuclaw]

Right, those are indeed all wrong. I was tempted to know who wrote this, but of course it's me. :-)

dlang/druntime@0e1ee40

[thewilsonator]

Right, those are indeed all wrong.

#20690

I was tempted to know who wrote this, but of course it's me. :-)

Its always the person you suspect most ;)