Patch proposition for socket.pp problem under openbsd (gitlab ticket #38188) lazarus / 38-Networking and Web Programming ---------------------------------------------------------------------- BSaidus · 2026-03-22 18:00 Hello. After, many tests, root cause identified: OpenBSD sockaddr_in ABI requires: * sin_len : byte * sin_family : byte Current RTL TInetSockAddr uses Linux-style layout: sin_family : word This shifts sockaddr fields and causes bind() to fail with errno 47 (EAFNOSUPPORT). Adding packed record OpenBSD layout + sin_len initialization fixes fpBind(). this is a patch Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i diff --git a/rtl/unix/sockets.pp b/rtl/unix/sockets.ppindex XXXXXXX..YYYYYYY 100644--- a/rtl/unix/sockets.pp+++ b/rtl/unix/sockets.pp@@ -120,11 +120,20 @@ type   in_addr = record     s_addr : cuint32;   end; +{$ifdef openbsd}+  TInetSockAddr = packed record+    sin_len    : byte;+    sin_family : byte;+    sin_port   : word;+    sin_addr   : in_addr;+    sin_zero   : array[0..7] of char;+  end;+{$else}   TInetSockAddr = packed record     sin_family : word;     sin_port   : word;     sin_addr   : in_addr;     sin_zero   : array[0..7] of char;   end;+{$endif}  and Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i diff --git a/rtl/unix/syssocket.inc b/rtl/unix/syssocket.incindex XXXXXXX..YYYYYYY 100644--- a/rtl/unix/syssocket.inc+++ b/rtl/unix/syssocket.inc@@ -45,6 +45,10 @@ FillChar(addr, SizeOf(addr), 0); +{$ifdef openbsd}+addr.sin_len := SizeOf(addr);+{$endif}+ addr.sin_family := AF_INET; addr.sin_port := htons(port);  This apply for FPC 3.2.X Thanks. PS: i can not submit on gitlab. ---------------------------------------------------------------------- BSaidus · 2026-03-22 18:30 Quote from: BSaidus on March 22, 2026, 07:00:45 pmHello. After, many tests, root cause identified: OpenBSD sockaddr_in ABI requires: * sin_len : byte * sin_family : byte Current RTL TInetSockAddr uses Linux-style layout: sin_family : word This shifts sockaddr fields and causes bind() to fail with errno 47 (EAFNOSUPPORT). Adding packed record OpenBSD layout + sin_len initialization fixes fpBind(). this is a patch Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i diff --git a/rtl/unix/sockets.pp b/rtl/unix/sockets.ppindex XXXXXXX..YYYYYYY 100644--- a/rtl/unix/sockets.pp+++ b/rtl/unix/sockets.pp@@ -120,11 +120,20 @@ type   in_addr = record     s_addr : cuint32;   end; +{$ifdef openbsd}+  TInetSockAddr = packed record+    sin_len    : byte;+    sin_family : byte;+    sin_port   : word;+    sin_addr   : in_addr;+    sin_zero   : array[0..7] of char;+  end;+{$else}   TInetSockAddr = packed record     sin_family : word;     sin_port   : word;     sin_addr   : in_addr;     sin_zero   : array[0..7] of char;   end;+{$endif}  and Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i diff --git a/rtl/unix/syssocket.inc b/rtl/unix/syssocket.incindex XXXXXXX..YYYYYYY 100644--- a/rtl/unix/syssocket.inc+++ b/rtl/unix/syssocket.inc@@ -45,6 +45,10 @@ FillChar(addr, SizeOf(addr), 0); +{$ifdef openbsd}+addr.sin_len := SizeOf(addr);+{$endif}+ addr.sin_family := AF_INET; addr.sin_port := htons(port);  This apply for FPC 3.2.X Thanks. PS: i can not submit on gitlab. I think that the correction exists on my FPC v: 3.2.4-rc1-d3a5f442 [2025/11/27] Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i   TInetSockAddr = sockaddr_in;  PInetSockAddr = psockaddr_in;   psockaddr = ^sockaddr;  sockaddr = packed record // if sa_len is defined, sa_family_t is smaller  {$ifdef SOCK_HAS_SINLEN}     sa_len   : cuchar;  {$endif}    case integer of      0: (sa_family: sa_family_t;          sa_data: packed array[0..13] of cuint8);      1: (sin_family: sa_family_t;          sin_port: cushort;          sin_addr: in_addr;          sin_zero: packed array[0..7] of cuint8);  end;   TSockAddr = sockaddr; I think we need just to define SOCK_HAS_SINLEN for BSD's systems while compiling packages. ---------------------------------------------------------------------- marcov · 2026-03-22 20:09 Sockets.pp has Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i {$if     defined(FreeBSD) or     defined(Darwin) or     defined(Haiku)}{$DEFINE SOCK_HAS_SINLEN}               // BSD definition of socketaddr{$endif} [/code] ---------------------------------------------------------------------- BSaidus · 2026-03-22 20:34 Why it do not works then, When I cross compile from Windows To OpenBSD, it fail on 'bind' and return Error 47. I think we should add OpenBSD to defines. ---------------------------------------------------------------------- marcov · 2026-03-22 20:49 If you add it, does it work ? Then I'll commit it. ---------------------------------------------------------------------- BSaidus · 2026-03-22 21:04 I'll give you feedback as soon I compile. ---------------------------------------------------------------------- BSaidus · 2026-03-22 21:24 Yes, you can commit. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  {$if     defined(FreeBSD) or     defined(Darwin) or     defined(Haiku) or     defined(OpenBSD) }{$DEFINE SOCK_HAS_SINLEN}               // BSD definition of socketaddr{$endif}   PS: Please, If you can, commit to branch 3.2.X also. ---------------------------------------------------------------------- Fred vS · 2026-03-22 21:55 Quote from: BSaidus on March 22, 2026, 07:00:45 pmthis is a patch Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i diff --git a/rtl/unix/sockets.pp b/rtl/unix/sockets.pp...  Hello BSaidus. I suppose that this patch is not for fpc 3.2.x because sockets.pp is in fpc/packages/rtl-extra/src/unix/sockets.pp. ---------------------------------------------------------------------- BSaidus · 2026-03-22 22:12 @Fred VS, Yes Now it is in '.\fpcsrc\packages\rtl-extra\src\unix\', I think I was mistake  . ---------------------------------------------------------------------- Fred vS · 2026-03-22 22:20 Ha ok, thanks. Other thing: QuoteI think that the correction exists on my FPC v: 3.2.4-rc1-d3a5f442 [2025/11/27] Hum, I dont see that commit in https://gitlab.com/freepascal.org/fpc/s ource/-/tree/release_3_2_4-branch/packages/rtl- extra/src/unix/sockets.pp. Where do you get it? ---------------------------------------------------------------------- BSaidus · 2026-03-23 06:58 Quote from: Fred vS on March 22, 2026, 11:20:14 pmHa ok, thanks. Other thing: QuoteI think that the correction exists on my FPC v: 3.2.4-rc1-d3a5f442 [2025/11/27] Hum, I dont see that commit in https://gitlab.com/freepascal.org/fpc/s ource/-/tree/release_3_2_4-branch/packages/rtl- extra/src/unix/sockets.pp. Where do you get it? I mean, the '$if defined' exists but without OpenBSD, so I added it & recompiled. ---------------------------------------------------------------------- marcov · 2026-03-23 08:07 Quote from: BSaidus on March 22, 2026, 10:24:38 pmPS: Please, If you can, commit to branch 3.2.X also. 3.2.x is frozen in anticipation for 3.2.4 for already for an year. But I keep lists and if there are opportunities I'll try to merge. p.s. if the openbsd pkg/ports system has a way to have OS specific patches over the release, this might be a candidate ---------------------------------------------------------------------- abouchez · 2026-03-25 11:26 I guess all this started with https://github.com/synopse/mORMot2/issues/447 I have implemented a corresponding patch in mormot.net.sock.posix.inc: https://github.com/synopse/mORMot2/commit/5a3540fd8 In fact, I re-defined all those records, and properly populate the sa_len field on BSD. It seems that FreeBSD and Darwin allow sa_len = 0 and assume it means "this is the correct length". But OpenBSD is more strict, and requires the proper length in bytes to be set in this sa_len field. So 1) FPC needs to be patched to define SOCK_HAS_SINLEN conditional on OpenBSD 2) User code needs to populate the sa_len field properly Both are now done automagically by the mORMot socket wrapper, which will work with old FPC versions - not only the trunk. And by the way, I am currently preparing Delphi for Linux compiler support, so I needed those records definition anyway. ---------------------------------------------------------------------- Fred vS · 2026-03-25 12:08 Quote from: abouchez on March 25, 2026, 12:26:46 pmI guess all this started with https://github.com/synopse/mORMot2/issues/447 I have implemented a corresponding patch in mormot.net.sock.posix.inc: https://github.com/synopse/mORMot2/commit/5a3540fd8 In fact, I re-defined all those records, and properly populate the sa_len field on BSD. It seems that FreeBSD and Darwin allow sa_len = 0 and assume it means "this is the correct length". But OpenBSD is more strict, and requires the proper length in bytes to be set in this sa_len field. So 1) FPC needs to be patched to define SOCK_HAS_SINLEN conditional on OpenBSD 2) User code needs to populate the sa_len field properly Both are now done automagically by the mORMot socket wrapper, which will work with old FPC versions - not only the trunk. And by the way, I am currently preparing Delphi for Linux compiler support, so I needed those records definition anyway. Note also that OpenBSD use a custom libc.so.xxx for each new release (unlike other Unix OS who use always libc.so.6). So a fpc binary release is needed for each OpenBSD release. You may use a fpc 3.2.4 release for OpenBSD 7.4, 7.5, 7.6, 7.7, 7.8 from here. ---------------------------------------------------------------------- BSaidus · 2026-04-02 07:44 Quote from: Fred vS on March 25, 2026, 01:08:28 pmQuote from: abouchez on March 25, 2026, 12:26:46 pmI guess all this started with https://github.com/synopse/mORMot2/issues/447 I have implemented a corresponding patch in mormot.net.sock.posix.inc: https://github.com/synopse/mORMot2/commit/5a3540fd8 In fact, I re-defined all those records, and properly populate the sa_len field on BSD. It seems that FreeBSD and Darwin allow sa_len = 0 and assume it means "this is the correct length". But OpenBSD is more strict, and requires the proper length in bytes to be set in this sa_len field. So 1) FPC needs to be patched to define SOCK_HAS_SINLEN conditional on OpenBSD 2) User code needs to populate the sa_len field properly Both are now done automagically by the mORMot socket wrapper, which will work with old FPC versions - not only the trunk. And by the way, I am currently preparing Delphi for Linux compiler support, so I needed those records definition anyway. Note also that OpenBSD use a custom libc.so.xxx for each new release (unlike other Unix OS who use always libc.so.6). So a fpc binary release is needed for each OpenBSD release. You may use a fpc 3.2.4 release for OpenBSD 7.4, 7.5, 7.6, 7.7, 7.8 from here. Yep, but for me the code works & I create a symlink to libc as needed by the program. ---------------------------------------------------------------------- Fred vS · 2026-04-02 10:27 Quote from: BSaidus on April 02, 2026, 09:44:06 amYep, but for me the code works & I create a symlink to libc as needed by the program. Yes, but that's not allowed in my "out-of-the-box" religion. ---------------------------------------------------------------------- marcov · 2026-04-02 10:36 Doesn't OpenBSD have a compat system for older releases? ---------------------------------------------------------------------- Fred vS · 2026-04-02 11:03 Quote from: marcov on April 02, 2026, 12:36:23 pmDoesn't OpenBSD have a compat system for older releases? No, sadly OpenBSD does not use the fabulous ELF Symbol Versioning like glibc on Linux. Instead, it uses a more traditional Major.Minor library versioning scheme without any compat system for "security" reason (?). ---------------------------------------------------------------------- marcov · 2026-04-02 11:23 Quote from: Fred vS on April 02, 2026, 01:03:25 pmQuote from: marcov on April 02, 2026, 12:36:23 pmDoesn't OpenBSD have a compat system for older releases? No, sadly OpenBSD does not use the fabulous ELF Symbol Versioning like glibc on Linux. BSD Compat systems are not the same as ELF symbol versioning. COMPAT assigns different library directories (and I assume dynlinker too) based on OS and version in the ELF ident.  FreeBSD can run linux binaries that way, as well as versions for older major versions. ---------------------------------------------------------------------- Fred vS · 2026-04-02 11:54 Quote from: marcov on April 02, 2026, 01:23:55 pmQuote from: Fred vS on April 02, 2026, 01:03:25 pmQuote from: marcov on April 02, 2026, 12:36:23 pmDoesn't OpenBSD have a compat system for older releases? No, sadly OpenBSD does not use the fabulous ELF Symbol Versioning like glibc on Linux. BSD Compat systems are not the same as ELF symbol versioning. COMPAT assigns different library directories (and I assume dynlinker too) based on OS and version in the ELF ident.  FreeBSD can run linux binaries that way, as well as versions for older major versions. Our best friend Gemini AI says: Q: Doesn't OpenBSD have a compat system for older releases? A: No OpenBSD does not have a formal compatibility system or binary compatibility layer for its own older releases. Unlike FreeBSD or NetBSD, which have historically maintained "compat" libraries to run binaries from previous versions, OpenBSD's policy generally prioritizes security and code cleanliness over long-term ABI (Application Binary Interface) stability. Why OpenBSD Lacks "Compat"Volatile ABI: OpenBSD often changes kernel structures and system calls between releases to improve security or performance. This frequently breaks binary compatibility with older versions.Security Policy: Running old, unpatched, or "insecure" binaries is discouraged by the project's design philosophy.Static vs. Dynamic: While some statically linked binaries might continue to work across a few releases if they don't touch changed kernel interfaces, this is considered "luck" rather than a supported feature. How to Handle Older Software. Since there is no built-in compatibility layer, you generally have two options:Recompile from Source: The standard practice is to rebuild your software on the current release. While the ABI changes often, the userland C API is significantly more stable, meaning code often compiles with minimal changes.Stay on Older Releases: If you must run a specific old binary, you usually have to keep the entire OS at that version. Note that OpenBSD only officially supports the current release and the one immediately preceding it. ---------------------------------------------------------------------- Fred vS · 2026-04-02 12:31 To summarize, regarding FPC release on OpenBSD, the only "legal" solution is to offer an FPC version per OpenBSD version. IMHO, of course. ---------------------------------------------------------------------- marcov · 2026-04-02 12:38 Quote from: Fred vS on April 02, 2026, 01:54:45 pmOur best friend Gemini AI says: Yes, that is about the same as I remember, and one of the reasons I rarely bothered with OpenBSD. Use it with packaged software as is (e.g. as router). Avoid for development. ---------------------------------------------------------------------- Fred vS · 2026-04-02 12:44 Quote from: marcov on April 02, 2026, 02:38:43 pmAvoid for development. For you, Marco, but not for others. ---------------------------------------------------------------------- marcov · 2026-04-02 12:52 Quote from: Fred vS on April 02, 2026, 02:44:47 pmQuote from: marcov on April 02, 2026, 02:38:43 pmAvoid for development. For you, Marco, but not for others.  According to Gemini. Free Pascal sources don't automatically adapt to kernel/libc structure/macro/consts changes, so that invalidates the whole premise of OpenBSD's security. But enlighten me, why do you think it is better for development than either FreeBSD or Linux? ---------------------------------------------------------------------- Fred vS · 2026-04-02 13:03 Quote from: marcov on April 02, 2026, 02:52:03 pmBut enlighten me, why do you think it is better for development than either FreeBSD or Linux? Allez, because you haven't killed me yet when I ask the AI ​​to explain more clearly what I think: OpenBSD is often preferred for development over FreeBSD or Linux by developers who prioritize security, code correctness, simplicity, and a cohesive, "batteries-included" base system. While FreeBSD excels in performance and Linux offers broader hardware/software support, OpenBSD's development environment is praised for its consistency, legendary documentation, and innovative security tools like pledge(2) and unveil(2). Here is why OpenBSD is considered better for development in specific contexts: 1. Superior Security-by-Default DesignProactive Hardening: OpenBSD is designed with an uncompromising focus on security, using technologies like W^X (Write XOR Execute) and ASLR, often making it more secure out of the box than hardened Linux alternatives.pledge(2) and unveil(2): These system calls allow developers to restrict a process's capabilities and filesystem access with minimal code changes. This makes auditing and securing applications much easier than alternative methods in Linux or FreeBSD's Capsicum.Secure Coding Audits: The development team routinely audits the entire source code for security issues and unsafe patterns. 2. Cohesive and "Correct" Base SystemSingle Repository: Unlike Linux, where the kernel, libc, and userland tools are developed separately, OpenBSD develops the entire base system (kernel and userland) together. This results in a tighter integration, making it feel more like a traditional Unix system.High-Quality Built-ins: The base system includes powerful, well-integrated software like pf (packet filter), OpenSSH, relayd, httpd, and smtpd.No Dependency on Systemd: OpenBSD follows the Unix philosophy, avoiding the complexity and bloat of systemd. 3. Better Developer Experience and DocumentationLegendary Man Pages: OpenBSD manual pages are known for being accurate, comprehensive, and updated with every code change. They often provide better technical information than Linux info pages or online forums.Consistency: System administration is predictable. Configuration files are consistently organized, and commands learned years ago rarely change unexpectedly.Simple Upgrades: OpenBSD is recognized for having one of the easiest and most reliable major version upgrade processes, reducing maintenance overhead. 4. Code Quality and AuditabilityConservative Coding: OpenBSD emphasizes code readability, correctness, and simplicity over "flashy" new features.No Bloatware: The project frequently removes dead or redundant code, keeping the system slim and easier to audit.Comparison SummaryOpenBSD vs. Linux: OpenBSD offers a far more consistent and secure environment, avoiding the fragmentation of Linux distributions.OpenBSD vs. FreeBSD: OpenBSD is generally more secure, but FreeBSD has superior hardware support, higher performance, and a larger repository of third-party ports.When to choose OpenBSD for development: If your project involves networking, security appliances, or you need a stable, secure, and predictable development environment.When to avoid: If you need modern graphics acceleration, the latest Wi-Fi drivers, or high-performance ZFS file systems, FreeBSD or Linux may be better suited. ---------------------------------------------------------------------- Fred vS · 2026-04-02 13:48 Quote from: marcov on April 02, 2026, 02:52:03 pmBut enlighten me, why do you think it is better for development than either FreeBSD or Linux? Oops, I forgot one advantage, and not a minor one: Xenocara, their custom X11 graphical server. While most Linux/FreeBSD distributions consider X11 as a third-party "package" to be added to the kernel, OpenBSD integrates Xenocara as a full-fledged part of the base system. Amen.