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.
It seems this borked the system completely... I tried to recompile coreutils, but got the same error.
Code:
FORCE_UNSAFE_CONFIGURE=1 ./configure \
> --prefix=/usr \
> --libexecdir=/usr/lib \
> --enable-no-install-program=kill,uptime
ls: error while loading shared libraries: /lib64/libacl.so.1: file too short
I think the only way to rebuild coreutils after this is, if you have backed up the tools directory you could copy it back, so you can use the coreutils tools from the temporary system.
I continued my experiment and recompiled coreutils and then recompiled acl. This time I also got the error.
That's good to know since at least three of us have come across it.
Quote:
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.
I've been doing LFS/BLFS for about a decade now. It's my primary, daily work environment and I keep current with the SVN versions of both LFS and BLFS. So the platform that I use has evolved over the years as I stay up to date with new packages as they appear in the Changelog.
That's the background and now for a direct answer to your question. I recompiled acl after coreutils simply because a newer version of the ACL/ATTR duo came along in BLFS's SVN book. The crux of the matter is the install binary from coreutils. It does have linkage against ACL/ATTR. Thus my theory is that the "make install-lib" phase of ACL/ATTR clobbers a shared library in use currently by the install command.
I hope to prove this theory over the weekend by rebuilding all of coreutils without ACL/ATTR and then extracting just install from the build to install onto the system. If my theory is indeed sound, the 0-byte shared library file should then not occur.
EDIT: My theory was wrong! See post #21 in this thread. The problem is that install is never used but a rather old shell wrapper uses cp to put the new library in place. Both the acl and attr packages suffer from this misfeature.
It seems this borked the system completely... I tried to recompile coreutils, but got the same error.
Code:
ls: error while loading shared libraries: /lib64/libacl.so.1: file too short
Lennie -- I have hosed my LFS system any number of times through the years. And since it's my primary platform, repairing the broken system has me forced to learn how to deal with these problems, some of which are my own making. The coreutils/acl/attr issue was one of the most frustrating since the "file too short" problem yields most of the core commands inoperative. That's why I've become friendly with sln, a static version of ln, to create symlinks to shared libraries when things get horribly borked.
I did another test.
1. I reinstalled the original coreutils package.
2. Then I recompiled acl. (But I still had the remnants from the former acl, with the empty libraries...)
3. I then recompiled coreutils with '--enable-no-install-program=kill,uptime,install' but it installed /usr/bin/install anyway. Before ran 'make install' I made a copy of /usr/bin/install, and after 'make install' I copied it back.
4. Then I recompiled acl, and again I got the 'file too short' error.
So it can't be only /usr/bin/install that is the problem.
For what it's worth... I'm defenately too tired for this now...
I did another test.
1. I reinstalled the original coreutils package.
2. Then I recompiled acl. (But I still had the remnants from the former acl, with the empty libraries...)
3. I then recompiled coreutils with '--enable-no-install-program=kill,uptime,install' but it installed /usr/bin/install anyway. Before ran 'make install' I made a copy of /usr/bin/install, and after 'make install' I copied it back.
4. Then I recompiled acl, and again I got the 'file too short' error.
So it can't be only /usr/bin/install that is the problem.
For what it's worth... I'm defenately too tired for this now...
I've got the whole weekend ahead of me and I'll be in a position to explore this in greater depth. Part of what I intend to figure out is just how the "make install-lib" target works in both acl and attr. It's not straightforward as is the case with most Makefiles. I don't mind hosing or borking my system since the fun part is learning from repairing the mess!
Maybe we can mark this thread as [SOLVED] if Dinesh and Lennie are willing to try something out. First of all, make sure you have a good, working LFS system with coreutils not failing due to the ACL/ATTR 0-byte file problem.
Then execute this command within the acl-2.2.25 and attr-2.4.47 source trees (changing the version if necessary for the directory name):
The build and install will no longer leave you stranded with a 0-byte shared library file. Both packages use a rather hairy install-sh script dating back to the turn of century from Silicon Graphics (RIP). The problem is the script uses "cp" to install the file. By changing it, via the sed command above to "cp -b", the good, working library is retained during the instant of time that "cp" does the replacement.
When complete, you can then remove the tilde-appended backup files to tidy up.
So, as it turns out, the problem isn't due to the install but due to the script which doesn't even use install at all.
I tried your solution and it worked for me too. Maybe you should write about this to the blfs mailing list where the developers are, so they can add this to the book. A big red warning about this would be great.
To the op: If you still have your acl build directory, you should have the real library there.
Code:
~/Data/LFS/build-chroot/sources/acl-2.2.52
└─$ find -name libacl.so.1.1.0
./libacl/.libs/libacl.so.1.1.0
~/Data/LFS/build-chroot/sources/acl-2.2.52
└─$ ls -lh ./libacl/.libs/libacl.so.1.1.0
-rwxr-xr-x 1 root root 192K Jun 29 10:21 ./libacl/.libs/libacl.so.1.1.0
Use Live cd and copy it to your system. It worked in my chroot.
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.
Thanks for this nelson but still i couldn't fix the problem here comes my results
Code:
root:/sources/coreutils-8.21# FORCE_UNSAFE_CONFIGURE=1 ./configure \
> --disable-acl \
> --disable-xattr \
> --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
I tried your solution and it worked for me too. Maybe you should write about this to the blfs mailing list where the developers are, so they can add this to the book. A big red warning about this would be great.
To the op: If you still have your acl build directory, you should have the real library there.
Code:
~/Data/LFS/build-chroot/sources/acl-2.2.52
└─$ find -name libacl.so.1.1.0
./libacl/.libs/libacl.so.1.1.0
~/Data/LFS/build-chroot/sources/acl-2.2.52
└─$ ls -lh ./libacl/.libs/libacl.so.1.1.0
-rwxr-xr-x 1 root root 192K Jun 29 10:21 ./libacl/.libs/libacl.so.1.1.0
Use Live cd and copy it to your system. It worked in my chroot.
I am not having acl build directory here is the op of find -name libacl.so.1.1.0
Maybe we can mark this thread as [SOLVED] if Dinesh and Lennie are willing to try something out. First of all, make sure you have a good, working LFS system with coreutils not failing due to the ACL/ATTR 0-byte file problem.
Then execute this command within the acl-2.2.25 and attr-2.4.47 source trees (changing the version if necessary for the directory name):
The build and install will no longer leave you stranded with a 0-byte shared library file. Both packages use a rather hairy install-sh script dating back to the turn of century from Silicon Graphics (RIP). The problem is the script uses "cp" to install the file. By changing it, via the sed command above to "cp -b", the good, working library is retained during the instant of time that "cp" does the replacement.
When complete, you can then remove the tilde-appended backup files to tidy up.
So, as it turns out, the problem isn't due to the install but due to the script which doesn't even use install at all.
This one also dint work for me but my LFS system is working here is the results after using this above command
Code:
root:/sources/attr-2.4.47# sed -i -e 's|/@pkg_name@|&-@pkg_version@|' include/builddefs.in &&
>
> INSTALL_USER=root \
> INSTALL_GROUP=root \
> ./configure --prefix=/usr --disable-static &&
> make
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
root:/sources/attr-2.4.47# sed -i -e 's|/@pkg_name@|&-@pkg_version@|' include/builddefs.in &&
>
> INSTALL_USER=root \
> INSTALL_GROUP=root \
> ./configure --prefix=/usr --disable-static &&
> make
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
First find your good copy of libacl.so.1 and then place in the /lib directory. Where you may have saved it is unknown to me but you do need it.
Then see post #14 and follow the steps as shown there.
One last thing you can try is to copy libacl.so.1.1.0 from another distro. I copied it from Slackware, and it worked.
I'll also mention that if the /tools directory is still around, you can prepend the PATH so that "/tools/bin" is searched for the core utilities. This will be sufficient to rebuild coreutils without ACL/ATTR per the first step in post #14 of this thread.
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.
Thanks for this instructions now everything is ok thank you so much marking this thread as <solved>
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
here is the op of find -name libacl.so.1.1.0
