LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
 
Search this Thread
Old 07-25-2014, 03:24 PM   #1
gearheadgeek
LQ Newbie
 
Registered: Aug 2007
Posts: 26

Rep: Reputation: 0
Trouble compiling glibc


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.
 
Old 07-25-2014, 04:46 PM   #2
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 497
Blog Entries: 4

Rep: Reputation: 531Reputation: 531Reputation: 531Reputation: 531Reputation: 531Reputation: 531
One does not simply recompile glibc.
Click image for larger version

Name:	alu62.jpg
Views:	13
Size:	50.8 KB
ID:	15969

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...

Last edited by 55020; 07-25-2014 at 04:57 PM.
 
Old 07-28-2014, 07:26 AM   #3
gearheadgeek
LQ Newbie
 
Registered: Aug 2007
Posts: 26

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by 55020 View Post
One does not simply recompile glibc.
That has become obvious.
Quote:
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.
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.

Quote:
*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 )
That thought had crossed my mind, but I didn't know where to start. I will look into that also.
Quote:
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...
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.
 
Old 07-28-2014, 07:47 AM   #4
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,545

Rep: Reputation: Disabled
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
 
Old 07-28-2014, 02:49 PM   #5
gearheadgeek
LQ Newbie
 
Registered: Aug 2007
Posts: 26

Original Poster
Rep: Reputation: 0
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!
 
Old 07-28-2014, 03:03 PM   #6
genss
Member
 
Registered: Nov 2013
Posts: 531

Rep: Reputation: Disabled
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
 
Old 07-28-2014, 03:24 PM   #7
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad W520
Posts: 5,113

Rep: Reputation: 1401Reputation: 1401Reputation: 1401Reputation: 1401Reputation: 1401Reputation: 1401Reputation: 1401Reputation: 1401Reputation: 1401Reputation: 1401
Quote:
Originally Posted by genss View Post
kernel headers are in /usr/src/linux/include/uapi/
/usr/include/* ones are made by glibc
What ???

Try this to check:
Code:
cat /var/log/packages/kernel-headers*|grep linux|less
 
Old 07-28-2014, 03:53 PM   #8
genss
Member
 
Registered: Nov 2013
Posts: 531

Rep: Reputation: Disabled
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)

Last edited by genss; 07-28-2014 at 04:03 PM.
 
Old 07-28-2014, 04:45 PM   #9
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad W520
Posts: 5,113

Rep: Reputation: 1401Reputation: 1401Reputation: 1401Reputation: 1401Reputation: 1401Reputation: 1401Reputation: 1401Reputation: 1401Reputation: 1401Reputation: 1401
Quote:
Originally Posted by genss View Post
in other words; where is the slackbuild ?
everything else has a slackbuild
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.

Last edited by Didier Spaier; 07-28-2014 at 04:52 PM.
 
Old 07-28-2014, 04:59 PM   #10
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 497
Blog Entries: 4

Rep: Reputation: 531Reputation: 531Reputation: 531Reputation: 531Reputation: 531Reputation: 531
Quote:
Originally Posted by genss View Post
in other words; where is the slackbuild ?
everything else has a slackbuild
The clue is in the question:

Quote:
Originally Posted by genss View Post
"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."
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.

Quote:
Originally Posted by genss View Post
edit: what confuses me is that they are not the same headers (in structure, same definitions thou)
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.
 
Old 07-28-2014, 05:20 PM   #11
genss
Member
 
Registered: Nov 2013
Posts: 531

Rep: Reputation: Disabled
Quote:
Originally Posted by 55020 View Post
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

Last edited by genss; 07-28-2014 at 05:23 PM.
 
Old 07-29-2014, 02:35 AM   #12
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,787

Rep: Reputation: 484Reputation: 484Reputation: 484Reputation: 484Reputation: 484
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.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Trouble compiling gcc and glibc with piledriver cpu optimization (march=bdver2) Holering Slackware 3 01-25-2013 10:25 AM
Trouble compiling glibc forloRn_ Linux - Software 3 05-01-2012 03:14 AM
compiling cross gcc for powerpc, glibc trouble and73y Programming 14 06-05-2009 04:21 AM
glibc-compiling loves to make errors? ok, let me post mine here: glibc 2.9 me-$-on Linux From Scratch 7 04-11-2009 06:22 PM
Compiling glibc-2.3.5 or glibc 2.3.5-r1 on Gentoo fails ghrellin Linux - Software 2 07-19-2005 01:01 AM


All times are GMT -5. The time now is 02:35 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration