Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hello,i have completed LFS and started BLFS and while installing attr i am getting the following error
Code:
ls: error while loading shared libraries: /lib/libacl.so.1: file too short
Additional Info:
I am on chroot environment
i checked that /lib/libacl.so.1 its 0 byte
I couldn't find an solution for this expecting for an good solution here!!Please help me to get rid of this problem!
That always happens to me as well when building libacl. The shared library file gets installed into /lib as a 0-byte file. I've just come to accept it over the years. My approach is make sure I have a backup of libacl.so.1.?.? before the install-lib target is executed. This has been the case for as long as I remember and is a real bother since all of my coreutils tools are linked to libacl.
Other than being aware of it and taking precautions, I've never worked out a real remedy and have just been making do with that workaround hack. I then just manually copy the newly built file like this:
That always happens to me as well when building libacl. The shared library file gets installed into /lib as a 0-byte file. I've just come to accept it over the years. My approach is make sure I have a backup of libacl.so.1.?.? before the install-lib target is executed. This has been the case for as long as I remember and is a real bother since all of my coreutils tools are linked to libacl.
Other than being aware of it and taking precautions, I've never worked out a real remedy and have just been making do with that workaround hack.
I've never found one yet and have just accepted it as a fact of life. Have you also built coreutils against the ACL libraries? That may be what's happening to both of us.
I've never found one yet and have just accepted it as a fact of life. Have you also built coreutils against the ACL libraries? That may be what's happening to both of us.
yes i made coreutils installation again to check acl
yes i made coreutils installation again to check acl
As I said, having been accustomed to this for years, I just ensure I have a backup of libacl.so.1.?.? since the problem is inevitable. I took at look at ./include/buildmacros in the source tree and it does some complicated things to install the shared library. I've yet to figure it out since that file calls even more macros. Since the install command itself is linked against the ACL library, I surmise that something goes awry during the interval of time when the shared library is placed into the target directory.
I'm surprised that this hasn't impacted more people. It happens on a live system, in a chroot environment and in a virtual system as well. The commonality is that the coreutils tools are linked to ACL.
Strange, I don't have this problem... I create packages of all packages (or how to say it...), so I installed it to $pkgdir using fakeroot. Except from that I followed the book. I also recompiled coreutils after acl. I installed it in a chroot.
I still have my logs if that could give some clue.
I'm surprised that this hasn't impacted more people. It happens on a live system, in a chroot environment and in a virtual system as well. The commonality is that the coreutils tools are linked to ACL.
One more followup since curiosity got the best of mine in spite of my long-used workaround. Since I also use Gentoo, in spite of LFS being my everyday working platform, the problem with a 0-byte ACL shared library doesn't happen there even with install linked to ACL. Gentoo installs everything to a staging area into a subdirectory named image. Then the files are replicated from that temporary staging area into the main filesystem. By doing so, I surmise that the relationship between the install command and its linkage to the ACL shared library then becomes moot.
Ideally, the ACL (and ATTR) packages would have a DESTDIR variable as is common in most Makefiles so that we LFS users could likewise use such a staging area before clobbering the "in-use" libraries.
Strange, I don't have this problem... I create packages of all packages (or how to say it...), so I installed it to $pkgdir using fakeroot. Except from that I followed the book. I also recompiled coreutils after acl. I installed it in a chroot.
If you don't mind possibly temporarily hosing your system in the interest of science...
Try rebuilding ACL exactly by the BLFS book without using that $pkgdir. In short, what would be interesting is to discern if the install command, presuming it does have linkage to the ACL shared library ends up creating that 0-byte file in the actual /lib target as opposed to a staging area.
I don't want to bork my working system, but I can install all packages before acl to a chroot, and then build acl by the book in that chroot. I don't have time for it now, but during the weekend.
Quote:
In short, what would be interesting is to discern if the install command, presuming it does have linkage to the ACL shared library ends up creating that 0-byte file in the actual /lib target as opposed to a staging area.
I'm not sure I understand this correctly. How can the install command be linked to acl before acl is installed and coreutils recompiled?
So I have done the experiment now. I installed the packages from lfs, and attr. I still had the old package of coreutils, which was compiled before acl. Then I just copy-pasted the commands from the book, and the result is:
Code:
~/Data/LFS/build-chroot/lib
└─$ ls -lh | grep libacl
lrwxrwxrwx 1 root root 15 Jun 28 17:52 libacl.so.1 -> libacl.so.1.1.0
-rwxr-xr-x 1 root root 192K Jun 28 17:52 libacl.so.1.1.0
I have stripped all packages (except acl in this experiment), and I remove all .la files.
I don't want to bork my working system, but I can install all packages before acl to a chroot, and then build acl by the book in that chroot. I don't have time for it now, but during the weekend.
I'm not sure I understand this correctly. How can the install command be linked to acl before acl is installed and coreutils recompiled?
Here's the procedure in step-by-step form:
1). Install coreutils per the LFS book on a system without the acl/attr packages from BLFS. None of the commands (cp, install, ln and so on) will thus be linked against the acl/attr shared libraries of course.
2). Then build and install acl/attr per BLFS. There will be no problem at this point.
3). With acl/attr now present, go back and rebuild coreutils in order to get linkage to acl/attr.
4). And finally, rebuild acl/attr anew. At this point, the 0-byte shared library file problem will occur.
Since experience has taught me to guard against this known problem, I can follow these steps every time and replicate the problem regardless of the underlying platform -- chroot, virtual system or live system. The problem first became evident to me circa 2005 when a new version of the acl/attr packages were released through BLFS. It was then that I initially experienced the 0-byte shared library file.
1). Install coreutils per the LFS book on a system without the acl/attr packages from BLFS. None of the commands (cp, install, ln and so on) will thus be linked against the acl/attr shared libraries of course.
2). Then build and install acl/attr per BLFS. There will be no problem at this point.
3). With acl/attr now present, go back and rebuild coreutils in order to get linkage to acl/attr.
4). And finally, rebuild acl/attr anew. At this point, the 0-byte shared library file problem will occur.
Since experience has taught me to guard against this known problem, I can follow these steps every time and replicate the problem regardless of the underlying platform -- chroot, virtual system or live system. The problem first became evident to me circa 2005 when a new version of the acl/attr packages were released through BLFS. It was then that I initially experienced the 0-byte shared library file.
FORCE_UNSAFE_CONFIGURE=1 ./configure \
> --prefix=/usr \
> --libexecdir=/usr/lib \
> --enable-no-install-program=kill,uptime
ls: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory
configure: error: working directory cannot be determined
Additional Info:
I have removed those libacl files just for testing but i have those files in another location,
I have removed those libacl files just for testing but i have those files in another location,
please help me to fix this problem.
To expedite a quick fix, my suggestion is as follows:
1). Rebuild coreutils with these two additional flag: --disable-acl and --disable-xattr. For the moment, just forget about ACL/ATTR but otherwise follow the LFS instructions.
2). Now, with coreutils no longer linked against ACL/ATTR, go back and build ACL/ATTR per the BLFS instructions.
3). With ACL/ATTR now built, one final time, go back and rebuild coreutils without the two flags shown in step 1. On this pass of the coreutils build, you'll then link to ACL/ATTR and get the benefits of extended attributes and access control lists for tools such as ls, cp, mv and so forth.
I continued my experiment and recompiled coreutils and then recompiled acl. This time I also got the error.
But why do you recompile acl after coreutils? What I can see it shouldn't make any difference. I ran ldd on the binaries in acl: /usr/bin/chacl, /usr/bin/getfacl and /usr/bin/setfacl. None of them added dependency to coreutils. They still only depend on acl(itself), attr and glibc.
Edit: I ran ldd on the binaries in the build folder, in case they weren't installed yet, but no difference.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.