| To: | Seth Mos <knuffie@xxxxxxxxx> |
|---|---|
| Subject: | Re: TAKE - userspace |
| From: | Alan Eldridge <alane@xxxxxxxxxxxx> |
| Date: | Sat, 21 Jul 2001 16:52:08 -0400 |
| In-reply-to: | <4.3.2.7.2.20010721222837.031d7178@pop.xs4all.nl>; from knuffie@xs4all.nl on Sat, Jul 21, 2001 at 10:36:19PM +0200 |
| References: | <200107200826.SAA36970@snort.melbourne.sgi.com> <200107200826.SAA36970@snort.melbourne.sgi.com> <15O37C-1kawUrC@fwd01.sul.t-online.com> <4.3.2.7.2.20010721222837.031d7178@pop.xs4all.nl> |
| Sender: | owner-linux-xfs@xxxxxxxxxxx |
| User-agent: | Mutt/1.2.5i |
On Sat, Jul 21, 2001 at 10:36:19PM +0200, Seth Mos wrote: >>What is the reason for putting libacl.a in /lib instead of leaving it in >>/usr/lib where it belongs IMHO ? >>This breaks all applications that try to link libacl.a at compiletime like >>Samba and Fileutils. Please move it back. > >NO! > >If you only have your root filesystem, how would you then be able to run >xfsdump or xfsrestore. >let's see. D'ya think making the xfs* utils statically linked is a good compromise? Then the libs could go back in /usr/lib. PS I understand your point. How about Sun, where, for years, /bin => /usr/bin. Auuuggghhh!!!! -- Alan Eldridge from std_disclaimer import * |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: TAKE - userspace, Juergen Hasch |
|---|---|
| Next by Date: | Re: TAKE - userspace, John Trostel |
| Previous by Thread: | Re: TAKE - userspace, Nathan Scott |
| Next by Thread: | Re: TAKE - userspace, John Trostel |
| Indexes: | [Date] [Thread] [Top] [All Lists] |