C-бібліотека відноситься до найважливіших компонентів кожної системи Unix, так як вона також відповідає за бездоганне взаємодію додатки і процесу сервера.
Далі Ви знайдете деякі вказівки і додаткову інформацію, в якій ми коротко розповімо, за скільки можна розпізнавати,
- не конфліктує встановлений антивірусний сканер з середовищем процесора
- куди слід звертатися в разі неповного оновлення.
Майже всі компоненти системи Unix (сама ОС, системні програми і переважна більшість всіх додатків) написано безпосередньо на мові програмування C або будуються на компонентах, на писаних на C.
Базові функції, на які додатки спираються при своїй роботі, знаходяться зазвичай в так званій libc. Так само як робота з файлами оперативної пам'яті, з мережею, управління процесами і доступ до всіх створеним операційною системою службам.
Логічно, що ці функції не перебувають постійно кожною програмою і не відправляються. Тому вони встановлені в центральному місці системи і доступними для інших програм. З тих пір як система Unix підтримує концепцію доступних бібліотек (можна порівняти з файлами DLL на інших платформах), прийнято розподіляти відповідні додатки як так звані dynamically linked binaries. Що лежить в основі операційна система тільки в момент запуску програми повинен надати таку ж прив'язану C-бібліотеку.
Тому неможливо уникнути ситуацій, коли то там, то тут виникають невідповідності зі стандартом. Іноді навіть "в оболонці" виходить однорідна, узгоджена картина, але в більш складних областях відхилення можуть призводити до того, що використовувані додатки повинні відповідати змінених умов. Наслідки зміненої семантики можуть бути такими, що, наприклад, інтерфейс, інтерпретував дані певний способом, несподівано використовується в інших процесах обробки. Можливо інший наслідок: Інтерфейси через модифікації їх параметрів змінюють свій образ і принцип дії, так як їх функціональність була розширена.
З цих причин бібліотека має чітке позначення версій (її поточний стан розвитку і тим самим її характеристика). Однак не всі використовувані версії сумісні між собою "у всіх напрямках".
Як правило, більш висока версія сумісна з більш старої. Така сумісність гарантується (якщо взагалі гарантується) тільки для суміжних версій. Інакше кажучи: в повному розумінні слова сумісність не здатна до великих переходах.
Так що ж робити? Якщо є вихідні коди операційної системи і додатків, можна зробити перетворення всієї системи для того, щоб завдяки цьому домогтися консистентного і сумісного стану. Якщо додатки завантажуються як виконавчі, при завантаженні треба вибирати правильну версію. При оновленні основних компонентів слід звертати увагу на те, щоб в компонентах вищої версії присутня залежність і щоб при необхідності їх можна було оновити. Якщо, наприклад, змінюється такий важливий компонент системи, як libc або виконується його оновлення до більш високої версії, може знадобитися оновити не лише основну систему, але і все прикладне ПЗ.
Визначення версії бібліотеки або підтримуваних AntiVir версій
Може звучати своєрідно: З причин сумісності та взаємодії з відкритою системою працює додаток не може дізнатися версію встановленої libc і тим самим визначити, чи може воно працювати в цьому середовищі. Визначення версії з вигляду бібліотеки зовсім не передбачено (проте якщо і є такі реалізації, мають цю функцію, цей метод ще довго буде працювати не в усіх системах і не на всіх платформах). Одночасно в даному випадку мова йде про відому проблему яйця і курки: Як при - непостійність необхідних і наявних версій - має запускатися непрацездатний додаток і потім тестувати свою працездатність?
На жаль ми, розробники програмного забезпечення, не можемо в даний час вирішити цю дилему і полегшити користувачам роботу так, як вони б цього хотіли. Описана вище ситуація вимагає того, щоб мережевий адміністратор постійно контролював сумісний стан встановленого ПО-це завдання за нього не виконає ніхто. Однак ми хотіли б запропонувати керівництво по розпізнаванню і усунення проблем.
усунення проблеми
Наступні вказівки спираються на ОС Linux з бібліотекою GNU-C. Зрозуміло. для інших платформ описані вище аспекти також діють, проте до цих пір тільки в Linux і в поєднанні з GNU libc існує настійна вимога вибирати одну із запропонованих версій.
Бібліотека glibc знаходиться на жорсткому диску в форматі, який дозволяє використовувати її як "звичайну програму". Це допомагає не тільки на етапі розробки, але і дозволяє пізніше при отриманні виводити істотну інформацію.
/lib/libc.so.6 | head -1
показує номер версії (надається інформація набагато ширший, однак в даному випадку фільтрується тільки рядок з номером версії). Якщо при цій команді показується повідомлення "Permission denied" або файл з яких-небудь інших причин не починається як "програма", можна спробувати запустити за допомогою наступної команди:
/lib/ld-linux.so.2 /lib/libc.so.6 | head -1
Якщо номер версії починається з 2.0 або 2.1, можна використовувати помічені як glibc20 архіви нашого ПО. Якщо номер версії починається з 2.2 або 2.3, слід використовувати помічені як glibc22 архіви. Зрозуміло, libc також може бути з (внутрішньої) версією 1 і в такому випадку мати ім'я файлу libc.so.5. Хоч ця реалізація і не актуальна і має мало функцій, завдяки своєму невеликому обсягу (відсутній інтернаціоналізація) вона часто використовується у вбудованих системах, тобто там, де потрібно економія місця і про оновлення немає й мови.
Поряд з версією GNU бібліотеки libc також використовуються інші реалізації, що переслідують різні цілі, наприклад, "гнучкість" або "екстремальну мобільність". Оскільки використання цього ПЗ є наслідком усвідомлених рішень (а не "випадковості" або через установки стандартного дистрибутива), ми виходимо з того, що адміністратори дуже добре знають свою систему. Вони дотримуються розглядаються тут положення і точно знають, яка бібліотека glibc найкраще підходить для використовуваної реалізації. Тому вони знають який архів ПО H + BEDV треба використовувати.
У рідкісних випадках, коли файл з реалізацією libc не перебуває у каталозі lib, адміністратор повинен знати, де знаходиться файл. У спірному випадку завантажувач в працюючій системі знає, де знаходяться відкриті об'єкти. При сумніві можна використовувати команду
ldd / bin / ls (або будь-яку іншу динамічно пов'язану програму)
і шукати рядки за допомогою libc (або по ldlinux для описаного вище випадку з бібліотекою, що не запускається в якості програми).
Зовнішні програми "мають" логіку високого рівня для додатка, в той час як вони звертаються до функцій низького рівня, до таких системних компонентів, як libc. Якщо ці компоненти конфліктують, ПЗ не буде працювати правильно (а палітра ефектів буде змінюватися починаючи з "начебто працюють" далі "працюють іноді, але часто не працюють" потім "взагалі не працюють, нічого не відбувається" аж до "форматує мій жорсткий диск , через це випадають моє волосся і моя кішка мене ненавидить ").
Прикладне ПО не в змозі виконати задовільний тест на сумісність, в наслідок чого адміністратор повинен відповідати за сумісність і працездатність системи. Оскільки версії Linux нашого ПО пропонуються в різних варіантах для різних середовищ, потрібно зробити вибір на підставі встановленої C-бібліотеки.
Повний шлях до файлу встановленої C-бібліотеки на жорсткому диску і версію використовуваної реалізації можна дізнатися за допомогою наступних команд:
$ Ldd / bin / ls / bin / bash / usr / bin / vi
/ Bin / ls:
librt.so.1 => /lib/librt.so.1 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x40030000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40160000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libncurses.so.5 => /lib/libncurses.so.5 (0x4001e000)
libgpm.so.1 => /usr/lib/libgpm.so.1 (0x40066000)
libdl.so.2 => /lib/libdl.so.2 (0x4006c000)
libperl.so.1 => /usr/lib/libperl.so.1 (0x4006f000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4016f000)
libutil.so.1 => /lib/libutil.so.1 (0x4019c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4019f000)
libm.so.6 => /lib/libm.so.6 (0x401f0000)
libc.so.6 => /lib/libc.so.6 (0x40213000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ /lib/libc.so.6 | head -1
GNU C Library stable release version 2.3.1, by Roland McGrath et al.
Залежно від встановленої бібліотеки CLibrary для програм треба використовувати відповідні архіви програмного забезпечення H + BEDV. Стандартно наші антивірусні програми виконуються для Linux так, щоб вони працювали з GNU-libc в версіях 2.2 або 2.3. Для систем, обмежених у своїх ресурсах, або там, де з інших причин використовується libc5, також доступні відповідні версії. Адміністратори, які не використовують в своїх системах реалізацію GNU, повинні вибирати найбільш підходящий архів.