Re: Using Linux-Libc-Headers-2.6.x.y + latest kernel version (e.g. 2. 6.14.x)
Mark Rosenstand wrote: On Wed, 2005-11-30 at 07:46 -0800, Dan Nicholson wrote: On 11/30/05, Feldmeier Bernd [EMAIL PROTECTED] wrote: Hello guys, I created a LFS 6.1.1 test system. But is there a problem if I use the latest kernel version ? Because Using Linux-Libc-Headers version and latest kernel version differs? It's perfectly fine as far as I know. Every major distro does it. In fact one of the main reasons to install l-l-h is so the glibc you installed will always have a known set of headers to interface with the kernel. All that happens is that your glibc can't use the new kernel features that come up, but other applications that are aware of them can. For instance, 2.6.14 includes something called FUSE (File Systems in Userspace) which allows ordinary users to mount various filesystems in userspace (I'm bungling the description). Anyway, my l-l-h headers are 2.6.12.0, but I updated the kernel to 2.6.14.2 and used the FUSE interface to my heart's content. Just an example. And I run a dovecot IMAP server without inotify-support on a inotify-enabled Linux 2.6.14 machine because it couldn't find linux/inotify.h And what is your experience with this ? Do you find that inotify works/is picked up by dovecot ? or do you find its just a feature that is enabled in the kernel, that is not picked up by applications. I'm interested Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Using Linux-Libc-Headers-2.6.x.y + latest kernel version (e.g. 2. 6.14.x)
Mark Rosenstand wrote: Matt Darcy wrote: Mark Rosenstand wrote: And I run a dovecot IMAP server without inotify-support on a inotify-enabled Linux 2.6.14 machine because it couldn't find linux/inotify.h And what is your experience with this ? Do you find that inotify works/is picked up by dovecot ? or do you find its just a feature that is enabled in the kernel, that is not picked up by applications. I'm interested I thought the because part made it pretty clear :) I would like it to use inotify, but it doesn't because the headers are too old. I never really understood why most (all?) distributors choose to use kernel headers that doesn't match the running kernel. got you - your right the because did make it clear to be fair. Just wanted there to be no confusdion that it wasn't built with inotify, nor could it use inotify. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
FC4 as a host [Was: Re: file format not recognized from ld right from the start????]
Andrew Benton wrote: Bing. You hit the nail on the head there. As Richard said, Fedora Core 4 isn't a suitable distro to build the stable version of the book. It should work OK for the development version but that may not be suitable if it's your first attempt at LFS. I've had good results building from Ubuntu. I like Ubuntu because it's all on one CD. Like the LFS live CD in fact. One important point. If you get an error building binutils, don't think it doesn't matter and try to build gcc. Fix the errors as they come up. Erm. Didn't we fix this issue for 6.1.1? (Of course development should be fine, too). We now patch binutils: If you are building from a host running Gcc-4 or later, it is necessary to patch the first build of this version of Binutils so that it can be compiled by the host system. Of course that's not true for 6.1, but since as of yesterday, stable is 6.1.1, FC4 *should* be suitable as a host. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: FC4 as a host [Was: Re: file format not recognized from ld right from the start????]
On Thu, 01 Dec 2005 10:04:50 -0500 Jeremy Huntwork [EMAIL PROTECTED] wrote: Andrew Benton wrote: Bing. You hit the nail on the head there. As Richard said, Fedora Core 4 isn't a suitable distro to build the stable version of the book. It should work OK for the development version but that may not be suitable if it's your first attempt at LFS. I've had good results building from Ubuntu. I like Ubuntu because it's all on one CD. Like the LFS live CD in fact. One important point. If you get an error building binutils, don't think it doesn't matter and try to build gcc. Fix the errors as they come up. Erm. Didn't we fix this issue for 6.1.1? (Of course development should be fine, too). We now patch binutils: If you are building from a host running Gcc-4 or later, it is necessary to patch the first build of this version of Binutils so that it can be compiled by the host system. Of course that's not true for 6.1, but since as of yesterday, stable is 6.1.1, FC4 *should* be suitable as a host. IIRC, Fedora patches the hell out of GCC-4 so that it isn't a regular GCC-4 anymore. I don't feel up to searching out all the threads on this. I think the best advice is still 'Don't build LFS from FC-4'. R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Using Linux-Libc-Headers-2.6.x.y + latest kernel version (e.g. 2. 6.14.x)
On 12/1/05, Mark Rosenstand [EMAIL PROTECTED] wrote: I would like it to use inotify, but it doesn't because the headers are too old. I never really understood why most (all?) distributors choose to use kernel headers that doesn't match the running kernel. It's up to the userspace package you're installing to include the appropriate headers for inotify support. The userspace package cannot make any assumptions about what kernel you're running or what kernel your libc is compiled against. That would be insane. Now, as for not installing the kernel headers of your running kernel, this has been hashed out MANY times. Once more though... When you install glibc, it is built against a static headers package (linux-libc-headers or you could pull the headers from a kernel source tree, but they're not sanitized). After you install glibc, you can't blindly update the headers because then any application you compile using libc functions (probably every single one) would see different function definitions than actually exist in your libc. Say you put the 2.6.14 headers in /usr/include but your libc was installed against 2.6.12. Now, you compile a program that wants inotify support. It finds the appropriate definitions in /usr/include/linux/some-header.h. Assuming it builds, when you run your program and it makes a call to some glibc function that the 2.6.14 headers say will return some inotify result, you get an error. See how that works? That's why it's called linux-libc-headers. If you don't believe me, read this old thread: http://linuxfromscratch.org/pipermail/faq/2004-July/000159.html and in Linus' own words: http://linuxmafia.com/faq/Kernel/usr-src-linux-symlink.html -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Using Linux-Libc-Headers-2.6.x.y + latest kernel version (e.g. 2. 6.14.x)
On 12/1/05, Dan Nicholson [EMAIL PROTECTED] wrote: On 12/1/05, Mark Rosenstand [EMAIL PROTECTED] wrote: I would like it to use inotify, but it doesn't because the headers are too old. I never really understood why most (all?) distributors choose to use kernel headers that doesn't match the running kernel. It's up to the userspace package you're installing to include the appropriate headers for inotify support. The userspace package cannot make any assumptions about what kernel you're running or what kernel your libc is compiled against. That would be insane. As a follow up to this comment, beagle also uses inotify. I built it with l-l-h-2.6.12.0, and it works fine now that I've upgraded my kernel to 2.6.14. How? beagle (appropriately) includes inotify.h in it's source tree. [11:59 AM [EMAIL PROTECTED] ls beagle-0.1.2/glue/ beagled-utils.cgecko-utils.cpp ioprio-glue.c tomboykeybinder.h eggaccelerators.c gecko-utils.h Makefile.am vmsize-glue.c eggaccelerators.h inotify-glue.c Makefile.in wv1-glue.c eggtrayicon.c inotify.h screensaver-glue.c eggtrayicon.h inotify-syscalls.h tomboykeybinder.c So, your problem is that dovecot is assuming you'll install inotify.h and its friends to /usr/include/linux which is not appropriate. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Using Linux-Libc-Headers-2.6.x.y + latest kernel version (e.g. 2. 6.14.x)
Dan Nicholson wrote: As a follow up to this comment, beagle also uses inotify. I built it with l-l-h-2.6.12.0, and it works fine now that I've upgraded my kernel to 2.6.14. How? beagle (appropriately) includes inotify.h in it's source tree. Just as a point of interest, what happens if one compiles and runs beagle on a kernel that doesn't have inotify present and/or enabled? Presumbly it has some runtime detection so it can fallback to something else or simply bail out, right? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Using Linux-Libc-Headers-2.6.x.y + latest kernel version (e.g. 2. 6.14.x)
On 12/1/05, Matthew Burgess [EMAIL PROTECTED] wrote: Dan Nicholson wrote: As a follow up to this comment, beagle also uses inotify. I built it with l-l-h-2.6.12.0, and it works fine now that I've upgraded my kernel to 2.6.14. How? beagle (appropriately) includes inotify.h in it's source tree. Just as a point of interest, what happens if one compiles and runs beagle on a kernel that doesn't have inotify present and/or enabled? Presumbly it has some runtime detection so it can fallback to something else or simply bail out, right? Yes, it has runtime detection and falls back if inotify isn't there. Their FAQ strongly suggests using inotify, but it will work without. You just have limited functionality. This was the case when I was still running 2.6.12.5 from my original LFS build. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
clarify __ Using Linux-Libc-Headers-2.6.x.y + latest kernel version (e.g. 2.6.14.x)
Hi guys, nice discussion about that very important stuff. I began this discussion earlier ... So maybe someone could clarify this stuff clearly ... a) dependency of kernel version and linux-libc-header version b) problems occuring c) real meaning of sanatized headers (why ...) d) creating our own up-to-date header version e) libc + kernel interface calls regards Bernd -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS 6.1 and 6.1.1, chapter 3: man-pages-2.01 download location
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! Chapter 3.2 of LFS 6.1.1 URL:http://www.linuxfromscratch.org/lfs/view/6.1.1/chapter03/packages.html lists URL:http://www.kernel.org/pub/linux/docs/manpages/ as download location for man-pages-2.01. This package is not/no longer available from this location. LFS 6.1 URL:http://www.linuxfromscratch.org/lfs/view/6.1/chapter03/packages.html has the same problem. I suggest finding a mirror which still has version 2.01 of man-pages and including the correct URIs in the LFS 6.1 and 6.1.1 errata. Thanks, - -- Nico -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDj4nUxI5uhYOGv4URAg4IAJwKJXFgcrXbBoN6m8gYPrwbBFPZIgCeI0yc /OfvNbsgGKwBGL2digU5iwQ= =QwrG -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS 6.1 and 6.1.1, chapter 3: man-pages-2.01 download location
Nico R. wrote: I suggest finding a mirror which still has version 2.01 of man-pages and including the correct URIs in the LFS 6.1 and 6.1.1 errata. LFS has its own package mirrors. On it are the packages for LFS version 6.0 to Development. There is no sense in adding download locations to the errata, when we host the packages and if we don't, one can find it with google. http://www.linuxfromscratch.org/lfs/download.html#ftp Justin -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: clarify __ Using Linux-Libc-Headers-2.6.x.y + latest kernel version (e.g. 2.6.14.x)
Bernd Feldmeier wrote: a) dependency of kernel version and linux-libc-header version None whatsoever. These are two different packages, with two different reasons for existing. l-l-h is based on the kernel headers, but you can use any version of either of them (well, no, that isn't quite right: your kernel version has to be = your l-l-h version, because the kernel contains backwards compatibility code, but it does not have to be ==). b) problems occuring Problems when you try to do what? If you upgrade l-l-h (and the kernel) without recompiling glibc, any programs you compile against the new l-l-h headers could break when they try to call functions in the glibc that never got changed. (See Linus's comments, which have been linked to by several people in this thread.) If you upgrade the kernel without upgrading l-l-h or glibc, then you have no problems. The kernel keeps all sorts of back-compat code in so that programs (and libraries, i.e. glibc) that use older versions of its userspace ABI can still work. If you upgrade the kernel without upgrading l-l-h or glibc, *and* you need to compile a program that (1) needs a feature present in the new kernel, but (2) does not include its own local header for that feature, then you won't be able to compile the program. But this is a bug in the program, not a reason to keep kernel and l-l-h versions in sync. When you're using a brand-new feature, you better be keeping your own version of that feature's header files, so you can compile against slightly older glibcs. c) real meaning of sanatized headers (why ...) Because the headers right out of the kernel contain all kinds of cruft that userspace doesn't need to see or use. (Plus they're bigger, so compilation takes slightly longer.) Plus they use the *wrong* names for several structures and structure members (IPv6), and therefore will *never* work with RFC-compliant user programs. d) creating our own up-to-date header version IMO, that's way too much work, since it's already being done by l-l-h. e) libc + kernel interface calls I'm not sure what you mean here... signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
ANNOUNCE: jhalfs 0.2 Released
As you may be aware, there is a new implementation of ALFS available, called jhalfs. The main purpose of jhalfs is to provide a pure reference build of LFS by extracting the commands to run directly from the LFS book. This has the added benefit of reducing maintenance as there are no profiles needed. This is the first release of jhalfs. Version 0.1 was a proof-of-concept and not a working release. You can download version 0.2 at: http://www.linuxfromscratch.org/alfs/downloads/jhalfs/ All comments, questions and discussion of this profile should be directed to the alfs-discuss mailing list. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: qt
Bruce Dubbs wrote: I'm working with qt on a fresh lfs-dev system. The latest suitable for KDE is version 3.3.5. I've built about all the dependencies and am trying to get qt validated. My access is via a chroot from an LFS 6.1 system. During the make, I am getting a segfault from the built uic application. I went back and tried version 3.3.4 which is known to work with a gcc4 compiler and it segfaults too. There was a message in blfs-support in September about this in blfs-support, but I didn't see a solution. Is this a chroot issue? Answering my own post, it looks like it is a chroot issue. When rebooting into the LFS-dev system and running the same commands, qt builds fine. I can't test it until I've built KDE, but I suspect it will be OK. Perhaps there should be a warning in the book that building qt in a chroot environment may cause a failure to build. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[Announce] LFS LiveCD 6.1.1-1 Released
The LFS LiveCD Team is proud to announce the release of the x86-6.1.1-1 version of the LFS LiveCD. This version is built using LFS 6.1.1 and BLFS packages from the svn branch. Packages for LFS 6.1.1 are included on the LiveCD. Other new features: * XFCE Terminal with helpful menus, including copy and paste * jhalfs 0.2 included * LFS 6.1.1 nALFS Profile * More new packages: rsync, sudo, wireless_tools Please mail any comments to the LFS LiveCD mailing list. To download the new LiveCD, visit the LFS LiveCD download page for a list of mirrors: http://www.linuxfromscratch.org/livecd/download.html At the time this announcement was sent, not all mirrors have synced. -- Justin R. Knierim lfs at lfs dash matrix dot net -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Announce] LFS LiveCD 6.1.1-1 Released
Congrats to all of the members of the LFS team. This is really a great achievement for us. Gossip is like a photograph. It starts with a negative, then is developed and enlarged --- Regards Mukesh Kaushal - Original Message - From: Justin R. Knierim [EMAIL PROTECTED] To: Development of LFS LiveCD livecd@linuxfromscratch.org; LFS Support List lfs-support@linuxfromscratch.org; ALFS Discussion and Development List alfs-discuss@linuxfromscratch.org; blfs-support@linuxfromscratch.org; LFS Developers Mailinglist lfs-dev@linuxfromscratch.org; BLFS Development List blfs-dev@linuxfromscratch.org; lfs-security@linuxfromscratch.org; lfs-announce@linuxfromscratch.org Sent: Friday, December 02, 2005 12:30 PM Subject: [Announce] LFS LiveCD 6.1.1-1 Released The LFS LiveCD Team is proud to announce the release of the x86-6.1.1-1 version of the LFS LiveCD. This version is built using LFS 6.1.1 and BLFS packages from the svn branch. Packages for LFS 6.1.1 are included on the LiveCD. Other new features: * XFCE Terminal with helpful menus, including copy and paste * jhalfs 0.2 included * LFS 6.1.1 nALFS Profile * More new packages: rsync, sudo, wireless_tools Please mail any comments to the LFS LiveCD mailing list. To download the new LiveCD, visit the LFS LiveCD download page for a list of mirrors: http://www.linuxfromscratch.org/livecd/download.html At the time this announcement was sent, not all mirrors have synced. -- Justin R. Knierim lfs at lfs dash matrix dot net -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
