Почему вам нужно связывать математическую библиотеку на C?

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

Математические функции в math.h имеют реализации в libm.so (или libm.a для статического связывания), а libm по умолчанию не связан. У этого _12 _ / _ 13_ раскола есть исторические причины, но ни одна из них не очень убедительна.

Интересно, что для среды выполнения C ++ libstdc++ требуется libm, поэтому, если вы скомпилируете программу на C ++ с GCC (g++), вы автоматически получите libm связанный файл.

Помните, что C - старый язык, а FPU - относительно недавнее явление. Я впервые увидел C на 8-битных процессорах, где даже 32-битные целочисленные арифметические операции требовали много работы. Многие из этих реализаций даже не имели математическую библиотеку с плавающей запятой!

Даже на первых 68000 машинах (Mac, Atari ST, Amiga) сопроцессоры с плавающей запятой часто были дорогостоящими надстройками.

Чтобы делать всю эту математику с плавающей запятой, вам нужна была довольно большая библиотека. И математика будет медленной. Значит, вы редко использовали поплавки. Вы пробовали делать все с целыми или масштабированными целыми числами. Когда вам пришлось включить math.h, вы стиснули зубы. Часто, чтобы избежать этого, вы должны написать свои собственные аппроксимации и справочные таблицы.

Компромиссы существовали давно. Иногда существовали конкурирующие математические пакеты, называемые «fastmath» или подобные. Какое лучшее решение для математики? Действительно точный, но медленный материал? Неточно, но быстро? Большие таблицы для триггерных функций? Большинство реализаций стало очевидным только после того, как в компьютере было гарантировано наличие сопроцессоров. Я полагаю, что где-то сейчас есть какой-то программист, работающий над встроенным чипом, пытающийся решить, использовать ли математическую библиотеку для решения некоторой математической задачи.

Вот почему математика не была стандартной. Многие, а может быть, и большинство программ не использовали ни одного числа с плавающей запятой. Если бы FPU всегда были рядом, а поплавки и двойники всегда были дешевы в эксплуатации, без сомнения, существовала бы «стандартная математика».

Из-за нелепой исторической практики, которую никто не хочет исправлять. Объединение всех функций, требуемых C и POSIX, в один файл библиотеки не только позволит избежать повторения этого вопроса снова и снова, но также сэкономит значительное количество времени и памяти при динамической компоновке, поскольку каждый связанный файл .so требует файловой системы операции по поиску и поиску, а также несколько страниц для его статических переменных, перемещений и т. д.

Реализация, в которой все функции находятся в одной библиотеке, а параметры -lm, -lpthread, -lrt и т. Д. Не работают (или связаны с пустыми .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), вам не нужно указывать компилятору (на самом деле компоновщику) их связывание.

РЕДАКТИРОВАТЬ: прочитав некоторые другие ответы и комментарии, я думаю, что ссылка libc.a и ссылка на libm, на которую обе они ссылаются, могут многое сказать о том, почему они разделены.

Обратите внимание, что многие функции в libm.a (математическая библиотека) определены в math.h, но отсутствуют в libc.a. Некоторые из них могут сбивать с толку, но практическое правило таково: библиотека C содержит те функции, которые, согласно требованиям ANSI, должны существовать, поэтому вам не понадобится -lm, если вы используете только функции ANSI. Напротив, libm.a содержит больше функций и поддерживает дополнительные функции, такие как обратный вызов matherr и соответствие нескольким альтернативным стандартам поведения в случае ошибок FP. Смотрите раздел libm для более подробной информации.

Как сказал ephemient, библиотека C libc связана по умолчанию, и эта библиотека содержит реализации stdlib.h, stdio.h и несколько других стандартных файлов заголовков. Чтобы добавить к нему, согласно "Введение в GCC" компоновщик Команда для базовой программы "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.

Я считаю, что это произвольно. Вы должны где-то нарисовать линию (какие библиотеки используются по умолчанию, а какие необходимо указать).

Это дает вам возможность заменить его другим, имеющим те же функции, но я не думаю, что это очень распространено.

