Error while loading shared libraries
 

Hello,i have completed LFS and started BLFS and while installing attr i am getting the following error

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:

so no other fix??

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

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.

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.

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.

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:
I have stripped all packages (except acl in this experiment), and I remove all .la files.

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.

I tried recompiling as mentioned here http://www.linuxfromscratch.org/lfs/...coreutils.html but i am getting the following error


Additional Info:
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.

It seems this borked the system completely... I tried to recompile coreutils, but got the same error.
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.

That's good to know since at least three of us have come across it.

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.

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'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.
Use Live cd and copy it to your system. It worked in my chroot.

Thanks for this nelson but still i couldn't fix the problem here comes my results

I am not having acl build directory :( here is the op of find -name libacl.so.1.1.0

This one also dint work for me :( but my LFS system is working here is the results after using this above command

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.

Thank you so much Lennie i used libacl.so.1.1.0 and few libraries from my Antergos and finally its working no more ld error :)
Feeling Up :)

Thanks for this instructions now everything is ok thank you so much marking this thread as <solved>

On behalf of Lennie, a key participant in this thread, you're very welcome. I'll just add that problems like these are part of the growing pains with Linux from Scratch (and BLFS). I've had a number of such problems through the years and several times was ready to give up, take the easy way out and stick with a pre-made distribution. But each one of these little battle scars has only served to enhance my knowledge.

Glad it all worked out! :)

:) I too planned to give it up and start LFS again but atlast it worked :) Feeling happy Thank you for the guidance! :)