I am stuck with Slack 12 on a legacy system and I am trying to replace Xenomai with a more modern kernel and high rez timers. glibc-2.5 on Slack12 does not have timerfd_create - you allegedly need >= 2.8 Slack 13.0 has 2.9 and has timerfd_create so I take the source from 13.0 and run glibc.Slackbuild on 12.0 but no joy. I get 2.9 with timerfd_create stubbed out rather than missing. ie, I get "warning timerfd_create is not implemented" rather than "undefined reference". How do I build so I really get functional timerfd_create? I have spent the day grepping but can't figure it out.

One does not simply recompile glibc.


I'm frankly surprised that you have got so far already, so congratulations.

As a wild guess, glibc-2.9 would need a particular minimum kernel that supports timerfd_create. Have you upgraded the kernel yet, and what version did you use? Did you install the upgraded kernel headers so that glibc-2.9 picked them up? You should consider the steps documented in Linux From Scratch 6.5 or LFS-6.4. Ideally, you should use the exact right version of binutils. My money is on the kernel headers being the problem, but that's just a guess.

*HOWEVER*, so long as your kernel is new enough to contain the timerfd_create syscall, you don't have to have a version of glibc that contains a wrapper function. You can call it directly and not bother with any of the glibc building trauma. See 'man 2 syscalls', which also helpfully tells us you need kernel 2.6.25 or later, and also 'man 2 syscall'. (One is 'syscalls' and the other is 'syscall'. You need to read both )

You don't explain why you are stuck with Slackware 12.0. Maybe people here could help you explore what is preventing you from upgrading? Because after you've upgraded the kernel, and maybe even glibc, you'll already have done a lot of the upgrade the hard way...

That has become obvious.
Thanks. As far as I can tell, you need glibc-2.8 or up to get timerfd_create, I tried to use glibc-2.9 because I of Pat's package, including glibc.Slackbuild. Kernel is 2.6.34 these days, so it isn't a problem. I can compile the application --static on a Slack 13.0 VM and it runs on the target, so I know the kernel is OK. I will take a look at LFS. I had not found any tutorial on compiling glibc. Re: binutils, my hope was that the difference gibc-2.5 to glibc-2.9 and Slack 12.0 to Slack 13.0 were small enough that I could get by. I do know how to build/install newer binutils is such a was as to allow a compile with them without screwing up the rest of the install. The build host is Slack 12 since that is what the target is. Kernel headers may very will be the problem as /usr/include is stock Slack 12 and I didn't want to overwrite it. I need to look at that more.

That thought had crossed my mind, but I didn't know where to start. I will look into that also.
The package is named after Slack. That started when we switched from 68K and OS9 to x86 and Slackware long ago. There has been Slack8, Slack9, Slack10, and Slack11. The next generation is Slack12. Slack13 is reserved for later. This is the back end of a data collection system for factories. I have always had to use a different kernel as I had to use one that had patches available for RTLinux or, more recently, Xenomai. The reason I needed them is that a 16550 fifo would overrun while the kernel had interrupts masked and I needed a stable 100Hz clock for sampling data. It looks like a 2.6.34 kernel running 1000Hz and tickless with high rez timers can handle the job without Xenomai, but you have the problem of getting the interrupt (signal) from the kernel cleanly. You can't do much in a signal handler and using sem_wait/post doesn't work well because of an extra context switch or some such. timerfd_* is clean and works well, which brings me to this point.

The old kernel headers are probably the cause.

Try this: compile and install the version of glibc that you need, then compile and install the new kernel (including the new kernel headers) that your target system is going to use, then recompile and re-install glibc so that it will pick up support for the new kernel functionality (through the kernel headers).

And take a moment to edit the glibc.SlackBuild and set the "--enable-kernel" value to the lowest kernel version you expect to be using on your target. Setting the kernel version as high as possible reduces the size of the resulting glibc package because less compatibility code (to support older kernels) needs to be compiled in.

Eric

Much thanks to both of you for the hints. I gave up on glibc. The problem headers were /usr/include/bits/syscall.h and /usr/include/asm/unistd.h which were missing timerfd_*. I don't know if those are considered kernel files, but they were not in the kernel header tarball so I grabbed them from my Slack 13 VM. But while the prior glibc linked cleanly but reported missing functions at run time, now I got link errors - unresolved reference __libc_csu_init/fini.

Since I had already found the headers and knew the magic numbers, I gave syscall() a try. It works great.

Thanks again!

kernel headers are in /usr/src/linux/include/uapi/
/usr/include/* ones are made by glibc

on the how, why and in what order i find myself confused still

PS for whoever decides to do this; some binutils are vital for glibc

What ???

Try this to check:

k..

"The correct way to package the header files for a distribution is to run 'make headers_install' from the kernel source directory to install the headers into /usr/include and then rebuild the C library package, with a dependency on the specific version of the just installed kernel headers."

http://kernelnewbies.org/KernelHeaders

they are still from the kernel
so no timerfd_create without manually updating them
and they are still there for glibc specifically
(or ofc other programs that want to use the kernel directly, but those are rare)

in other words; where is the slackbuild ?
everything else has a slackbuild

edit: what confuses me is that they are not the same headers (in structure, same definitions thou)

Most packages a have a SlackBuild, not all. This one (as well as slackpkg, for instance) doesn't have one, because there's nothing to compile specifically to make the package.

To make the package kernel-headers, you have just to create a file tree, copy some of the header files from /usr/src/linux/include there, then apply the "makepkg" command to the file tree.

If instead you run make headers_install instead as suggested @ http://kernelnewbies.org, that doesn't need a SlackBuild either.

The clue is in the question:

Maybe Mr Volkerding feels no great need for a SlackBuild that would contain only 'make headers_check; make headers_install' and a makepkg command, though he has put a slack-desc file in the obvious place.

IIRC, years ago, there was a huge fight about whose responsibility it was to convert the internal kernel headers into userspace headers. The kernel people said it was glibc's job, and the glibc people (fsvo) said it was the kernel's job. The kernel people blinked first. The conversion is performed by the kernel's 'make headers_install' target.

it is a bit more of a kernel makers job since, well, some like/need to call the kernel directly (or at least want to avoid glibc)
not by much thou

funny that now with musl and friends things are getting more streamlined
still glibc holds the flag on having many non-posix things

as for the question, it was rhetorical
my guess, that i thought about when walking the dog just now, is that a slackbuild might get misused
also ye it would be 2 lines long, 3 with cd

Creating properly 'sanitized' headers for use when compiling glibc used to be a black art. Some of the more advanced users/hackers of Slackware have always taken exception at PatV's non-transparent method of creating the headers (by not providing a SlackBuild which documents the process).

1 members found this post helpful.