Чому вам потрібно зв’язати математичну бібліотеку на C?

Якщо я включаю <stdlib.h>або <stdio.h>в програму C, мені не потрібно пов'язувати їх під час компіляції, але я маю посилатися на <math.h>, наприклад, -lmз gcc, наприклад:

gcc test.c -o test -lm

У чому причина цього? Чому я повинен явно пов'язувати математичну бібліотеку, а не інші бібліотеки?

Функції в stdlib.hі stdio.hмають реалізацію в libc.so(або libc.aдля статичного зв'язку), який за замовчуванням пов'язаний з вашим виконуваним файлом (як би -lcвказано). GCC можна доручити уникати цього автоматичного зв’язку з параметрами -nostdlibабо -nodefaultlibs.

Математичні функції в math.hмають реалізацію в libm.so(або libm.aдля статичного зв’язку), і libmза замовчуванням не пов'язано. Є історичні причини цього libm/ libcрозколу, жодна з них не дуже переконлива.

Цікаво, що час виконання C ++ libstdc++вимагає libm, тому якщо ви складете програму C ++ з GCC ( g++), ви автоматично libmзв’яжетесь.

Пам'ятайте, що C - це стара мова і що ППУ - явище порівняно недавно. Я вперше побачив C на 8-бітових процесорах, де було багато роботи навіть для 32-бітової цілочисельної арифметики. Багато з цих реалізацій навіть не було бібліотеки математики з плаваючою комою!

Навіть на перших 68000 машинах (Mac, Atari ST, Amiga) співпроцесори з плаваючою комою часто були дорогими додатками.

Щоб зробити все з математики з плаваючою комою, вам знадобилася досить велика бібліотека. І математика збиралася повільною. Так ви рідко використовували поплавці. Ви намагалися зробити все з цілими чи масштабованими цілими числами. Коли вам довелося включати math.h, ви стискали зуби. Часто ви пишете власні наближення та таблиці пошуку, щоб уникнути цього.

Компроміси існували тривалий час. Іноді існували конкуруючі математичні пакети під назвою "fastmath" або подібні. Що найкраще рішення для математики? Дійсно точні, але повільні речі? Неточний, але швидкий? Великі таблиці для триггерних функцій? Лише коли копроцесори не отримали гарантії перебування в комп'ютері, більшість реалізацій стали очевидними. Я думаю, що там десь зараз є якийсь програміст, який працює над вбудованим чіпом, намагаючись вирішити, чи занести до математичної бібліотеки для вирішення якоїсь математичної проблеми.

Тому математика не була стандартною . Багато або, можливо, більшість програм не використовували один плавець. Якби FPU завжди були поруч, а поплавки і дублі завжди були дешевими для експлуатації, без сумніву, було б "stdmath".

Через смішну історичну практику, яку ніхто не бажає виправляти. Консолідація всіх функцій, що вимагаються C і POSIX, в єдиний файл бібліотеки, не тільки уникне запитання про це знову і знову, але й заощадить значну кількість часу та пам'яті при динамічному посиланні, оскільки кожен .soзв'язаний файл вимагає операцій з файловою системою щоб знайти та знайти його, та декілька сторінок для його статичних змінних, переміщення тощо.

Реалізація якої всі функції знаходяться в одній бібліотеці і -lm, -lpthread, -lrtі т.д. опції не все немає-OPS (або посилання на порожні .aфайли) ідеально POSIX сумісного і , звичайно , краще.

Примітка. Я кажу про POSIX, оскільки сам C нічого не вказує про те, як викликається компілятор. Таким чином, ви можете просто трактувати gcc -std=c99 -lmяк специфічний для способу використання компілятор для відповідної поведінки.

Оскільки time()і деякі інші функції builtinвизначені в самій бібліотеці C ( libc), а GCC завжди посилається на libc, якщо ви не використовуєте параметр -ffreestandingкомпіляції. Однак математичні функції живуть, в libmяких невірно пов'язана gcc.

Пояснення дано тут :

Отже, якщо у вашій програмі використовуються математичні функції та в тому числі math.h, вам потрібно явно зв’язати математичну бібліотеку, передавши -lmпрапор. Причиною такого розмежування є те, що математики дуже вибагливі до того, як обчислюється їх математика, і вони можуть захотіти використовувати власну реалізацію математичних функцій замість стандартної реалізації. Якби математичні функції були зібрані, libc.aце зробити це було б неможливо.

[Редагувати]

Я не впевнений, що згоден з цим. Якщо у вас є бібліотека, яка забезпечує, скажімо, sqrt()і передаєте її перед стандартною бібліотекою, Unix-лінкер прийме вашу версію, правда?

Існує ретельна дискусія про зв'язок із зовнішніми бібліотеками у Вступі до GCC - Зв'язок із зовнішніми бібліотеками . Якщо бібліотека є членом стандартних бібліотек (як, наприклад, stdio), то вам не потрібно вказувати компілятору (справді лінкеру), щоб пов’язати їх.

EDIT: Прочитавши деякі інші відповіді та коментарі, я думаю, що посилання на libc.a та посилання на libm, які вона посилається на обидва, мають багато що сказати про те, чому обидві є окремими.

Зауважте, що багато функцій у ‘libm.a’ (математична бібліотека) визначені у ‘math.h’, але їх немає у libc.a. Деякі з них можуть заплутатися, але правило є таким - бібліотека C містить ті функції, які повинні існувати диктати ANSI, так що вам не знадобиться -lm, якщо ви використовуєте лише функції ANSI. Навпаки, `libm.a 'містить більше функцій і підтримує додаткові функціональні можливості, такі як зворотний виклик matherr та відповідність декільком альтернативним стандартам поведінки у разі помилок FP. Докладнішу інформацію див. У розділі libm.

Як було сказано ефектом, libc бібліотеки C пов'язаний за замовчуванням, і ця бібліотека містить реалізацію stdlib.h, stdio.h та декілька інших стандартних файлів заголовків. Тільки додати до нього, згідно з " Введенням до GCC " команда linker для основної програми "Hello World" на C наведена нижче:

ld -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o 
/usr/lib/crti.o /usr/libgcc-lib /i686/3.3.1/crtbegin.o
-L/usr/lib/gcc-lib/i686/3.3.1 hello.o -lgcc -lgcc_eh -lc 
-lgcc -lgcc_eh /usr/lib/gcc-lib/i686/3.3.1/crtend.o /usr/lib/crtn.o

Зауважте опцію -lc у третьому рядку, який посилається на бібліотеку C.

Я думаю, що це щось довільно. Ви повинні десь намалювати рядок (які бібліотеки за замовчуванням і які потрібно вказати).

Це дає вам можливість замінити його на інший, який має ті самі функції, але я не думаю, що це дуже часто буває.

EDIT: (з моїх власних коментарів): Я думаю, що gcc робить це для підтримки зворотної сумісності з оригінальним куб. Я здогадуюсь, чому cc робить це через час складання - cc був написаний для машин з набагато меншою потужністю, ніж у нас зараз. Багато програм не мають математики з плаваючою комою, і вони, ймовірно, брали кожну бібліотеку, яку зазвичай не використовували за замовчуванням. Я здогадуюсь, що час побудови ОС UNIX та інструменти, які йдуть разом із нею, були рушійною силою.

Якщо я поклав stdlib.h або stdio.h, мені не доведеться посилати їх, але я маю посилатись, коли компілюю:

stdlib.h, stdio.h- файли заголовків. Ви включаєте їх для вашої зручності. Вони лише прогнозують, які символи стануть доступними, якщо ви зв’яжетесь у відповідній бібліотеці. Реалізації знаходяться у файлах бібліотеки, саме там функції дійсно живуть.

У тому числі math.h - це лише перший крок до отримання доступу до всіх математичних функцій.

Крім того, вам не доведеться зв’язуватися, libmякщо ви не використовуєте його функції, навіть якщо ви робите це, #include <math.h>що є лише інформаційним кроком для компілятора про символи.

stdlib.h, stdio.hзверніться до функцій, доступних у libc, які, як правило, завжди пов'язані між собою, так що користувачеві не потрібно робити це сам.

stdio є частиною стандартної бібліотеки С, з якою за замовчуванням gcc буде посилатися на.

Реалізації математичної функції знаходяться в окремому файлі libm, який за замовчуванням не пов'язаний, тому вам потрібно вказати -lm. До речі, між тими заголовними файлами та бібліотечними файлами немає зв’язку.

Я б здогадався, що це спосіб зробити додатки, які зовсім не використовують його, трохи ефективніше. Ось моя думка з цього приводу.

ОС x86 (і я думаю, що інші) повинні зберігати стан FPU на контекстному комутаторі. Однак більшість ОС намагаються зберегти / відновити цей стан після того, як програма намагається використовувати FPU вперше.

На додаток до цього, в математичній бібліотеці є певний базовий код, який встановить FPU у здоровий базовий стан при завантаженні бібліотеки.

Отже, якщо ви взагалі не зв’язуєте жоден математичний код, нічого з цього не відбудеться, тому ОС не повинна взагалі зберігати / відновлювати будь-який стан FPU, роблячи контекстні перемикання дещо ефективнішими.

Тільки здогадка, хоча.

EDIT: у відповідь на деякі коментарі, те саме базове передумови досі застосовується до випадків, що не належать до FPU (припущення полягає в тому, що програми, які не використовують libm, працюють трохи краще).

Наприклад, якщо є Soft-FPU, який був подібний в перші дні C. Тоді, якщо розділити libm окремо, це може перешкодити безлічі великого (і повільного, якщо воно використовується) коду.

Крім того, якщо доступно лише статичне посилання, то застосовується аналогічний аргумент, який би зберігав виконувані розміри та час компіляції.