Включает с компоновщиком GCC Linux
Недостаточно информации, чтобы дать ответ, что за предупреждение?
Свойство colDef.sortable появилось в версии 20, возможно, вы используете более старую версию ag-Grid?
5 ответов
Хорошо. Когда Вы включаете math.h компилятор считает файл, который содержит объявления функций и макросов, которые могут использоваться. Если Вы вызываете функцию, объявленную в том файле (заголовок), то компилятор вставляет команду вызова в то место в Вашем объектном файле, который будет сделан из файла, который Вы компилируете (давайте назовем его test.c и объектный файл создается test.o). Это также добавляет запись в таблицу перемещения того объектного файла:
Relocation section '.rel.text' at offset 0x308 contains 1 entries:
Offset Info Type Sym.Value Sym. Name
0000001c 00000902 R_386_PC32 00000000 bar
Это было бы записью перемещения для функциональной панели. Запись в таблице символов будет сделана, отмечая, что функция все же не определена:
9: 00000000 0 NOTYPE GLOBAL DEFAULT UND bar
Когда Вы связываетесь test.o объектный файл в программу, необходимо связаться против математической названной библиотеки libm.so . so расширение подобно .dll расширение для окон. Это означает, что это - файл общего объекта. Компилятор, при соединении, будет фиксация все места, которые появляются в таблице перемещения test.o, замена его записей с надлежащим адресом функции панели. В зависимости от того, используете ли Вы общую версию библиотеки или статической (это называют libm.a затем), компилятор сделает ту фиксацию после компиляции, или позже, во времени выполнения при фактическом запуске программы. По окончании это введет запись в таблице общих библиотек, необходимых для той программы. (с можно показать readelf -d ./test):
Dynamic section at offset 0x498 contains 22 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libc.so.6]
... ... ...
Теперь, если Вы запустите свою программу, то динамический компоновщик будет поиск, что библиотека, и свяжет ту библиотеку с Вашим исполняемым изображением. В Linux называют программу, делающую это ld.so. Статические библиотеки не имеют места в динамическом разделе, поскольку они просто связаны с другими объектными файлами, и затем о них забывают; они - часть исполняемого файла с тех пор.
В действительности это на самом деле намного более сложно, и я также не понимаю это подробно. Это - грубый план, все же.
Существует несколько аспектов, включенных здесь.
Во-первых, заголовочные файлы. Компилятор просто включает содержание файла в местоположении, где это было включено, ничто больше. Насколько я знаю, GCC даже не рассматривает стандартные заголовочные файлы по-другому (но я мог бы быть неправым там).
Однако заголовочные файлы не могли бы на самом деле содержать реализацию, только ее объявление. Если реализация расположена где-то в другом месте, необходимо сказать компилятор/компоновщика это. По умолчанию Вы делаете это путем простой передачи соответствующих файлов библиотеки компилятору, или путем передачи названия библиотеки. Например, следующие два эквивалентны (при условии, что libcurl.a находится в каталоге, где это может быть найдено компоновщиком):
gcc codefile.c -lcurl
gcc codefile.c /path/to/libcurl.a
Это говорит редактору связей (“компоновщик”) связывать Ваш файл кода против реализации статической библиотеки libcurl.a (компилятор gcc на самом деле игнорирует эти аргументы, потому что это не знает, что сделать с ними и просто передает их компоновщику). Однако это называют статическим подключением. Существует также динамическое подключение, которое происходит при запуске Вашей программы, и которое происходит с .dlls в соответствии с Windows (тогда как статические библиотеки соответствуют .lib файлы в Windows). Динамические файлы библиотеки в соответствии с Linux обычно имеют расширение файла .so.
Лучший способ узнать больше об этих файлах состоит в том, чтобы ознакомиться с компоновщиком GCC, ld, а также превосходный набор инструментов binutils, с которым можно редактировать/просматривать файлы библиотеки легко (любые файлы двоичного кода, действительно).
Существует ли эквивалентное понятие к Windows DLLs под *, отклоняют?
Да их называют "Общими объектами" или .so файлами. Они динамично связаны в Ваш двоичный файл во времени выполнения. В Linux можно использовать команду "ldd" на исполняемом файле для наблюдения, с какими общими объектами двоичный файл связан. Можно использовать ListDLLs от sysinternals для выполнения того же самого в окнах.
Компилятору позволяют сделать независимо от того, что ему нравится, целый, в действительности, он действует, как будто Вы включали файл. (Все компиляторы, которые я знаю, включая GCC, просто включают файл, названный math.h.)
И не, это обычно не содержит функциональные определения само. Это - libm.so, "общий объект", подобный окнам.DLLs. Это должно быть в каждой системе, поскольку это - компаньон libc.so, времени выполнения C.
Править: И вот почему необходимо передать-lm компоновщику при использовании математических функций - он дает этому команду связываться против libm.so.
Существует. Включение делает текстовое, включают заголовочного файла (который является стандартным поведением C/C++). То, что Вы ищете, является компоновщиком.-l аргумент gcc/g ++ говорит компоновщику что библиотеку (библиотеки) включить. Для математики (libm.so), Вы использовали бы-lm. Общий шаблон:
- исходный файл: #include <foo.h>
- gcc/g ++ командная строка:-lfoo
- общая библиотека: libfoo.so
math.h является небольшой вариацией на эту тему.