LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Linux From Scratch
User Name
Password
Linux From Scratch This 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

Reply
 
Search this Thread
Old 06-27-2013, 11:05 AM   #1
Dinesh Raja
Member
 
Registered: Jun 2013
Location: India
Distribution: Antergos,Ubuntu,LFS
Posts: 31

Rep: Reputation: Disabled
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!
 
Old 06-27-2013, 11:51 AM   #2
re_nelson
Member
 
Registered: Oct 2011
Location: Texas, USA
Distribution: LFS-SVN, Gentoo-2.2 ~amd64, CentOS-6.5, Slackware64-current, FreeBSD-9.2-STABLE
Posts: 176

Rep: Reputation: Disabled
Quote:
Originally Posted by Dinesh Raja View Post
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

Last edited by re_nelson; 06-27-2013 at 11:56 AM.
 
Old 06-27-2013, 11:55 AM   #3
Dinesh Raja
Member
 
Registered: Jun 2013
Location: India
Distribution: Antergos,Ubuntu,LFS
Posts: 31

Original Poster
Rep: Reputation: Disabled
Unhappy

Quote:
Originally Posted by re_nelson View Post
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??
 
Old 06-27-2013, 11:58 AM   #4
re_nelson
Member
 
Registered: Oct 2011
Location: Texas, USA
Distribution: LFS-SVN, Gentoo-2.2 ~amd64, CentOS-6.5, Slackware64-current, FreeBSD-9.2-STABLE
Posts: 176

Rep: Reputation: Disabled
Quote:
Originally Posted by Dinesh Raja View Post
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.
 
Old 06-27-2013, 12:00 PM   #5
Dinesh Raja
Member
 
Registered: Jun 2013
Location: India
Distribution: Antergos,Ubuntu,LFS
Posts: 31

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by re_nelson View Post
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
 
Old 06-27-2013, 12:10 PM   #6
re_nelson
Member
 
Registered: Oct 2011
Location: Texas, USA
Distribution: LFS-SVN, Gentoo-2.2 ~amd64, CentOS-6.5, Slackware64-current, FreeBSD-9.2-STABLE
Posts: 176

Rep: Reputation: Disabled
Quote:
Originally Posted by Dinesh Raja View Post
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.
 
Old 06-27-2013, 01:11 PM   #7
Lennie
Member
 
Registered: Aug 2012
Location: Sweden
Distribution: LFS, built with pacman
Posts: 301

Rep: Reputation: 60
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’
 
Old 06-27-2013, 01:17 PM   #8
re_nelson
Member
 
Registered: Oct 2011
Location: Texas, USA
Distribution: LFS-SVN, Gentoo-2.2 ~amd64, CentOS-6.5, Slackware64-current, FreeBSD-9.2-STABLE
Posts: 176

Rep: Reputation: Disabled
Quote:
Originally Posted by re_nelson View Post
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.
 
Old 06-27-2013, 01:26 PM   #9
re_nelson
Member
 
Registered: Oct 2011
Location: Texas, USA
Distribution: LFS-SVN, Gentoo-2.2 ~amd64, CentOS-6.5, Slackware64-current, FreeBSD-9.2-STABLE
Posts: 176

Rep: Reputation: Disabled
Quote:
Originally Posted by Lennie View Post
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.
 
Old 06-28-2013, 02:08 AM   #10
Lennie
Member
 
Registered: Aug 2012
Location: Sweden
Distribution: LFS, built with pacman
Posts: 301

Rep: Reputation: 60
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?
 
Old 06-28-2013, 11:05 AM   #11
Lennie
Member
 
Registered: Aug 2012
Location: Sweden
Distribution: LFS, built with pacman
Posts: 301

Rep: Reputation: 60
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.
 
Old 06-28-2013, 11:19 AM   #12
re_nelson
Member
 
Registered: Oct 2011
Location: Texas, USA
Distribution: LFS-SVN, Gentoo-2.2 ~amd64, CentOS-6.5, Slackware64-current, FreeBSD-9.2-STABLE
Posts: 176

Rep: Reputation: Disabled
Quote:
Originally Posted by Lennie View Post
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.
 
Old 06-28-2013, 11:53 AM   #13
Dinesh Raja
Member
 
Registered: Jun 2013
Location: India
Distribution: Antergos,Ubuntu,LFS
Posts: 31

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by re_nelson View Post
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.
 
Old 06-28-2013, 12:28 PM   #14
re_nelson
Member
 
Registered: Oct 2011
Location: Texas, USA
Distribution: LFS-SVN, Gentoo-2.2 ~amd64, CentOS-6.5, Slackware64-current, FreeBSD-9.2-STABLE
Posts: 176

Rep: Reputation: Disabled
Quote:
Originally Posted by Dinesh Raja View Post
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.

Last edited by re_nelson; 06-28-2013 at 12:30 PM.
 
Old 06-28-2013, 01:16 PM   #15
Lennie
Member
 
Registered: Aug 2012
Location: Sweden
Distribution: LFS, built with pacman
Posts: 301

Rep: Reputation: 60
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.

Last edited by Lennie; 06-28-2013 at 01:20 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
error while loading shared libraries: libgda-4.0.so.4: cannot open shared object file mahesh1234 Linux - Newbie 2 10-22-2013 11:06 PM
honeyd: error while loading shared libraries: libdnet.1: cannot open shared object fi secbuddy Linux - Software 2 12-24-2011 02:01 PM
error while loading shared libraries: libtermcap.so.2: cannot open shared object file astroboy2000ir Linux - Software 3 12-07-2010 11:16 PM
error while loading shared libraries: libgvc.so.3: cannot open shared object file coolrock Slackware 6 01-17-2007 05:10 PM
error while loading shared libraries: libdb-4.1.so: cannot open shared object file putquery8581 Linux - Software 1 10-01-2004 07:03 AM


All times are GMT -5. The time now is 04:45 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration