glibc 2.16 -- just what is supposed to be in /lib now ??
On Tue, Jul 10, 2012 at 11:15 PM, David C. Rankin
<drankinatty@suddenlinkmail.com> wrote:
> Guys,
>
> I have read the recent thread about glibc problems and I am totally
> confused about what I am still supposed to have in /lib...
Nothing, but everything:
Both "/lib" and "/lib64" should be symlinks to "usr/lib". If they are
directories, fix that.
--
Mantas MikulÄ—nas
07-11-2012, 03:52 AM
"David C. Rankin"
glibc 2.16 -- just what is supposed to be in /lib now ??
On 07/10/2012 04:12 PM, Mantas MikulÄ—nas wrote:
> On Tue, Jul 10, 2012 at 11:15 PM, David C. Rankin
> <drankinatty@suddenlinkmail.com> wrote:
>> > Guys,
>> >
>> > I have read the recent thread about glibc problems and I am totally
>> > confused about what I am still supposed to have in /lib...
> Nothing, but everything:
> Both "/lib" and "/lib64" should be symlinks to "usr/lib". If they are
> directories, fix that.
OK,
So then since /lib is very much still a directory and not a symlink, then I
should:
... and the kernel modules for the running kernel ending up in /usr/lib/modules
and udev ending up in /usr/lib/udev -- are all OK with this? And what is /usr
and /lib as _separate_ partitions on the main box? softlinks won't work across
partition boundaries -- so what then?
--
David C. Rankin, J.D.,P.E.
07-11-2012, 04:32 AM
Tom Gundersen
glibc 2.16 -- just what is supposed to be in /lib now ??
On Wed, Jul 11, 2012 at 5:52 AM, David C. Rankin
<drankinatty@suddenlinkmail.com> wrote:
> So then since /lib is very much still a directory and not a symlink, then I
> should:
First, notice that /lib as a symlink is only in testing so far, so
that might explain why you haven't seen it yet. It could be that your
problem is unrelated...
You probably want to be a bit more careful in order to make sure that
the pacman db is not out of sync. That is, check who owns the files in
/lib, if they are owned by glibc leave them alone, if they are owned
by packages, then rebuild and reinstall the packages with the files in
/usr/lib instead, if they are not owned by anyone then move them over
manually as you described. Once that is done, you should be able to
"pacman -S glibc" and it should create the symlink for you. Also check
Allan's last email to dev-public, it is probably explained better
there.
> ... and the kernel modules for the running kernel ending up in /usr/lib/modules
> and udev ending up in /usr/lib/udev -- are all OK with this?
All official packages have their modules in /usr/lib/modules and their
udev rules in /usr/lib/udev, in fact modules in /lib/modules will no
longer work (if you are using testing).
> And what is /usr
> and /lib as _separate_ partitions on the main box? softlinks won't work across
> partition boundaries -- so what then?
Softlinks work across filesystem boundaries, no problem.
-t
07-11-2012, 05:47 AM
David Benfell
glibc 2.16 -- just what is supposed to be in /lib now ??
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/10/12 20:52, David C. Rankin wrote:
> And what is /usr and /lib as _separate_ partitions on the main box?
> softlinks won't work across partition boundaries -- so what then?
Tom is right. You're thinking of *hard* links, which I think don't
work for directories anyway (though I saw some discussion about
changing that).
- --
David Benfell
benfell@parts-unknown.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
glibc 2.16 -- just what is supposed to be in /lib now ??
> Tom is right. You're thinking of *hard* links, which I think don't
> work for directories anyway (though I saw some discussion about
> changing that).
>
You are correct. Hard links must link to another item within the current
partition/volume and cannot cross over, however soft/symbolic links can.
Last time I checked, Apple's file system is the only one that can Hard Link
a directory.
07-11-2012, 04:44 PM
Mantas MikulÄ—nas
glibc 2.16 -- just what is supposed to be in /lib now ??
On Wed, Jul 11, 2012 at 6:57 PM, Squall Lionheart
<headmastersquall@gmail.com> wrote:
>> Tom is right. You're thinking of *hard* links, which I think don't
>> work for directories anyway (though I saw some discussion about
>> changing that).
>>
>
> You are correct. Hard links must link to another item within the current
> partition/volume and cannot cross over, however soft/symbolic links can.
> Last time I checked, Apple's file system is the only one that can Hard Link
> a directory.
(...but cannot hardlink files in a sane way.)
ext4 supports hardlinked directories, can be done using `debugfs` –
Linux just disallows that in link() currently.
--
Mantas MikulÄ—nas
07-11-2012, 05:00 PM
Squall Lionheart
glibc 2.16 -- just what is supposed to be in /lib now ??
> (...but cannot hardlink files in a sane way.)
>
> ext4 supports hardlinked directories, can be done using `debugfs` –
> Linux just disallows that in link() currently.
>
Thank you Mantas for the info. I'm having a hard time finding information
on how to create a hard link on a directory, if you have any resources you
can provide that would be very helpful.
07-11-2012, 06:52 PM
"David C. Rankin"
glibc 2.16 -- just what is supposed to be in /lib now ??
On 07/11/2012 12:00 PM, Squall Lionheart wrote:
(...but cannot hardlink files in a sane way.)
ext4 supports hardlinked directories, can be done using `debugfs` –
Linux just disallows that in link() currently.
Thank you Mantas for the info. I'm having a hard time finding information
on how to create a hard link on a directory, if you have any resources you
can provide that would be very helpful.
Double thanks to Tom, David, Mantas, Squall, and all who responded. I now have
a better appreciation for where my install is (no testing pkgs) and the /lib
-> /usr/lib linking that I will expect in the future. As for the original
rpcgen error, that is still in work and I'll keep digging.
I have a much better appreciation of all the hard work you guys put in keeping
Arch the most current distro in use.
glibc 2.16 -- just what is supposed to be in /lib now ??
