LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
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-28-2013, 01:45 PM   #16
Lennie
Member
 
Registered: Aug 2012
Location: Sweden
Distribution: LFS, built with pacman
Posts: 301

Rep: Reputation: 60

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.
 
Old 06-28-2013, 01:50 PM   #17
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 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.

Last edited by re_nelson; 06-28-2013 at 09:07 PM.
 
Old 06-28-2013, 02:01 PM   #18
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
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.

Last edited by re_nelson; 06-28-2013 at 02:13 PM.
 
Old 06-28-2013, 02:39 PM   #19
Lennie
Member
 
Registered: Aug 2012
Location: Sweden
Distribution: LFS, built with pacman
Posts: 301

Rep: Reputation: 60
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...
 
Old 06-28-2013, 02:49 PM   #20
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 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!
 
Old 06-28-2013, 05:17 PM   #21
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
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):

Code:
sed -ie 's/CP=cp/CP="cp -b"/' $(find -name 'install-sh' -exec grep -l 'CP=cp' {} +)
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.

Last edited by re_nelson; 06-28-2013 at 05:18 PM.
 
Old 06-29-2013, 03:48 AM   #22
Lennie
Member
 
Registered: Aug 2012
Location: Sweden
Distribution: LFS, built with pacman
Posts: 301

Rep: Reputation: 60
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.
 
Old 06-29-2013, 07:50 AM   #23
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
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
 
Old 06-29-2013, 08:19 AM   #24
Dinesh Raja
Member
 
Registered: Jun 2013
Location: India
Distribution: Antergos,Ubuntu,LFS
Posts: 31

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Lennie View Post
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

Code:
root:/sources/acl-2.2.51# find -name libacl.so.1.1.0
root:/sources/acl-2.2.51#
 
Old 06-29-2013, 08:22 AM   #25
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
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):

Code:
sed -ie 's/CP=cp/CP="cp -b"/' $(find -name 'install-sh' -exec grep -l 'CP=cp' {} +)
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
 
Old 06-29-2013, 12:53 PM   #26
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
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
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.

Last edited by re_nelson; 06-29-2013 at 01:01 PM.
 
Old 06-29-2013, 02:13 PM   #27
Lennie
Member
 
Registered: Aug 2012
Location: Sweden
Distribution: LFS, built with pacman
Posts: 301

Rep: Reputation: 60
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.
 
Old 06-29-2013, 03:51 PM   #28
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
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.
 
Old 06-29-2013, 10:15 PM   #29
Dinesh Raja
Member
 
Registered: Jun 2013
Location: India
Distribution: Antergos,Ubuntu,LFS
Posts: 31

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Lennie View Post
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.
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
 
Old 06-29-2013, 11:10 PM   #30
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
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>
 
  


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 09:14 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