How to detect Linux Kernel and glibc version?

Ruby
#1

Hi, for a Ruby C extension I need to check in extconf.rb the Linux
kernel and glibc version in which the extension is being compiled (so
when running “gem install xxxx”). I need to know this information in
order to use the accept4 system call which exists from kernel 2.6.28
and from glibc 2.10 (both conditions must be satisfied).

So I expect something like the following in my extconf.rb:

case RUBY_PLATFORM
when /linux/
if KERNEL_VERSION >= “2.6.28” and GLIBC_VERSION >= “2.10”
add_define ‘HAVE_ACCEPT4’
end

Well, I could run “uname -r” but that is dangerous, example:

“2.6.3” >= “2.6.28”
=> true OPSSSSS !!!

And unfortunatelly I cannot add more gems (i.e. versionomy) as
depencency.

Also, no idea to get the current “glibc” version.

Thanks for any tip.

#2

“Iñaki Baz C.” [email protected] wrote in post #1050385:

case RUBY_PLATFORM
when /linux/
if KERNEL_VERSION >= “2.6.28” and GLIBC_VERSION >= “2.10”
add_define ‘HAVE_ACCEPT4’
end

Well, I could run “uname -r” but that is dangerous, example:

“2.6.3” >= “2.6.28”
=> true OPSSSSS !!!

And unfortunatelly I cannot add more gems (i.e. versionomy) as
depencency.

But you could add a few lines, couldn’t you? Why not

irb(main):001:0> class String
irb(main):002:1> def to_v
irb(main):003:2> scan(/\d+/).map(&:to_i).extend Comparable
irb(main):004:2> end
irb(main):005:1> end
=> nil
irb(main):006:0> “2.6.3”.to_v > “2.6.28”.to_v
=> false

Kind regards

robert

#3

Iñaki Baz C. [email protected] wrote:

Hi, for a Ruby C extension I need to check in extconf.rb the Linux
kernel and glibc version in which the extension is being compiled (so
when running “gem install xxxx”). I need to know this information in
order to use the accept4 system call which exists from kernel 2.6.28
and from glibc 2.10 (both conditions must be satisfied).

kgio just uses: have_func(‘accept4’, %w(sys/socket.h))

I recently added an extra check for SOCK_* macros because of
Debian GNU/kFreeBSD:

http://bogomips.org/kgio.git/patch/?id=56cce133d979c22bbef80fdba1881d8f40876e2f

Also, no idea to get the current “glibc” version.

No need to care about kernel version or glibc version.
I try to avoid version-based checks entirely (not always possible).

The trickier case is handling ENOSYS, because I’ve seen folks run into
issues where code gets built on a newer machine and deployed on an old
one.

#4

2012/3/6 Robert K. [email protected]:

irb(main):001:0> class String
irb(main):002:1> def to_v
irb(main):003:2> scan(/\d+/).map(&:to_i).extend Comparable
irb(main):004:2> end
irb(main):005:1> end
=> nil
irb(main):006:0> “2.6.3”.to_v > “2.6.28”.to_v

Just cool :slight_smile:

#5

Iñaki Baz C. [email protected] wrote:

SOCK_CLOEXEC = 02000000, /* Atomically set close-on-exec
flag for the new
descriptor(s). */
#define SOCK_CLOEXEC SOCK_CLOEXEC

Am I right?

Yes.

(I don’t understand the purpose of lines 8-14 in your above link).

I assume you meant ext/kgio/missing_accept4.h and not the actual diff:

$ sed -ne 8,14p < ~/kgio/ext/kgio/missing_accept4.h

if (02000000 == O_NONBLOCK)

define SOCK_CLOEXEC 1

define SOCK_NONBLOCK 2

else

define SOCK_CLOEXEC 02000000

define SOCK_NONBLOCK O_NONBLOCK

endif

I’m just defining SOCK_* macros so the wrapper function has a way
of making sense of those flags and expose an interface similar
to the accept4() syscall. Those macros eventually get defined
to the corresponding Kgio::SOCK_* constants in Ruby.

This compatibility workaround of defining macros that look like
system-provide ones is only safe for use private headers, though.
(Don’t do anything crazy like resolve the Ruby constants to
Integers in your source and expect those Integers to work across
upgrades/different platforms)

#6

2012/3/8 Eric W. [email protected]:

I’m just defining SOCK_* macros so the wrapper function has a way
of making sense of those flags and expose an interface similar
to the accept4() syscall. Those macros eventually get defined
to the corresponding Kgio::SOCK_* constants in Ruby.

This compatibility workaround of defining macros that look like
system-provide ones is only safe for use private headers, though.
(Don’t do anything crazy like resolve the Ruby constants to
Integers in your source and expect those Integers to work across
upgrades/different platforms)

Clear, thanks a lot.

#7

2012/3/7 Eric W. [email protected]:

kgio just uses: have_func(‘accept4’, %w(sys/socket.h))

Just great :slight_smile:

I recently added an extra check for SOCK_* macros because of
Debian GNU/kFreeBSD:

http://bogomips.org/kgio.git/patch/?id=56cce133d979c22bbef80fdba1881d8f40876e2f

So SOCK_CLOEXEC is set when loading some .h file, in my case
/usr/include/x86_64-linux-gnu/bits/socket.h which includes:

SOCK_CLOEXEC = 02000000, /* Atomically set close-on-exec
flag for the new
descriptor(s). */
#define SOCK_CLOEXEC SOCK_CLOEXEC

Am I right? (I don’t understand the purpose of lines 8-14 in your above
link).

Also, no idea to get the current “glibc” version.

No need to care about kernel version or glibc version.
I try to avoid version-based checks entirely (not always possible).

Ok.

The trickier case is handling ENOSYS, because I’ve seen folks run into
issues where code gets built on a newer machine and deployed on an old
one.

Yes, but that should be considered an “human” error :slight_smile:

Thanks a lot.