Проблема с xpdf...

Проблема решается переходом на Adobe Reader, imho, удобнее!

>Проблема с xpdf...

А что ты хочешь? Он же на motif.

>Gtk/Qt проги не предлагать...

А acroread теперь как раз под gtk.

Есть ещё глюкавый evince--он тоже под gtk.

Какая версия xpdf? В других иксовых прогах такое есть? ИМХО шрифтов где-то не хватает...

> Есть ещё глюкавый evince

Сам такой

>> Проблема решается переходом на Adobe Reader, imho, удобнее!

У меня после перехода на gcc -3.4.5 этот акробат перестал запускаться,
т.к. он собран gcc из ветки 3.3

а при чем тут вообще gcc?! как же он тогда работает, когда gcc вообще нет на компе? у меня вообще gcc 4.0.3 и акробат прекрасно работает.

Как?! Неужели все мотифовские проги не будут поддерживать русский? :-((((

>> а при чем тут вообще gcc?! как же он тогда работает, когда gcc вообще нет на компе? у меня вообще gcc 4.0.3 и акробат прекрасно работает

Речь идет о 7 акробате?
ldd libagluc.so.28.0
libstdc++.so.5 ==> not found
А llibstdc++.so.5 входит в состав gcc-g++3.3.6.
В gcc-g++3.4.5 уже libstdc++.so.6

>libstdc++.so.5 ==> not found

sudo apt-get install libstdc++5

причём здесь gcc?

P.S.
$ dpkg --search libstdc++.so.5
libstdc++5: /usr/lib/libstdc++.so.5

В какой же тогда пакет входит libstdc++.so.5 ?
И что же скажет ldd libstdc++.so.5 ?

>В какой же тогда пакет входит libstdc++.so.5 ?

см. пост выше, там всё написано

>И что же скажет ldd libstdc++.so.5 ?

$ ldd /usr/lib/libstdc++.so.5
        linux-gate.so.1 =>  (0xffffe000)
        libm.so.6 => /lib/tls/libm.so.6 (0xb7e76000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e6b000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7d34000)
        /lib/ld-linux.so.2 (0x80000000)

кстати:

$ apt-cache policy gcc
gcc:
  Installed: 4:4.0.2-2
  Candidate: 4:4.0.2-2
  Version table:
 *** 4:4.0.2-2 0
        800 http://debian.balt.net etch/main Packages
         50 http://debian.balt.net unstable/main Packages
        100 /var/lib/dpkg/status

rpm -qf /usr/local/lib/libstdc++.so.5
libstdc++32-3.2.2-5asp

Иначе говоря, libstdc++.so.5 может принадлежать любому пакету (в зависимости от того, куда его поместит сборщик) начиная с gcc-3.2.2 как минимум.

>> Иначе говоря, libstdc++.so.5 может принадлежать любому пакету

Вот и получается, что при апгрейде gcc , gcc-g++ надо следить за тем,
чтобы в системе оставался пакет библиотек, который бы обеспечивал запуск
динамически линкованных С++ бинарей, собранными более старыми
libstdc++

>Вот и получается, что при апгрейде gcc , gcc-g++ надо следить за тем, чтобы в системе оставался пакет библиотек, который бы обеспечивал запуск динамически линкованных С++ бинарей, собранными более старыми libstdc++

а в чём проблема? и что значит "следить"? по такой же логике нужно _постоянно_ "следить" за наличием ядра в системе, ведь без него она не запустится.

в конце концов, "следить" за зависимостями - задача пакетного менеджера, и если честно, совсем не понимаю, в чём проблема.

>Иначе говоря, libstdc++.so.5 может принадлежать любому пакету

в нормальных дистрибутивах так быть не может; другое дело если это неофициальный пакет или пакет из другого дистрибутива

>> в конце концов, "следить" за зависимостями - задача пакетного менеджера,

Не во всех системах это есть.

>>в нормальных дистрибутивах так быть не может;

Понятие нормальный дистрибутив у каждого свое.

> Иначе говоря, libstdc++.so.5 может принадлежать любому пакету

> в нормальных дистрибутивах так быть не может; другое дело если это неофициальный пакет или пакет из другого дистрибутива

Так бывает в разных версиях даже одного дистрибутива

>Так бывает в разных версиях даже одного дистрибутива

в любом случае, это проблема пакетного менджера, не так ли? для людей, использующих дистрибутивы без п.м. этот вопрос изначально не составит проблемы.