[SOLVED] Error while loading shared libraries

Dinesh Raja · 06-27-2013, 11:05 AM

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!

re_nelson · 06-27-2013, 11:51 AM

Quote:

Originally Posted by Dinesh Raja

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:

Code:

install ./libacl/.libs/libacl.so.1.1.0 /lib

Dinesh Raja · 06-27-2013, 11:55 AM

Quote:

Originally Posted by re_nelson

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.

so no other fix??

re_nelson · 06-27-2013, 11:58 AM

Quote:

Originally Posted by Dinesh Raja

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.

Dinesh Raja · 06-27-2013, 12:00 PM

Quote:

Originally Posted by re_nelson

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

re_nelson · 06-27-2013, 12:10 PM

Quote:

Originally Posted by Dinesh Raja

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.

Lennie · 06-27-2013, 01:11 PM

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.

Code:

grep libacl.so build.log 

libtool: link: gcc -shared  -fPIC -DPIC  .libs/acl_add_perm.o .libs/acl_calc_mask.o .libs/acl_clear_perms.o .libs/acl_copy_entry.o .libs/acl_copy_ext.o .libs/acl_copy_int.o .libs/acl_create_entry.o .libs/acl_delete_def_file.o .libs/acl_delete_entry.o .libs/acl_delete_perm.o .libs/acl_dup.o .libs/acl_free.o .libs/acl_from_text.o .libs/acl_get_entry.o .libs/acl_get_fd.o .libs/acl_get_file.o .libs/acl_get_perm.o .libs/acl_get_permset.o .libs/acl_get_qualifier.o .libs/acl_get_tag_type.o .libs/acl_init.o .libs/acl_set_fd.o .libs/acl_set_file.o .libs/acl_set_permset.o .libs/acl_set_qualifier.o .libs/acl_set_tag_type.o .libs/acl_to_text.o .libs/acl_valid.o .libs/acl_size.o .libs/acl_to_any_text.o .libs/acl_entries.o .libs/acl_check.o .libs/acl_error.o .libs/acl_cmp.o .libs/acl_extended_fd.o .libs/acl_extended_file.o .libs/acl_equiv_mode.o .libs/acl_from_mode.o .libs/acl_extended_file_nofollow.o .libs/__acl_extended_file.o .libs/__acl_to_any_text.o .libs/__acl_to_xattr.o .libs/__acl_from_xattr.o .libs/__acl_reorder_obj_p.o .libs/__libobj.o .libs/__apply_mask_to_mode.o .libs/perm_copy_fd.o .libs/perm_copy_file.o  -Wl,--whole-archive ../libmisc/.libs/libmisc.a -Wl,--no-whole-archive  -lattr  -Wl,--version-script -Wl,../exports   -Wl,-soname -Wl,libacl.so.1 -o .libs/libacl.so.1.1.0
libtool: link: (cd ".libs" && rm -f "libacl.so.1" && ln -s "libacl.so.1.1.0" "libacl.so.1")
libtool: link: (cd ".libs" && rm -f "libacl.so" && ln -s "libacl.so.1.1.0" "libacl.so")
libtool: link: gcc -o .libs/chacl chacl.o  ../libacl/.libs/libacl.so -lattr
libtool: link: gcc -o .libs/getfacl getfacl.o user_group.o  ../libmisc/.libs/libmisc.a ../libacl/.libs/libacl.so -lattr
libtool: link: gcc -o .libs/setfacl setfacl.o do_set.o sequence.o parse.o  ../libmisc/.libs/libmisc.a ../libacl/.libs/libacl.so -lattr
cd ../libacl/.libs; ../../include/install-sh -o root -g root -m 755 -d /usr/lib; ../../include/install-sh -o root -g root -m 644 -T old_lib libacl.lai /usr/lib; ../../include/install-sh -o root -g root -m 644 libacl.lai /usr/lib/libacl.la ; ../../include/install-sh -o root -g root -m 755 -d /lib; ../../include/install-sh -o root -g root -T so_base libacl.lai /lib; if test "x/usr/lib" != "x/lib" ; then ../../include/install-sh -o root -g root -S /usr/lib/libacl.a /lib/libacl.a; ../../include/install-sh -o root -g root -S /usr/lib/libacl.la /lib/libacl.la; ../../include/install-sh -o root -g root -S /lib/libacl.so /usr/lib/libacl.so; fi
mode of ‘/packages/build/blfs/before_xorg/acl/pkg/acl/lib/libacl.so.1.1.0’ changed from 0644 (rw-r--r--) to 0755 (rwxr-xr-x)
removed ‘/packages/build/blfs/before_xorg/acl/pkg/acl/lib/libacl.so’
‘/packages/build/blfs/before_xorg/acl/pkg/acl/usr/lib/libacl.so’ -> ‘../../lib/libacl.so.1’

re_nelson · 06-27-2013, 01:17 PM

Quote:

Originally Posted by re_nelson

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.

re_nelson · 06-27-2013, 01:26 PM

Quote:

Originally Posted by Lennie

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.

Lennie · 06-28-2013, 02:08 AM

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?

Lennie · 06-28-2013, 11:05 AM

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.

re_nelson · 06-28-2013, 11:19 AM

Quote:

Originally Posted by Lennie

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.

Dinesh Raja · 06-28-2013, 11:53 AM

Quote:

Originally Posted by re_nelson

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

Code:

 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,

please help me to fix this problem.

re_nelson · 06-28-2013, 12:28 PM

Quote:

Originally Posted by Dinesh Raja

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.

Lennie · 06-28-2013, 01:16 PM

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.