РЕДАКТИРОВАТЬ: (из моих собственных комментариев): я думаю, что gcc делает это для поддержания обратной совместимости с исходным cc. Я предполагаю, почему cc делает это из-за времени сборки - cc был написан для машин с гораздо меньшей мощностью, чем у нас сейчас. Во многих программах нет математики с плавающей запятой, и они, вероятно, взяли все библиотеки, которые обычно не использовались, по умолчанию. Я предполагаю, что время сборки ОС UNIX и сопутствующие ей инструменты были движущей силой.

Если я помещаю stdlib.h или stdio.h, мне не нужно связывать их, но я должен ссылаться при компиляции:

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

Включение math.h - это только первый шаг к получению доступа ко всем математическим функциям.

Кроме того, вам не нужно ссылаться на libm, если вы не используете его функции, даже если вы выполняете #include <math.h>, который является только информационным шагом для вас, для компилятора о символах.

stdlib.h, stdio.h относятся к функциям, доступным в libc, которые всегда связаны, так что пользователю не нужно делать это самому.

stdio является частью стандартной библиотеки C, с которой по умолчанию связывается gcc.

Реализации математических функций находятся в отдельном файле libm, который не связан по умолчанию, поэтому вы должны указать его -lm. Между прочим, между этими заголовочными файлами и файлами библиотеки нет никакой связи.

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

Операционные системы x86 (и, я полагаю, другие) должны сохранять состояние FPU при переключении контекста. Однако большинство операционных систем заботятся о сохранении / восстановлении этого состояния только после того, как приложение пытается использовать FPU в первый раз.

В дополнение к этому, в математической библиотеке, вероятно, есть какой-то базовый код, который установит FPU в нормальное базовое состояние при загрузке библиотеки.

Итак, если вы вообще не связываете какой-либо математический код, ничего из этого не произойдет, поэтому ОС вообще не нужно сохранять / восстанавливать какое-либо состояние FPU, что делает переключение контекста немного более эффективным.

Только предположение.

РЕДАКТИРОВАТЬ: в ответ на некоторые комментарии та же базовая предпосылка по-прежнему применяется к случаям, не связанным с FPU (предпосылка заключалась в том, чтобы приложения, которые не использовали libm, работали немного лучше).

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

Вдобавок, если доступно только статическое связывание, то применяется аналогичный аргумент, что он сократит размеры исполняемых файлов и время компиляции.

Обратите внимание, что -lm может не всегда указываться, даже если вы используете некоторые математические функции C.

Например, следующая простая программа:

#include <stdio.h>
#include <math.h>

int main() {

    printf("output: %f\n", sqrt(2.0));
    return 0;
}

можно скомпилировать и успешно запустить с помощью следующей команды:

gcc test.c -o test

Протестировано на gcc 7.5.0 (на Ubuntu 16.04) и gcc 4.8.0 (на CentOS 7).

Сообщение здесь дает некоторые пояснения:

Вызываемые математические функции реализуются встроенными функциями компилятора.

Смотрите также:

• https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
• https://stackoverflow.com/a/57062793/6064933

Это ошибка. Вам больше не нужно явно указывать -lm. Возможно, если на это пожалуется достаточное количество людей, это будет исправлено. (Я не верю в это всерьез, поскольку специалисты по сопровождению, которые поддерживают это различие, очевидно, очень упрямы, но я могу надеяться.)

Все библиотеки, такие как stdio.h и stdlib.h, имеют свою реализацию в libc.so или libc.a и по умолчанию связываются компоновщиком. Библиотеки для libc.so автоматически подключаются во время компиляции и включаются в исполняемый файл.
Но math.h имеет свои реализации в libm.so или libm.a, которые отделены от libc.so, и по умолчанию он не связывается, и вам нужно вручную связать его при компиляции вашей программы в gcc с помощью флага -lm.

Команда gnu gcc разработала его таким образом, чтобы он был отделен от других файлов заголовков, в то время как другие файлы заголовков связываются по умолчанию, а файл math.h - нет.

Здесь прочтите пункт № 14.3, вы можете прочитать его все, если хотите: Причина, по которой необходимо связать math.h
Посмотрите эту статью: почему мы должны связать math.h в gcc?
Взгляните на использование: с помощью библиотеки