[Solved]/usr/lib/libGL.so.1 symlink keeps changing on package installs

Hello,
I recently switched my desktop from using the proprietary nvidia drivers to nouveau. After doing so, I experienced seg faults in many applications (emacs, xfce4-session). I tracked down the problem to be caused by the /usr/lib/libGL.so.1 symlink pointing to the wrong file. I noticed that if I looked in /usr/lib, I would see libGL.so.1 -> libGL.so.190.42 when in fact it should have been pointing to mesa-libGL.so.1.2.0.  ( https://bbs.archlinux.org/viewtopic.php?id=174663 )
Changing the symlink by hand ( sudo ln -sf mesa-libGL.so.1.2.0 libGL.so.1 ) makes everything work again, but every time I install something new the symlink goes back to libGL.so.190.42.
What is causing this symlink to change on every package install and how can I stop this from happening?
Thanks!
Last edited by mikej_96 (2013-12-23 21:25:19)

Oh wow - how can this even happen?
I verified that the libGL.so.1 symlink was correct:
ls -lah libGL.so*
lrwxrwxrwx 1 root root 19 Dec 13 12:12 libGL.so -> mesa-libGL.so.1.2.0
lrwxrwxrwx 1 root root 19 Dec 23 14:20 libGL.so.1 -> mesa-libGL.so.1.2.0
lrwxrwxrwx 1 root root 19 Dec 13 12:12 libGL.so.1.2.0 -> mesa-libGL.so.1.2.0
-rwxr-xr-x 1 root root 775K Aug 29 2009 libGL.so.185.18.36
-rwxr-xr-x 1 root root 906K Oct 25 2009 libGL.so.190.42
Then rename the 'bad' libGL file.
$ mv libGL.so.190.42 libGL.so.190.42.why_is_this_here
Then, re-install archlinux wallpaper
$ pacman -S archlinux-wallpaper
warning: archlinux-wallpaper-1.4-1 is up to date -- reinstalling
resolving dependencies...
looking for inter-conflicts...
Packages (1):
Name Old Version New Version Net Change
extra/archlinux-wallpaper 1.4-1 1.4-1 0.00 MiB
Total Installed Size: 11.78 MiB
Net Upgrade Size: 0.00 MiB
:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring [################################] 100%
(1/1) checking package integrity [################################] 100%
(1/1) loading package files [################################] 100%
(1/1) checking for file conflicts [################################] 100%
(1/1) reinstalling archlinux-wallpaper [################################] 100%
Then check the symlink again
$ ls -lah libGL.so*
lrwxrwxrwx 1 root root 19 Dec 13 12:12 libGL.so -> mesa-libGL.so.1.2.0
lrwxrwxrwx 1 root root 32 Dec 23 14:16 libGL.so.1 -> libGL.so.190.42.why_is_this_here
lrwxrwxrwx 1 root root 19 Dec 13 12:12 libGL.so.1.2.0 -> mesa-libGL.so.1.2.0
-rwxr-xr-x 1 root root 775K Aug 29 2009 libGL.so.185.18.36
-rwxr-xr-x 1 root root 906K Oct 25 2009 libGL.so.190.42.why_is_this_here
It moved back to the unwanted libGL file.

Similar Messages

  • File conflict, libgl-dr: /usr/lib/libGL.so.1

    I am trying to upgrade xorg but whenever I pacman -S xorg, I get the following error
    error: the following file conflicts were found:
    libgl-dri: /usr/lib/libGL.so.1: exists in filesystem
    I was wondering if anyone new how to fix this problem.
    Thanks

    schultz wrote:
    Yep... That was a problem fixer...
    Problably more to come...  :cry:
    Unfortunaly I was right...  new problems... Stupid Xorg7...

  • [SOLVED]/usr/lib/arch-tempfiles line 106: install:command not found

    Hi everyone!
    This is my boot.log
    http://pastebin.com/1gfynhSN
    It says"/usr/lib/initscripts/arch-tmpfiles:line 106: install:command not found".This is leading to problems such as dbus and network manager not being started(even manually),no shutdown option,not able to 'open' log files without sudo  etc.
    I think a possible reason for this is that I had messed up with symlinks.I had issued the command
    sudo ln -s /bin/install /usr/bin/install
    .Then I had used
    cd /bin/
    unlink install
    Now,I find that /bin/install and /usr/bin/install does not exist.(I have deleted them!) .How can I fix this up?Any help would be appreciated.
    Last edited by adwaita45 (2012-04-05 20:41:40)

    Reinstall coreutils (or manually extract install from the package and put it in /usr/bin).
    Last edited by Raynman (2012-04-05 18:14:10)

  • [Solved]/usr/lib/libwx_gtk2u_core-2.8.so.0 is truncated

    Since before I can remember I've had the following output after installing anything from pacman:
    /sbin/ldconfig: file /usr/lib/libwx_gtk2u_stc-2.8.so.0.1.1 is truncated
    /sbin/ldconfig: file /usr/lib/libwx_gtk2u_stc-2.8.so is truncated
    /sbin/ldconfig: file /usr/lib/libwx_gtk2u_core-2.8.so is truncated
    /sbin/ldconfig: file /usr/lib/libwx_gtk2u_stc-2.8.so.0 is truncated
    /sbin/ldconfig: file /usr/lib/libwx_gtk2u_core-2.8.so.0.1.1 is truncated
    /sbin/ldconfig: file /usr/lib/libwx_gtk2u_core-2.8.so.0 is truncated
    /sbin/ldconfig: file /usr/lib/libwx_gtk2u_stc-2.8.so.0.1.1 is truncated
    /sbin/ldconfig: file /usr/lib/libwx_gtk2u_stc-2.8.so is truncated
    /sbin/ldconfig: file /usr/lib/libwx_gtk2u_core-2.8.so is truncated
    /sbin/ldconfig: file /usr/lib/libwx_gtk2u_stc-2.8.so.0 is truncated
    /sbin/ldconfig: file /usr/lib/libwx_gtk2u_core-2.8.so.0.1.1 is truncated
    /sbin/ldconfig: file /usr/lib/libwx_gtk2u_core-2.8.so.0 is truncated
    I hoped it would be ok to forget about it, but no such luck. Now I'm trying to compile amule-cvs from yaourt:
    /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../libwx_gtk2u_core-2.8.so: file not recognized
    Compilation then stops. So, are the two problems related? I've tried the main amule package in extra for the time being, but when I run it I get 'bus error' from the console, so I really would like the cvs version.
    Last edited by shadeheim (2007-10-16 20:57:10)

    The files are owned by wxgtk-2, so I just made sure all the corrupt versions of the package were removed from my cache.
    sudo rm /var/cache/pacman/pkg/wxgtk-2.*
    Then do a 'pacman -Sy wxgtk' and choose to upgrade if need be. If all goes well you will no longer get the warnings from pacman, and both the binary and cvs packages will install and run fine.
    Last edited by shadeheim (2007-10-16 20:56:54)

  • [SOLVED] /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.18' not found

    I got fed up typing the password every time I push some files to a server with scp, as I do it a lot with this project. Public/private key pair is not really an option (read: I do not want to send anything else but the web app files to the server) as the host is not my own, nor it is my client's. Instead it is my client's client's host.
    So I installed filezilla. And got this:
    > filezilla
    filezilla: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by filezilla)
    I did a quick pacman -Syu as always, and the error still comes up.
    > strings /usr/lib/libstdc++.so.6 | grep GLIBCXX
    GLIBCXX_3.4
    GLIBCXX_3.4.1
    GLIBCXX_3.4.2
    GLIBCXX_3.4.3
    GLIBCXX_3.4.4
    GLIBCXX_3.4.5
    GLIBCXX_3.4.6
    GLIBCXX_3.4.7
    GLIBCXX_3.4.8
    GLIBCXX_3.4.9
    GLIBCXX_3.4.10
    GLIBCXX_3.4.11
    GLIBCXX_3.4.12
    GLIBCXX_3.4.13
    GLIBCXX_3.4.14
    GLIBCXX_3.4.15
    GLIBCXX_3.4.16
    GLIBCXX_3.4.17
    GLIBCXX_DEBUG_MESSAGE_LENGTH
    Now what?
    Perhaps some alternatives? What's your favorite GUI FTP client? Mine's WinSCP, but it's only for windows AFAIK.
    I have used gFTP in the past, but the gui design is just horrible. For example ctrl+v is some key binding to do something else than paste from clipboard. And then there is no drag&drop. It also crashes if I open more than one file to edit at the same time. All these little details drive me nuts with gFTP.
    Last edited by Lazzu (2013-10-14 16:23:23)

    ~ > pacman -Qo /usr/lib/libstdc++.so.6
    /usr/lib/libstdc++.so.6 is owned by gcc-libs 4.8.1-3
    ~ > strings /usr/lib/libstdc++.so.6 | grep GLIBCXX
    GLIBCXX_3.4
    GLIBCXX_3.4.1
    GLIBCXX_3.4.2
    GLIBCXX_3.4.3
    GLIBCXX_3.4.4
    GLIBCXX_3.4.5
    GLIBCXX_3.4.6
    GLIBCXX_3.4.7
    GLIBCXX_3.4.8
    GLIBCXX_3.4.9
    GLIBCXX_3.4.10
    GLIBCXX_3.4.11
    GLIBCXX_3.4.12
    GLIBCXX_3.4.13
    GLIBCXX_3.4.14
    GLIBCXX_3.4.15
    GLIBCXX_3.4.16
    GLIBCXX_3.4.17
    GLIBCXX_3.4.18
    GLIBCXX_3.4.19
    GLIBCXX_DEBUG_MESSAGE_LENGTH
    Is your system fully up to date?

  • [SOLVED] /usr/lib/aspell-0.60/xray.cset does not exist...

    Update:
    I'd still like to understand what this /usr/lib/aspell-0.60/xray.cset file is all about. But apearantly I don't really need it. I fired up my xubuntu installation to spellcheck the LyX document. And because the  ~/.aspell.en.pws on Arch had more added words in it I was about to copy it over the Xubuntu copy... Fortunately I compared them first and noticed that the working Xubuntu  ~/.aspell.en.pws  was a 212 line file beginning with "personal_ws-1.1 en 211" (evidently reflecting the number of words @ 1 per line) while the broken ~/.aspell.en.pws on Arch was a 299 line file beginning with "personal_ws-1.1 en 299 xray" Considering I had recently deleted one word/line from it the only part that didn't make sense was the word xray... changed that line to "personal_ws-1.1 en 298" and aspell is working again.
    But I still don't know where the word "xray" came from, nor why aspell thought it meant there should be an "/usr/lib/aspell-0.60/xray.cset" file... ???????
    End Update (Original post below)
    I think I did something stupid... And it broke aspell.
    What I did was: I was spellchecking a LyX document (which uses aspell) and
    I accidentally added a misspelled word. Whenever I've done that in the past
    I simply opened my ~/.aspell.en.pws with vim, and deleted the misspelled
    word from the list. But this time I'd been using aspell indirectly and
    while I closed LyX's pop-up spellchecking utility before I switched to a
    terminal window, I didn't close LyX itself. (I didn't think it would matter
    as long as it wasn't actively spellchecking at the time...) Well I got rid
    of the misspelled word OK. When I switched back to LyX every thing seemed
    to work normally until I pressed <F7> to start up the spellchecker again.
    At that point LyX crashed...
    When I try to use aspell from the command line in a terminal window I get
    this:
    JtWdyP -> /home/jtwdyp/tmp
    >
    JtWdyP -> /home/jtwdyp/tmp
    > echo "test txt a tst file" > test.txt
    JtWdyP -> /home/jtwdyp/tmp
    > aspell -c test.txt
    Unhandled Error: The encoding "xray" is not known. This could also mean that the file "/usr/lib/aspell-0.60/xray.cset" could not be opened for reading or does not exist.
    Aborted
    JtWdyP -> /home/jtwdyp/tmp
    > ls /usr/lib/aspell-0.60/xray.cset
    ls: cannot access /usr/lib/aspell-0.60/xray.cset: No such file or directory
    JtWdyP -> /home/jtwdyp/tmp
    >
    I've tried logging into my root account and:
    UnderTree =->
    UnderTree =-> pacman -S aspell
    warning: aspell-0.60.6-4 is up to date -- reinstalling
    resolving dependencies...
    looking for inter-conflicts...
    Targets (1): aspell-0.60.6-4
    Total Download Size: 0.00 MB
    Total Installed Size: 3.79 MB
    Proceed with installation? [Y/n] y
    checking package integrity...
    (1/1) checking for file conflicts [##########################] 100%
    (1/1) upgrading aspell [##########################] 100%
    UnderTree =->
    But aspell still fails with the same error, and the file:
    /usr/lib/aspell-0.60/xray.cset
    still doesn't exist...
    Next it occurred to me that for all I know, reinstalling with "pacman -S"
    might not be as complete as installing a new package so I thought that if I
    removed aspell first, I might be able to get a cleaner install...
    UnderTree =->
    UnderTree =-> pacman -R aspell
    checking dependencies...
    error: failed to prepare transaction (could not satisfy dependencies)
    :: aspell-en: requires aspell
    :: enchant: requires aspell
    :: lyx: requires aspell
    UnderTree =->
    I'm not so sure I want to remove enchant & lyx to test that theory...
    So I guess I gotta ask, how do I go about getting a replacement
    "/usr/lib/aspell-0.60/xray.cset" file????
    jtwdyp
    J(tWdy)P
    Joe(theWordy)Philbrook
    Last edited by jtwdyp (2010-11-10 17:20:19)

    ukhippo wrote:Have you tried using “-t nat” instead of “-t NAT” in your iptables command?
    I hate you, and I love you (with emphasis on the love)...
    That did it, stupid spelling mistake trying to use NAT, bah Thank you!
    Last edited by Torxed (2014-06-04 17:52:07)

  • Not yet solved, /usr/lib/systemd/systemd does not exit

    Hi,
    I was on 3.8.2 kernel, and did a full system backup with rsync to later upgrade, but after upgrading and rebooting, it just shows me
    Error: Root device mounted successfully, but /bin/systemd does not exist.
    Bailing out, you are on your own. Good Luck
    tty's could not initialize [*or something similar, I'm not sure]
    [root /]#
    Then I just replaced my system with the backup I did earlier. But it shows the same
    I did search for info but no clue.
    Currently trying with an older backup.
    Thanks in advance
    Last edited by arcaid (2013-05-14 23:58:26)

    progandy wrote:
    Error: Root device mounted successfully, but /usr/lib/systemd/systemd does not exist.
    The initscript tests if init is executable, so "does not exist" could also mean "is not executable"
    Somehow your root has a problem with its execute permissions. Did you somehow remove them, /usr/lib/systemd/systemd should be 755 or "-rwxr-xr-x"?
    While I'm not sure why is this modified, maybe the backups I did doesn't hold the attributes, I'm storing them in an NTFS partition but it can store the attributes doesn't it?
    Well I changed the attributes as you mentioned, but then it makes me wonder if then pretty much the other root files are too with other attributes..which is really bad.
    Nevertheless I changed it and now it shows permission denied and a kernel panic, sigh.
    Here is an image of it: http://imageshack.us/photo/my-images/689/dsc06698b.jpg
    Thanks in advance
    @Pantera
    The problem here is kinda different, while at the beggining it was the problem you mention and solution, now the thing is that it says that "/usr/lib/systemd/systemd does not exit" and not /bin/systemd which it was in the beggining. thanks though.

  • [SLVD] force using /usr/lib/xorg/modules/updates/extensions/libglx.so

    Latest versions of catalyst bring powerXpress support - it means that we can now switch between discreet AMD gfx driver and integrated intel gfx driver (and maybe also switch between catalyst and ati oss driver).
    I'm working on it now, unfortunatelly it's not that easy to implement in a right way in Arch. There's no way without doing some ugly tricks (like creating /usr/X11R6 dir). Although i must say that i almost succeeded.
    Yes, i know that /usr/X11R6/lib is obsolete and not supported by Arch, but i must to place catalyst's libGL.so somewhere so it wouldn't conflict with libgl's libGL.so (+ more important is to be able to update libgl package without problems), and that directory is looking good.
    Basically this whole powerXpress suport = linking libGL and libglx libraries into right place. Let me show you some functions:
    switching libGL:
    function switch_to_amd() {
    ln -snf /usr/X11R6/lib/fglrx/fglrx-libGL.so.1.2 \
    /usr/X11R6/lib/libGL.so.1.2
    ln -snf libGL.so.1.2 /usr/X11R6/lib/libGL.so.1
    ln -snf libGL.so.1 /usr/X11R6/lib/libGL.so
    ldconfig /usr/X11R6/lib
    function switch_to_intel() {
    ln -snf /usr/lib/libGL.so.1.2 \
    /usr/X11R6/lib/libGL.so.1.2
    ln -snf libGL.so.1.2 /usr/X11R6/lib/libGL.so.1
    ln -snf libGL.so.1 /usr/X11R6/lib/libGL.so
    ldconfig /usr/X11R6/lib
    switching libglx:
    function switch_to_amd() {
    ln -snf /usr/lib/xorg/modules/updates/extensions/fglrx/fglrx-libglx.so \
    /usr/lib/xorg/modules/updates/extensions/libglx.so
    function switch_to_intel() {
    ln -snf /usr/lib/xorg/modules/extensions/libglx.so \
    /usr/lib/xorg/modules/updates/extensions/libglx.so
    I've created /etc/ld.so.conf.d/catalyst.conf with:
    /usr/X11R6/lib
    inside. I've also added /usr/X11R6/lib into PATH in /etc/profile in 1st place (just in case).
    And it's working fine (i mean catalyst is working fine) untill i will install libgl (so it's not fine)... After restart, when running X server screen goes blank and i cannot do anything (even when it's switched to amd). /var/log/Xorg.0.log looks fine, no errors, it's longer than usuall with those lines:
    [ 2515.883] (II) Power Button: Close
    [ 2515.883] (II) UnloadModule: "evdev"
    [ 2515.883] (II) Unloading evdev
    [ 2515.895] (II) Power Button: Close
    [ 2515.895] (II) UnloadModule: "evdev"
    [ 2515.895] (II) Unloading evdev
    [ 2515.911] (II) My keyboard: Close
    [ 2515.911] (II) UnloadModule: "evdev"
    [ 2515.911] (II) Unloading evdev
    [ 2515.926] (II) My keyboard: Close
    [ 2515.926] (II) UnloadModule: "evdev"
    [ 2515.926] (II) Unloading evdev
    [ 2515.942] (II) My Mouse: Close
    [ 2515.942] (II) UnloadModule: "evdev"
    [ 2515.942] (II) Unloading evdev
    [ 2515.947] (II) fglrx(0): Shutdown CMMQS
    [ 2515.948] (II) fglrx(0): [uki] removed 1 reserved context for kernel
    [ 2515.948] (II) fglrx(0): [uki] unmapping 8192 bytes of SAREA 0x2000 at 0x7fdc4f862000
    [ 2515.962] (II) fglrx(0): Interrupt handler Shutdown.
    but it doesn't look relevant.
    I don't know is it:
    - /usr/X11R6/lib that is chosen after /usr/lib
    - OR /usr/lib/xorg/modules/updates/extensions/ that is chosen after /usr/lib/xorg/modules/extensions/  - i though that updates should be taken in 1st place by default
    Maybe both of them?
    Right now i'm thinking that this is the problem of /usr/X11R6/lib that need to be taken before /usr/lib, so my question is same as the question in topic of this post.
    I will really appreciate any help.
    Btw: there's only one file in /usr/X11R6/lib : /usr/X11R6/lib/fglrx/fglrx-libGL.so.1.2
    + there's only one file in /usr/lib/xorg/modules/updates/extensions : /usr/lib/xorg/modules/updates/extensions/fglrx/fglrx-libglx.so
    I took this whole solution and scripts from SUSE (AMD's solution is really ugly). SUSE also doesn't like /usr/X11R6/lib, but they used it and there it seems to work. I mean i don't have SUSE, i just see their catalyst packaging script.
    Last edited by Vi0L0 (2011-05-15 10:02:32)

    Lone_Wolf wrote:
    've installed libgl, then removed /usr/lib/libGL.so* and problem persist. Then i reinstalled libgl, and removed /usr/lib/xorg/modules/extensions/libglx.so - it was working fine...
    This may be because of  a fallback option that if libglx.so is not found , xorg uses libglx.xorg .
    But libglx.so owned by catalyst (/usr/lib/xorg/modules/updates/extensions/libglx.so) should be found, and is found if only libglx.so owned by libgl (/usr/lib/xorg/modules/extensions/libglx.so) is not present. And if the last one is absent i can see in Xorg.0.log that xserver/catalyst is using that one placed in updates dir, not libglx.xorg.
    Now i removed libgl, and removed /usr/lib/xorg/modules/updates/extensions/libglx.so, so catalyst should got troubles, restart X and same problem: blank screen with only one char sign on top left corner: _
    So obviously catalyst need that /usr/lib/xorg/modules/updates/extensions/libglx.so
    I just don't know how to force using /usr/lib/xorg/modules/updates/extensions directory over /usr/lib/xorg/modules/extensions dir...
    Maybe i need something like LD_PRELOAD or something.
    This maybe not clear but what i'm trying to reach right now is to get catalyst working when libgl package is present, cuz it's looking like good begining.
    Lone_Wolf wrote:It does look like xorg doesn't entirely folllow ldconfig / symbolic links , so i'm inclined to suggest to keep things as simple as possible and change only what's really necessary .
    Ofcourse, i also don't like this whole /usr/X11R6/lib thing. Hell no, i even don't got intel gfx , i'm only trying to implement something that can be usefull for others.
    And since SUSE know how to use /usr/lib/xorg/modules/updates/extensions directory over /usr/lib/xorg/modules/extensions i'm sure it's also possible in Arch. Maybe the right and only way is to change something in xserver compilation, i don't know. Right now i'm trying to do this in "easier" way.
    Lone_Wolf wrote:
    As your libraries have different names as the mesa ones :
    place fglrx-libGL.so.1.2 in /usr/lib
    put fglrx-libglx.so in /usr/lib/xorg/modules/extensions
    for libgl only change the symbolic link just above the binary :  /usr/lib/libGL.so.1
    for libglx change /usr/lib/xorg/modules/extensions/libglx.so
    That ofcourse should work - since it will link to proper libs.
    But it's not what i'm trying to reach : catalyst and libgl installed without conflicts.
    Lone_Wolf wrote:If that works, you'll atleast know the switch is possible.
    Just a mention: this whole linking thing isn't anything new, it was used by linux users for long time so such switch is possible (as i can see they used to use such linking as you suggested but imho it's bad way - it should to be done without pacman's conflicts), now ati is just trying to implement it by default.
    This powerXpress support is still in developement, although i can see what way ati picked up, i'm trying to follow it and i'm pretty sure that it will work if i will follow it. The sooner - the better.

  • [solved] compiz-core upgrade issue: missing /usr/lib/compiz/libcore.so

    After upgrading from compiz-core 0.8.8-3 to 0.8.8-4, but it's persisting even downgrading I got a segfault for the missing file.
    Running
    LANG=C xinit >xinit.log 2>xinit.log
    with the following .xinitrc
    if [ -d /etc/X11/xinit/xinitrc.d ]; then
    for f in /etc/X11/xinit/xinitrc.d/*; do
    [ -x "$f" ] && . "$f"
    done
    unset f
    fi
    setxkbmap it -option compose:rctrl -option terminate:ctrl_alt_bksp
    urxvtd -f -o
    fbpanel &
    gtk-redshift &
    compiz --debug --replace ccp --indirect-rendering
    echo "ARGH -> $?"
    I got this output in xinit.log
    ARGH -> 139
    rver 1.13.0
    Release Date: 2012-09-05
    X Protocol Version 11, Revision 0
    Build Operating System: Linux 3.6.0-1-ARCH x86_64.
    Current Operating System: Linux archmini 3.6.2-1-ARCH #1 SMP PREEMPT Fri Oct 12 23:58:58 CEST 2012#
    Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=7342087f-b1bb-4133-8b50-d25ff902fcab#
    Build Date: 05 October 2012 01:57:18PM
    Current version of pixman: 0.26.2
    >...Before reporting problems, check http://wiki.x.org
    >...to make sure that you have the latest version.
    Markers: (--) probed, (**) from config file, (==) default setting,
    >...(++) from command line, (!!) notice, (II) informational,
    >...(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
    (==) Log file: "/var/log/Xorg.0.log", Time: Mon Oct 15 22:20:21 2012
    (==) Using config directory: "/etc/X11/xorg.conf.d"
    Initializing built-in extension Generic Event Extension
    Initializing built-in extension SHAPE
    Initializing built-in extension MIT-SHM
    Initializing built-in extension XInputExtension
    Initializing built-in extension XTEST
    Initializing built-in extension BIG-REQUESTS
    Initializing built-in extension SYNC
    Initializing built-in extension XKEYBOARD
    Initializing built-in extension XC-MISC
    Initializing built-in extension SECURITY
    Initializing built-in extension XINERAMA
    Initializing built-in extension XFIXES
    Initializing built-in extension RENDER
    Initializing built-in extension RANDR
    Initializing built-in extension COMPOSITE
    Initializing built-in extension DAMAGE
    Initializing built-in extension MIT-SCREEN-SAVER
    Initializing built-in extension DOUBLE-BUFFER
    Initializing built-in extension RECORD
    Initializing built-in extension DPMS
    Initializing built-in extension X-Resource
    Initializing built-in extension XVideo
    Initializing built-in extension XVideo-MotionCompensation
    Initializing built-in extension XFree86-VidModeExtension
    Initializing built-in extension XFree86-DGA
    Initializing built-in extension XFree86-DRI
    Initializing built-in extension DRI2
    Loading extension GLX
    The XKEYBOARD keymap compiler (xkbcomp) reports:
    > Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
    > Ignoring extra symbols
    Errors from xkbcomp are not fatal to the X server
    rxvt-unicode daemon listening on /home/milky/.urxvt/urxvtd-archmini.
    compiz (core) - Debug: Could not stat() file /home/milky/.compiz/plugins/libcore.so : No such file#
    compiz (core) - Debug: Could not stat() file /usr/lib/compiz/libcore.so : No such file or directory
    /home/milky/.xinitrc: line 19: 858 Segmentation fault compiz --debug --replace ccp --indire#
    xinit: connection to X server lost
    ^M
    waiting for X server to shut down urxvt: X connection to ':0' broken, unable to recover, exiting.
    Server terminated successfully (0). Closing log file.
    Relevant pacman.log:
    [2012-10-15 21:30] Running 'pacman -Syu'
    [2012-10-15 21:30] synchronizing package lists
    [2012-10-15 21:30] starting full system upgrade
    [2012-10-15 21:40] upgraded acpid (2.0.17-1 -> 2.0.17-3)
    [2012-10-15 21:40] upgraded cabal-install (1.16.0-1 -> 1.16.0-2)
    [2012-10-15 21:40] upgraded chromium (22.0.1229.92-1 -> 22.0.1229.94-1)
    [2012-10-15 21:40] upgraded libglapi (8.0.4-3 -> 9.0-1)
    [2012-10-15 21:40] upgraded libgl (8.0.4-3 -> 9.0-1)
    [2012-10-15 21:40] installed glu (9.0.0-1)
    [2012-10-15 21:40] upgraded compiz-core (0.8.8-3 -> 0.8.8-4)
    [2012-10-15 21:40] upgraded curl (7.27.0-1 -> 7.28.0-1)
    [2012-10-15 21:40] upgraded dnsutils (9.9.1.P3-1 -> 9.9.2-1)
    [2012-10-15 21:40] upgraded erlang (R15B01-1 -> R15B01-2)
    [2012-10-15 21:40] upgraded firefox (15.0.1-1 -> 16.0.1-1)
    [2012-10-15 21:40] upgraded firefox-i18n-it (15.0.1-1 -> 16.0.1-1)
    [2012-10-15 21:40] upgraded freeglut (2.8.0-1 -> 2.8.0-2)
    [2012-10-15 21:40] upgraded gegl (0.2.0-3 -> 0.2.0-4)
    [2012-10-15 21:40] upgraded git (1.7.12.2-1 -> 1.7.12.3-1)
    [2012-10-15 21:40] upgraded gnutls (3.1.2-1 -> 3.1.3-1)
    [2012-10-15 21:40] upgraded gparted (0.13.1-1 -> 0.14.0-1)
    [2012-10-15 21:40] upgraded hwids (20120922-1 -> 20121012-1)
    [2012-10-15 21:40] upgraded intel-dri (8.0.4-3 -> 9.0-1)
    [2012-10-15 21:40] upgraded jasper (1.900.1-7 -> 1.900.1-8)
    [2012-10-15 21:40] upgraded khrplatform-devel (8.0.4-3 -> 9.0-1)
    [2012-10-15 21:40] upgraded pam (1.1.5-4 -> 1.1.6-1)
    [2012-10-15 21:40] upgraded util-linux (2.22-7 -> 2.22.1-1)
    [2012-10-15 21:40] upgraded systemd (194-1 -> 194-3)
    [2012-10-15 21:40] upgraded libgbm (8.0.4-3 -> 9.0-1)
    [2012-10-15 21:40] upgraded libegl (8.0.4-3 -> 9.0-1)
    [2012-10-15 21:40] upgraded libldap (2.4.32-1 -> 2.4.33-1)
    [2012-10-15 21:40] >>> Updating module dependencies. Please wait ...
    [2012-10-15 21:40] >>> Generating initial ramdisk, using mkinitcpio. Please wait...
    [2012-10-15 21:40] ==> Building image from preset: 'default'
    [2012-10-15 21:40] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
    [2012-10-15 21:40] ==> Starting build: 3.6.2-1-ARCH
    [2012-10-15 21:40] -> Running build hook: [base]
    [2012-10-15 21:40] -> Running build hook: [udev]
    [2012-10-15 21:40] -> Running build hook: [autodetect]
    [2012-10-15 21:40] -> Running build hook: [pata]
    [2012-10-15 21:40] -> Running build hook: [scsi]
    [2012-10-15 21:40] -> Running build hook: [sata]
    [2012-10-15 21:40] -> Running build hook: [filesystems]
    [2012-10-15 21:40] -> Running build hook: [usbinput]
    [2012-10-15 21:40] -> Running build hook: [fsck]
    [2012-10-15 21:40] ==> Generating module dependencies
    [2012-10-15 21:40] ==> Creating gzip initcpio image: /boot/initramfs-linux.img
    [2012-10-15 21:40] ==> Image generation successful
    [2012-10-15 21:40] ==> Building image from preset: 'fallback'
    [2012-10-15 21:40] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
    [2012-10-15 21:40] ==> Starting build: 3.6.2-1-ARCH
    [2012-10-15 21:40] -> Running build hook: [base]
    [2012-10-15 21:40] -> Running build hook: [udev]
    [2012-10-15 21:40] -> Running build hook: [pata]
    [2012-10-15 21:40] -> Running build hook: [scsi]
    [2012-10-15 21:40] -> Running build hook: [sata]
    [2012-10-15 21:40] -> Running build hook: [filesystems]
    [2012-10-15 21:40] -> Running build hook: [usbinput]
    [2012-10-15 21:40] -> Running build hook: [fsck]
    [2012-10-15 21:40] ==> Generating module dependencies
    [2012-10-15 21:40] ==> Creating gzip initcpio image: /boot/initramfs-linux-fallback.img
    [2012-10-15 21:40] ==> Image generation successful
    [2012-10-15 21:40] upgraded linux (3.5.6-1 -> 3.6.2-1)
    [2012-10-15 21:40] upgraded linux-headers (3.5.6-1 -> 3.6.2-1)
    [2012-10-15 21:40] upgraded lirc-utils (1:0.9.0-30 -> 1:0.9.0-31)
    [2012-10-15 21:40] upgraded mesa (8.0.4-3 -> 9.0-1)
    [2012-10-15 21:40] upgraded mtdev (1.1.2-1 -> 1.1.3-1)
    [2012-10-15 21:40] upgraded nodejs (0.8.11-1 -> 0.8.12-1)
    [2012-10-15 21:40] upgraded subversion (1.7.6-1 -> 1.7.7-1)
    [2012-10-15 21:40] upgraded sysvinit-tools (2.88-8 -> 2.88-9)
    [2012-10-15 21:40] upgraded systemd-sysvcompat (194-1 -> 194-3)
    [2012-10-15 21:40] upgraded thunderbird (15.0.1-1 -> 16.0.1-1)
    [2012-10-15 21:40] upgraded tmux (1.6-2 -> 1.7-1)
    [2012-10-15 21:40] upgraded wpa_supplicant (1.0-1 -> 1.0-2)
    [2012-10-15 21:40] upgraded xf86-input-evdev (2.7.3-1 -> 2.7.3-2)
    [2012-10-15 21:40] upgraded xf86-video-intel (2.20.9-1 -> 2.20.9-2)
    [2012-10-15 21:40] upgraded xorg-server-common (1.12.4-1 -> 1.13.0-2)
    [2012-10-15 21:40] upgraded xorg-server (1.12.4-1 -> 1.13.0-2)
    [2012-10-15 21:40] upgraded youtube-dl (2012.09.27-1 -> 2012.10.09-1)
    Anyone can help me tracing in which package the missing file is located (if it's not in compiz-core)?
    Last edited by dexgeh (2012-10-16 17:58:39)

    I managed to solve the issue commenting the --indirect-rendering flag and installing and launching driconf to create a default ~/.drirc file.
    I just noticed that in the same upgrade I got intel-dri from 8.x to 9.x version, maybe it's related.
    Launching a terminal in .xinitrc and manually launching
    LIBGL_DEBUG=verbose compiz --debug --replace ccp
    show me a lot of errors, but it's working, and I don't need anymore the --indirect-rendering flag (in the past I put that flag in the command because of the bad performance that compiz had without).

  • Should arch symlink /usr/lib64 to /usr/lib?

    After spending two hours debugging a bloody java applet accessing a smart card trough pcsclite (Buypass used for different services in Norway, including  government services) it turns out it failed because it ONLY looked for 64bit libs in /usr/lib64. As arch stores 64bit libs in plain old /usr/lib on a 64bit system, this obivously failed. Two hours someone stole from me by doing a sloppy job! Argh!. And I should have been in bed at least one and a half hour ago too.
    I know Debian does this symlinking, and as there apparently are idiots out there who do stuff like above, making such a symlink could save someone some major hassle. I guess it's not to easy for developers of such apps either, as you have to avoid loading libs from /usr/lib before looking for them in /usr/lib64, or else you will get a 32bit lib on Fedora/RedHat and Suse, if both 32bit libs and 64bit ones are installed. Of course you should look for the lib in /usr/lib if you don't find something in /usr/li64, but I guess some don't. Grrrr.
    As there really are no agreed "best pracitce" for where libs of different arch should go (that I could find anyway), such a symlink makes sense to me.

    Inxsible wrote:
    So If I am reading this correctly, you are saying that now that you have found a solution to do what you need, you do not want to spend time to file a bug report? That's a pretty selfish thing to do.
    You want the developers to create symlinks for you by default, but you are not willing to even report something like that on the bug tracker.
    You misunderstand me. tomk said my concern for "someone" having problems might be because I was this "someone".  While he has a point (I wouldn't have brought this up if it hadn't caused me problems - wouldnt even know about it), it was not to solve my own problem I started this thread - my problem was already fixed.  That was what I meant. Fixing this now would not benefit me, and as I solved my problem before starting this thread, my benefit was not my goal. As soon as i realized I could fix this with a symlink, I fixed it with a symlink. And after happily using my smartcard in that stupid java applet, then I started this thread.
    While I certainly could post a bug report, I was not really sure if this was a bug. And based on the response I got here, it seemed it wasn't, and that people think those requiring a symlink should make their own.
    The sidenote about people answering to the thread without reading my posts was made because  people obviously missed the part of this being about a java applet, and therefore is not something in some arch TU messed up while packaging. No biggie, though.
    After reading R00kies post, I actually DID read about FHS, and it appears to me that the AMD64-arch SHOULD in deed have their libs in lib64, according to the  standard
    So i guess a bug report is in order after all, so the devs atleast can have a look on it. But not until after school and work tomorrow.
    ngoonee: By the way, this would not preclude a mulilib system, this is how all the multilib distros I know of do this.

  • [SOLVED]Missing /usr/lib/libgssapi.so when using conserver client

    With newly MIT krb5 in [Core] repo, everything I using console ( the client of conserver: http://aur.archlinux.org/packages.php?ID=27856), I got a compain about missing /usr/lib/libgssapi.so error.
    I recompiled it, but not work.
    Manaully create a link from /usr/lib/libgssapi_krb5.so will solve this problem.
    But still confusing about why recompile the software don't goes to correct lib file.
    Anyone can give me a clue?
    Last edited by cathay4t (2011-05-12 11:23:49)

    Where did you get that 0.1-4?
    I get this error when starting cups
    # /etc/rc.d/cups start
    :: Starting CUPS Daemon [BUSY]
    /usr/sbin/cupsd: error while loading shared libraries: libgssapi.so.2: cannot open shared object file: No such file or directory
    [FAIL]
    Last edited by markuman (2011-05-12 16:41:17)

  • [SOLVED] Error "libpng12: /usr/lib/libpng.so.3 exists in filesystem".

    I've just tried to install the stable "google-chrome" package from AUR with the command.  I have all of the dependencies already installed except for these two:
    - libjpeg6 (building from AUR)
    - libpng12 (package found)
    When the package manage tries to install "libpng12-1.2.43-1", I get the following error:
    error: failed to commit transaction (conflicting files)
    libpng12: /usr/lib/libpng.so.3 exists in filesystem
    Errors occurred, no packages were upgraded.
    According to the file manager (Thunar), the file /usr/lib/libpng.so.3 is a link to /usr/lib/libpng.so.
    This is probably a silly question (as I'm a clueless newbie!) but... can I just delete this link and expect the installation of libpng12 to replace it so that everything will still work...?
    Thanks in advance :-)
    Last edited by esuhl (2011-01-21 02:46:19)

    $ pacman -Ql libpng|grep /lib/
    libpng /usr/lib/
    libpng /usr/lib/libpng.a
    libpng /usr/lib/libpng.so
    libpng /usr/lib/libpng14.a
    libpng /usr/lib/libpng14.so
    libpng /usr/lib/libpng14.so.14
    libpng /usr/lib/libpng14.so.14.5.0
    libpng /usr/lib/pkgconfig/
    libpng /usr/lib/pkgconfig/libpng.pc
    libpng /usr/lib/pkgconfig/libpng14.pc
    A tip: run pacman -Qo on the file in question, either you put that symlink there yourself or strange things are happening on your system.

  • [SOLVED] ldconfig: /usr/lib/libOpenCL.so.1 is not a symbolic link

    Hi. I use 64 bits arch with gnome and the ATI driver 13.6 beta installed from the AMD binary and I usually execute steam. Everything seem fine, but recently I receive a message when I update any package with pacman
    ldconfig: /usr/lib/libOpenCL.so.1 is not a symbolic link
    However the update seems correct, only that warning message. I've checked the propietary of the file
    pacman -Qo /usr/lib/libOpenCL.so.1
    /usr/lib/libOpenCL.so.1 is owned by libcl 1.1-3
    The last update without the ldconfig message was
    [2013-07-22 21:27] [PACMAN] Running 'pacman -Syu'
    [2013-07-22 21:27] [PACMAN] synchronizing package lists
    [2013-07-22 21:27] [PACMAN] starting full system upgrade
    [2013-07-22 21:29] [PACMAN] upgraded apache (2.2.24-3 -> 2.2.25-1)
    [2013-07-22 21:29] [PACMAN] upgraded apr (1.4.6-1 -> 1.4.8-1)
    [2013-07-22 21:29] [PACMAN] upgraded boost-libs (1.53.0-2 -> 1.54.0-2)
    [2013-07-22 21:30] [PACMAN] upgraded python2-psutil (1.0.0-1 -> 1.0.1-1)
    [2013-07-22 21:30] [PACMAN] upgraded calibre (0.9.38-1 -> 0.9.40-1)
    [2013-07-22 21:30] [PACMAN] upgraded clucene (2.3.3.4-6 -> 2.3.3.4-7)
    [2013-07-22 21:30] [PACMAN] upgraded libpciaccess (0.13.1-1 -> 0.13.2-1)
    [2013-07-22 21:30] [PACMAN] upgraded libdrm (2.4.46-1 -> 2.4.46-2)
    [2013-07-22 21:30] [PACMAN] upgraded cogl (1.14.0-3 -> 1.14.0-4)
    [2013-07-22 21:30] [PACMAN] upgraded wayland (1.1.0-1 -> 1.2.0-1)
    [2013-07-22 21:30] [PACMAN] upgraded mesa (9.1.4-3 -> 9.1.5-1)
    [2013-07-22 21:30] [PACMAN] upgraded clutter (1.14.4-2 -> 1.14.4-3)
    [2013-07-22 21:30] [PACMAN] upgraded dconf (0.16.0-1 -> 0.16.1-1)
    [2013-07-22 21:30] [PACMAN] upgraded colord (1.0.1-1 -> 1.0.2-1)
    [2013-07-22 21:30] [PACMAN] upgraded gnutls (3.2.1-1 -> 3.2.2-1)
    [2013-07-22 21:30] [PACMAN] upgraded libcups (1.6.2-3 -> 1.6.3-1)
    [2013-07-22 21:30] [PACMAN] upgraded cups (1.6.2-3 -> 1.6.3-1)
    [2013-07-22 21:30] [PACMAN] upgraded libgdm (3.8.3-1 -> 3.8.3.1-1)
    [2013-07-22 21:30] [ALPM] warning: directory permissions differ on /var/log/gdm/
    filesystem: 711 package: 1770
    [2013-07-22 21:30] [PACMAN] upgraded gdm (3.8.3-1 -> 3.8.3.1-1)
    [2013-07-22 21:30] [PACMAN] upgraded gnome-contacts (3.8.2-1 -> 3.8.3-1)
    [2013-07-22 21:30] [PACMAN] upgraded gnome-settings-daemon (3.8.3-2 -> 3.8.4-1)
    [2013-07-22 21:30] [PACMAN] upgraded gnome-tweak-tool (3.8.0-1 -> 3.8.1-1)
    [2013-07-22 21:30] [PACMAN] upgraded gnome-user-share (3.8.0-1 -> 3.8.3-1)
    [2013-07-22 21:30] [PACMAN] upgraded idnkit (1.0-2 -> 1.0-3)
    [2013-07-22 21:30] [PACMAN] upgraded lib32-libpciaccess (0.13.1-1 -> 0.13.2-1)
    [2013-07-22 21:30] [PACMAN] upgraded lib32-mesa (9.1.4-1 -> 9.1.5-1)
    [2013-07-22 21:30] [PACMAN] upgraded lib32-mesa-libgl (9.1.4-1 -> 9.1.5-1)
    [2013-07-22 21:30] [PACMAN] upgraded lib32-xz (5.0.4-1 -> 5.0.5-1)
    [2013-07-22 21:30] [PACMAN] upgraded libmbim (1.2.0-1 -> 1.4.0-1)
    [2013-07-22 21:30] [PACMAN] upgraded libqmi (1.4.0-1 -> 1.4.0-2)
    [2013-07-22 21:30] [PACMAN] upgraded libxfont (1.4.5-1 -> 1.4.6-1)
    [2013-07-22 21:30] [PACMAN] upgraded mesa-libgl (9.1.4-3 -> 9.1.5-1)
    [2013-07-22 21:30] [PACMAN] upgraded modemmanager (0.7.991-1 -> 1.0.0-1)
    [2013-07-22 21:30] [PACMAN] upgraded netctl (1.1-1 -> 1.2-1)
    [2013-07-22 21:30] [PACMAN] upgraded opus (1.0.2-2 -> 1.0.3-1)
    [2013-07-22 21:30] [PACMAN] upgraded qtwebkit (2.3.1-2 -> 2.3.2-1)
    [2013-07-22 21:30] [PACMAN] upgraded rtmpdump (20121230-1 -> 20121230-2)
    [2013-07-22 21:30] [PACMAN] upgraded source-highlight (3.1.7-5 -> 3.1.7-6)
    [2013-07-22 21:30] [PACMAN] upgraded tzdata (2013c-1 -> 2013d-1)
    [2013-07-22 21:30] [PACMAN] upgraded xorg-mkfontscale (1.1.0-1 -> 1.1.1-1)
    but honestly I don't know if the message is relate with the gdm warning. The first updated package with the ldconfig message was
    [2013-07-23 12:12] [PACMAN] Running 'pacman -Syu'
    [2013-07-23 12:12] [PACMAN] synchronizing package lists
    [2013-07-23 12:13] [PACMAN] starting full system upgrade
    [2013-07-23 12:13] [PACMAN] upgraded libusbx (1.0.15-1 -> 1.0.16-1)
    [2013-07-23 12:13] [ALPM-SCRIPTLET] ldconfig: /usr/lib/libOpenCL.so.1 is not a symbolic link
    [2013-07-23 12:13] [ALPM-SCRIPTLET]
    I don't know how to remove the ldconfig message, I'm not sure if I can safely remove the libOpenCL.so.1
    Last edited by David López (2013-07-24 12:54:31)

    On my system, that file IS a symbolic link:
    lrwxrwxrwx 1 root root 23 Aws 14 2012 /usr/lib/libOpenCL.so -> /usr/lib/libOpenCL.so.1*
    lrwxrwxrwx 1 root root 27 Aws 14 2012 /usr/lib/libOpenCL.so.1 -> /usr/lib/libOpenCL.so.1.0.0*
    -rwxr-xr-x 1 root root 21K Aws 14 2012 /usr/lib/libOpenCL.so.1.0.0*
    [Aside: I know that the "Aws" isn't English but I hardly ever pass LC_ALL=C myself just because so little is translated into my interface language . Dates is almost it. ]
    I would try reinstalling libcl and take it from there.
    Last edited by cfr (2013-07-24 00:54:01)

  • Ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib liker error

    Hello,
    I found out that some open source applications when tied to be installed from source or trough fink or mac ports simply fail at linking with the error:
    ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib
    However, when I force the linker to use /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib instead it works.
    I am wondering what is the problem since /usr/X11/lib/libGL.dylib has to be exported from /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib.
    It is very painful to force configure to use right version of libGL.dylib. Since the two libraries are of
    different size the should be different. Simple replacement of /usr/X11/lib/libGL.dylib by /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib would work, but what are the consequences for the other applications?
    I would be very happy is someone from OS X developement would reply to this and address this problem in the future.
    Regards,
    Slobodan

    Post to the Unix forum under OS X Technologies and you should get a knowledgeable answer.

  • /lib symlinks /usr/lib. Doeas it mean /usr HAS to be mounted??

    For traditional Unix systems (FHS-compliant) it is (was?) completely safe to unmount (or even delete) the `/usr' filesystem. There are (were?) no files critical to the system "itself" - only applications, daemons, desktop data etc.
    Since now under Arch `/lib' symlinks `/usr/lib'. But `/lib/modules/<kernel>' stores kernel modules - even those that are critical; `/lib' also stores libraries critical to binaries in `/bin' ans `/sbin'! Does it mean that since now inaccessible `/usr' may result in a non-booting system???
    Last edited by quayasil (2012-07-21 20:05:28)

    quayasil wrote:Does it mean that since now inaccessible `/usr' may result in a non-booting system???
    Arch uses an initramfs, so all necessary tools for rescue operatiosn should be included there. As long as /boot is working, you'll be able to boot in an initramfs-console.
    critical to the system "itself"
    Well, what do you define as critical? Text-console and writing files? Mounting? Networking?
    Last edited by progandy (2012-07-21 20:53:24)

Maybe you are looking for