LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux From Scratch (http://www.linuxquestions.org/questions/linux-from-scratch-13/)
-   -   Error while loading shared libraries (http://www.linuxquestions.org/questions/linux-from-scratch-13/error-while-loading-shared-libraries-4175467600/)

Dinesh Raja 06-27-2013 11:05 AM

Error while loading shared libraries
 
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 (Post 4979674)
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 (Post 4979700)
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 (Post 4979703)
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 (Post 4979707)
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 (Post 4979710)
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 (Post 4979715)
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 (Post 4979758)
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 (Post 4980068)
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 (Post 4980313)
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 (Post 4980328)
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.


All times are GMT -5. The time now is 04:43 AM.