OpenBSD structure layout wrong after recent OpenBSD changes

[jeremyevans]

Recently, OpenBSD moved from a 32-bit time_t to a 64-bit time_t, with some other changes as well:

Commit message: http://marc.info/?l=openbsd-cvs&m=137637321205010&w=2)
Changes to sys/_types.h: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/_types.h.diff?r1=1.5;r2=1.6
Changes to sys/stat.h: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/stat.h.diff?r1=1.22;r2=1.23

After this change in OpenBSD, JRuby will not fully install, as it fails when trying to install rake (http://pbot.rmdir.de/JDuDNBBfrpVBb_EQKuJSVA).

I believe I have a diff that brings the jnr-posix structure layouts in-line with OpenBSD-current, but I haven't tested it yet (http://pastie.org/pastes/8260655/text). However, a straight patch approach may be unacceptable as it would mean that jnr-posix would then not work correctly on older OpenBSD versions. Would that be a problem?

If it would be a problem, do you have a recommendation on the best way to fix this such that both older and newer OpenBSD would run correctly? Should we have code for both OpenBSD layouts, and pick which one to use at runtime? If so, should such a check go in POSIXFactory.java, and do you have an idea about how to check (such as using the operating system version)?

[vext01]

I am also having difficulty with jnr-posix, albeit with the jar that is distributed with jython. It seems that FileStat sometimes reports paths which are not a symlink as a symlink. Looking at OpenBSDFileStat.java I think the interface needs to be reviewed. For example:

• time_t is certainly not a signed 32 any more (as pointed out by Jeremy). You may need to do a sizeof check, as there will be many OpenBSD systems in the wild still running time32.
• On my amd64 system, a ino_t is an unsigned 64 (not a unsigned 32).

You may find that these types vary from arch to arch(?)

In other words, OpenBSD support needs some love.

[vext01]

I confirm that the patch Jeremy posted, when applied to jnr-posix-2.4 (the version jython uses) fixes the problems I am seeing with symlinks/stat.

[enebo]

@wmeissner Talking to @jeremyevans on irc he pointed out this only works OpenBSD >5.4, We should be able to conditionalize loading a second OpenBSD Libc right? Have you thought about this particular issue past 32/64 bit differences?

[ghost]

We don't have to load a different lib, just define different structures, correct?

Worst case, when we detect OpenBSD, we can just look at the output from uname -r, and use the new structs when we detect release > 5.4.

i.e. I'd rename the existing OpenBSD structs to OldOpenBSDFoo, and use them when uname -r <= "5.4", otherwise use the new structs/calls.

[enebo]

yeah that seems reasonable. thanks @wmeissner.

[vext01]

Are you able to do something equivalent to sizeof on C?
On 9 Oct 2013 21:34, "Wayne Meissner" notifications@github.com wrote:

We don't have to load a different lib, just define different structures,
correct?

Worst case, when we detect OpenBSD, we can just look at the output from uname
-r, and use the new structs when we detect release > 5.4.

i.e. I'd rename the existing OpenBSD structs to OldOpenBSDFoo, and use
them when uname -r <= "5.4", otherwise use the new structs/calls.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-26006155
.

[ghost]

Are you able to do something equivalent to sizeof on C?

No - we don't call the compiler at all during runtime linking. That will probably change in future versions of jnr-ffi (using clang), but it isn't an option right now (other than shelling out to the C compiler to compile a small C program that prints out all the sizes).

jnr-ffi does contain a table of common types, but the OpenBSD table was built for an older version of OpenBSD.

[jasperla]

Has there been any work done in this direction? The new puppetserver project is utilising jnr-posix and it fails to run, most likely due to this very issue.

[jeremyevans]

Fixed by #36.