Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий"" (Библиотеки, утилита libtool)

Модератор: Модераторы разделов

Ответить
Аватара пользователя
жучара
Сообщения: 937
ОС: астралинукс

Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение жучара »

Друзья! Вот эта статья.
http://www.linuxcenter.ru/lib/books/linuxdev/linuxdev6.phtml

Так-то я вроде всё понял. С этим тоже разобрался
http://pyviy.blogspot.com/2010/12/gcc.html

Но некоторые тык скыть непонятности остались.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++=

Исходники. Взял из статьи и сильно-сильно упростил
main.c

Код: Выделить всё

////////////////////////////////////////
// main.c
#include <stdio.h>
#include "calculate.h"

int main(void)
{
  printf ("%f\n", Calculate());
  return 0;
}
calculate.c

Код: Выделить всё

//////////////////////////////////
// calculate.c
#include <stdio.h>
#include <math.h>
#include "calculate.h"

float Calculate()
{
  float x = sin(3);
  return(sin(2));
}
calculate.h

Код: Выделить всё

///////////////////////////////////////
// calculate.h
#ifndef CALCULATE_H_
#define CALCULATE_H_

#ifdef __cplusplus
extern "C" {
#endif /*__cplusplus*/

float Calculate();

#ifdef __cplusplus
}
#endif /*__cplusplus*/
#endif /*CALCULATE_H_*/
Cхема простая. Если соберём проект, то из функции main(), которая в файле main.c вызовется функция calculate(), которая в файле calculate.c, а из неё вызовется функция sin() математической библиотеки. Всё просто.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++=

Обратимся к статье:
Давайте создадим подключаемую библиотеку из исходника calculate.c. Для этого вначале создадим объектный файл.

Shell

user@astra:~libtooldemo$ libtool compile gcc -c calculate.c
libtool: compile: gcc -c calculate.c -fPIC -DPIC -o .libs/calculate.o
libtool: compile: gcc -c calculate.c -o calculate.o >/dev/null 2>&1
user@astra:~$
...
Наконец сформируем саму библиотеку.

Shell

user@astra:~$
user@astra:~$ libtool link gcc -rpath /usr/local/lib -o libcalculate.la calculate.lo
libtool: link: gcc -shared -fPIC -DPIC .libs/calculate.o -Wl,-soname -Wl,libcalculate.so.0 -o .libs/libcalculate.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libcalculate.so.0" && ln -s "libcalculate.so.0.0.0" "libcalculate.so.0")
libtool: link: (cd ".libs" && rm -f "libcalculate.so" && ln -s "libcalculate.so.0.0.0" "libcalculate.so")
libtool: link: ar cru .libs/libcalculate.a calculate.o
libtool: link: ranlib .libs/libcalculate.a
libtool: link: ( cd ".libs" && rm -f "libcalculate.la" && ln -s "../libcalculate.la" "libcalculate.la" )
user@astra:~$
...
Содержимое файла libcalculate.a связывается с программой при компоновке, но библиотечных функций этот файл не содержит. Она содержит лишь ссылку на другой файл – libcalculate.so, который содержит библиотечные функции и связывается с программой динамически, то есть, по требованию в процессе выполнения программы.
Ерунда какая-то по-моему, нет? libcalculate.a сам по себе, содержит ссылку на sin(), при чём тут libcalculate.so? libcalculate.a и libcalculate.so друг без друга вполне себе существуют и проект компилится как с одной, так и с другой библиотекой по отдельности. Так что что там за ссылка, я понять не могу, не разъяснит ли кто-нибудь? Спасибо, кто откликнется.
Я просто читаю маны.
Спасибо сказали:
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение Hephaestus »

жучара писал(а):
02.08.2019 19:57
Ерунда какая-то по-моему, нет? libcalculate.a сам по себе, содержит ссылку на sin(), при чём тут libcalculate.so?
Файл libcalculate.a - это архив,
содержимое можно посмотреть командой ar t libcalculate.a,
тогда будет видно, что внутри содержится calculate.o.
Это не совсем ссылка на sin(), но близко.

Затрудняюсь, рассудить, где правда, но...
Либо ошибка в тексте,
либо libtool тогда (в 2006 году) работал работал как-то иначе,
либо при сборке подхватывается libcalculate.a, который содержит calculate.o, который затребует libcalculate.so (не похоже),
либо я чего-то не понимаю.
жучара писал(а):
02.08.2019 19:57
libcalculate.a и libcalculate.so друг без друга вполне себе существуют и проект компилится как с одной, так и с другой библиотекой по отдельности.
Да. Насколько мне известно, libcalculate.a - это статическая библиотека, libcalculate.so - динамическая.
Обе сразу не нужны, очевидно.
жучара писал(а):
02.08.2019 19:57
Так что что там за ссылка, я понять не могу, не разъяснит ли кто-нибудь?
Я там никаких ссылок не увидел.
В выводе libtool видно, что сборка проводилась с опцией -shared, значит линковка динамическая,
и если собрать исполняемый файл, он при запуске будет таки просить libcalculate.so.
Более того, libcalculate.a можно удалить и всё спокойно соберется
libtool link gcc -o kalkul main.c libcalculate.la
как видно, при сборке указывается libcalculate.la и в результате подхватится libcalculate.so.

А вот если явно указать использование libcalculate.a
libtool link gcc -o kalkul main.c ./.libs/libcalculate.a
тогда динамическая библиотека не будет использоваться - получится статическая линковка.
Добавлено (23:31):
А позвольте полюбопытствовать, на кой Вам нужен libtool? Да ещё такая старая статья по нему?
Я когда в своё время разбирался с autotools, libtool пропустил мимо (вообще не вникал) и спокойно обошёлся без него, даже нехватки не ощутил.
Последний раз редактировалось Hephaestus 03.08.2019 11:53, всего редактировалось 1 раз.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Аватара пользователя
жучара
Сообщения: 937
ОС: астралинукс

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение жучара »

Hephaestus, вы знаете, я так и думал. Цитата из текста:
Содержимое файла libcalculate.a связывается с программой при компоновке, но библиотечных функций этот файл не содержит. Она содержит лишь ссылку на другой файл – libcalculate.so, который содержит библиотечные функции и связывается с программой динамически, то есть, по требованию в процессе выполнения программы.
Если бы вместо libcalculate.so было написано libm.so, я бы согласился. Как вы сказали,
Hephaestus писал:
02.08.2019 23:26
Это не совсем ссылка на sin(), но близко.
+++++++++++++++++++++++++++++++++++++++++++++++++++

Но дальше интереснее ещё будет. Речь пойдёт о параметре -rpath команды libtool
Для этого вначале создадим объектный файл.

Shell

user@astra:~$ libtool compile gcc -c calculate.c
libtool: compile: gcc -c calculate.c -fPIC -DPIC -o .libs/calculate.o
libtool: compile: gcc -c calculate.c -o calculate.o >/dev/null 2>&1
user@astra:~$
...
Наконец сформируем саму библиотеку.

Shell

user@astra:~$
user@astra:~$ libtool link gcc -rpath /usr/local/lib -o libcalculate.la calculate.lo
libtool: link: gcc -shared -fPIC -DPIC .libs/calculate.o -Wl,-soname -Wl,libcalculate.so.0 -o .libs/libcalculate.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libcalculate.so.0" && ln -s "libcalculate.so.0.0.0" "libcalculate.so.0")
libtool: link: (cd ".libs" && rm -f "libcalculate.so" && ln -s "libcalculate.so.0.0.0" "libcalculate.so")
libtool: link: ar cru .libs/libcalculate.a calculate.o
libtool: link: ranlib .libs/libcalculate.a
libtool: link: ( cd ".libs" && rm -f "libcalculate.la" && ln -s "../libcalculate.la" "libcalculate.la" )
user@astra:~$
Опция -rpath с указанием пути к стандартному каталогу библиотек указывает компоновщику, что необходимо создать библиотеку с динамическим связыванием, то есть предусмотреть оба – и a-файл и so-файл, и что они при инсталляции будут помещаться именно в тот каталог, который указан после -rpath. Путь к этому каталогу будет сохранён в a-файле, и именно по этому пути будет осуществляться поиск динамической библиотеки.
...Позвольте. Вот тут
http://pyviy.blogspot.com/2010/12/gcc.html

Чётко сказано, зачем нужен -rpath. Он определяет путь, по которому загрузчик ищет динамические библиотеки во время исполнения и этот путь прописан в исполняемый файл. Практика вышесказанное подтверждает.

В данном же случае -rpath не параметр gcc, а параметр libtool (код shell это подтверждает), следовательно, роль у него другая может быть. Какая же? А вот, ещё раз:
Путь к этому каталогу будет сохранён в a-файле, и именно по этому пути будет осуществляться поиск динамической библиотеки.
:wacko:

Что-то тут не то. На всякий случай скропаем исполняемый файл и посмотрим, не затесался ли туда путь /usr/local/lib

Shell

user@astra:~$ libtool link gcc -o kalkul main.c libcalculate.la -lm
libtool: link: gcc -o .libs/kalkul main.c ./.libs/libcalculate.so -lm
user@astra:~$
Нет, не затесался. Не видно, чтобы /usr/local/lib как-то участвовал в создании исполняемого файла. На всякий случай:

Shell

user@astra:~$ objdump -p .libs/kalkul | grep RPATH
user@astra:~$
Так, а под конец автор выдал:
И вот здесь скорее всего многих из вас ждёт неприятный сюрприз – программа первый раз не запустится. Она выдаст сообщение:
...
И потом предложил путь для поиска динамических библиотек прописывать вручную в LD_LIBRARY_PATH (я не пробовал). Ну, допустим.

Но -rpath-то тут зачем?
Я просто читаю маны.
Спасибо сказали:
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение Hephaestus »

жучара писал(а):
03.08.2019 10:19
...Позвольте. Вот тут
http://pyviy.blogspot.com/2010/12/gcc.html

Чётко сказано, зачем нужен -rpath. Он определяет путь, по которому загрузчик ищет динамические библиотеки во время исполнения и этот путь прописан в исполняемый файл. Практика вышесказанное подтверждает.
Это был уже другой тирлим-бом-бом. (с)Винни-Пух
В смысле, это другой -rpath, который для gcc.
Я не работал вплотную с libtool. Насколько я могу судить - это "обёртка", которая вызывает компилятор, линковщик, инсталлятор и передаёт им нужные параметры. Поэтому у libtool есть "свой" -rpath.
жучара писал(а):
03.08.2019 10:19
В данном же случае -rpath не параметр gcc, а параметр libtool (код shell это подтверждает), следовательно, роль у него другая может быть. Какая же? А вот, ещё раз:
Путь к этому каталогу будет сохранён в a-файле, и именно по этому пути будет осуществляться поиск динамической библиотеки.
:wacko:

Что-то тут не то.
Могу только ещё раз предположить, что libtool в 2006 году и нынешний libtool - это разные вещи.
Либо это просто криво сформулированные фразы в тексте.
Смотрите сами:
Содержимое файла libcalculate.a связывается с программой при компоновке, но библиотечных функций этот файл не содержит. Она содержит лишь ссылку на другой файл – libcalculate.so, который содержит библиотечные функции и связывается с программой динамически, то есть, по требованию в процессе выполнения программы.
Она содержит ссылку. Кто это "Она"? "Содержимое файла" - "она"? "Этот файл" - "она"? Программа - "она"?
Непонятно.
Я не очень понимаю, как можно в a-файле сохранить "ссылку на другой файл" или "Путь к каталогу",
поскольку a-файл - это архив. Man-страница не прояснила этот момент.
Кроме того, a-файл - это статическая библиотека, ссылка на so-файл там совершенно ни к чему.
Я припоминаю, встречались какие-то a-файлы, содержащие внутри себя so-файлы, но это, скорее всего, я что-то путаю.
жучара писал(а):
03.08.2019 10:19
Так, а под конец автор выдал:
И вот здесь скорее всего многих из вас ждёт неприятный сюрприз – программа первый раз не запустится. Она выдаст сообщение:
...
И потом предложил путь для поиска динамических библиотек прописывать вручную в LD_LIBRARY_PATH (я не пробовал). Ну, допустим.
Я пробовал. Всё запустилось без проблем. Путь указывать не пришлось.
жучара писал(а):
03.08.2019 10:19
Но -rpath-то тут зачем?
Современный libtool требует обязательного указания mode. Для каждого mode есть свой help.
libtool --mode=link --help
.......
-rpath LIBDIR the created library will eventually be installed in LIBDIR
.......
Однако при установке путь всё равно нужно указывать явно. Мутно это всё как-то.

Я могу Вам лишь посоветовать воспользоваться актуальной документацией по libtool, если уж Вы никак не можете без libtool обойтись.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Аватара пользователя
жучара
Сообщения: 937
ОС: астралинукс

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение жучара »

Hephaestus, вот именно, что я разделяю и высказываю то же самое недоумение.

Короче, как я понял, из этой статьи нужно только взять команды и разобраться с ними. А пояснения такие пояснения...
Hephaestus писал:
02.08.2019 23:26
А позвольте полюбопытствовать, на кой Вам нужен libtool? Да ещё такая старая статья по нему?
что изучать не знаю, поэтому изучаю всё подряд. Короче, что есть, то и ем.
Я просто читаю маны.
Спасибо сказали:
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение Hephaestus »

жучара писал(а):
04.08.2019 11:26
Короче, как я понял, из этой статьи нужно только взять команды и разобраться с ними. А пояснения такие пояснения...
Статья - сентябрь 2006 года. Я ради смеха развернул на ВМ slackware, соответствующую тому времени (версия 11.0) и посмотрел, как там работает libtool, что даёт на выходе.
Так вот, на выходе тогдашний libtool выдаёт то же, что и сейчас - a-файл с объектным файлом внутри.
Посему вот это
Hephaestus писал:
02.08.2019 23:26
либо libtool тогда (в 2006 году) работал работал как-то иначе
Hephaestus писал:
03.08.2019 12:59
libtool в 2006 году и нынешний libtool - это разные вещи
Не подтверждается, в смысле выдаваемых результатов.

А вот это
Hephaestus писал:
03.08.2019 12:59
Либо это просто криво сформулированные фразы в тексте.
больше похоже на правду.
жучара писал(а):
04.08.2019 11:26
что изучать не знаю, поэтому изучаю всё подряд. Короче, что есть, то и ем.
Понятно. Ну тогда хоть изучайте по актуальным материалам.В оригинальную документацию загляните, например. Но вот конкретно libtool - вещь довольно бесполезная. Я совершенно спокойно обходился без неё.
Судя по разным, встречавшимся в Сети мнениям, libtool - это набор костылей к autotools для работы с библиотеками. Мне ни разу не пригодилось.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение Bizdelnick »

Hephaestus писал:
05.08.2019 06:52
Но вот конкретно libtool - вещь довольно бесполезная. Я совершенно спокойно обходился без неё.
Если использовать autotools для сборки библиотек, libtool необходим. Но это такая кривая, глючная и захлебнувшаяся в собственной переусложнённости штука, что это просто является ещё одним поводом не использовать autotools.
Кстати, в Debian libtool частенько бывает поломан ещё больше, чем оригинальный. В частности, в stretch и buster я натыкался на баги, которых нет в апстриме.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение Hephaestus »

Bizdelnick писал:
05.08.2019 11:17
Если использовать autotools для сборки библиотек, libtool необходим.
Это точно? Я прикручивал autotools к программе, у которой изначально были только make-файлы.
То есть я использовал Automake, Autoconf, писал с нуля configure.ac, am-файлы и т.д.
Всё собиралось, в том числе и библиотеки - без libtool. Совершенно спокойно.
Может, оно там неявно где-то подтягивалось - не знаю, не замечал.
По крайней мере, специально я libtool не задействовал.
Насколько я понимаю, libtool, собирая библиотеку, дергает компилятор и линковщик с нужными параметрами,
так сборку библиотеки можно указать в am-файле с таким же успехом.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение Bizdelnick »

Hephaestus писал:
05.08.2019 15:25
Я прикручивал autotools к программе, у которой изначально были только make-файлы.
То есть я использовал Automake, Autoconf, писал с нуля configure.ac, am-файлы и т.д.
Всё собиралось, в том числе и библиотеки - без libtool. Совершенно спокойно.
А зачем Вы прикручивали autotools? Если для переносимости, то своей цели Вы явно не добились: проблемы вылезут при статической линковке, если у библиотеки есть хотя бы одна внешняя зависимость. Если же переносимость не нужна, то и autotools не нужны, можно спокойно обходиться make.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение Hephaestus »

Bizdelnick писал:
05.08.2019 15:32
А зачем Вы прикручивали autotools?
Мне хотелось, чтобы при сборке анализировалось наличие библиотек, версии, создавались make-файлы и т.д. Те make-файлы, которые были изначально, содержали жестко прописанные пути и вообще требовали ручной корректировки. От этого хотелось избавиться.
Bizdelnick писал:
05.08.2019 15:32
Если для переносимости, то своей цели Вы явно не добились
Это как посмотреть. Я тестировал процесс сборки на Linux 32bit, Linux 64bit, и на Windows под cygwin в режиме кросс-компиляции (чтобы бинарники получились нативными для win). Всё работало. Без libtool.
Сейчас вот думаю перевести всё это дело на cmake.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение Bizdelnick »

Hephaestus писал:
05.08.2019 17:35
Те make-файлы, которые были изначально, содержали жестко прописанные пути и вообще требовали ручной корректировки. От этого хотелось избавиться.
Ну и переписали бы эти мейкфайлы по-человечески. Когда нужна сборка только под GNU, GNU и GNU, это проще.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение Hephaestus »

Bizdelnick писал:
05.08.2019 18:28
Ну и переписали бы эти мейкфайлы по-человечески.
Так неинтересно. Хотелось поковырять autotools - это во-первых,
а во-вторых, хотелось автоматизировать создание make-файлов.
Bizdelnick писал:
05.08.2019 18:28
Когда нужна сборка только под GNU, GNU и GNU, это проще.
Там не совсем GNU. Там всё-таки нативные файлы под Win в одном случае.

Но всё это никак не отменяет того факта, что libtool ни разу не понадобился.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение Bizdelnick »

Hephaestus писал:
06.08.2019 08:01
хотелось автоматизировать создание make-файлов
А какой смысл его автоматизировать, если для этого надо написать больше кода, чем было бы в самих мейкфайлах?
Hephaestus писал:
06.08.2019 08:01
Там не совсем GNU. Там всё-таки нативные файлы под Win в одном случае.
Так тулчейн-то всё равно от GNU.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение Hephaestus »

Bizdelnick писал:
06.08.2019 08:58
А какой смысл его автоматизировать, если для этого надо написать больше кода, чем было бы в самих мейкфайлах?
Смысл в предварительной проверке. Наличие компилятора, библиотек, проверка их версий, определение путей к файлам.
С учетом того, что сборка может происходить на разных системах и даже разных платформах, это не будет лишним.
Можно ли всё это организовать на "чистом make" - я не знаю. По крайней мере, те материалы по make, которые я видел, не содержали таких сведений. Рискну предположить, что если бы было можно всё сделать с помощью make, то ни autotools, ни cmake не появились бы.
Кроме того, сборочные файлы нужно написать один раз и потом использовать. А make-файл вполне может не заработать на другой системе. Как у меня не заработал, например.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение Bizdelnick »

Hephaestus писал:
06.08.2019 13:11
Смысл в предварительной проверке. Наличие компилятора, библиотек, проверка их версий, определение путей к файлам.
Компилятор во всех случаях называется gcc, при его отсутствии сборка упадёт сразу же. Всё, касающееся библиотек, можно получить от pkg-config (или, в отдельных случаях, <libname>-config).
Hephaestus писал:
06.08.2019 13:11
Кроме того, сборочные файлы нужно написать один раз и потом использовать. А make-файл вполне может не заработать на другой системе. Как у меня не заработал, например.
В обоих случаях всё зависит от того, как писать.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
s.xbatob
Сообщения: 1139
ОС: Fedora

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение s.xbatob »

В любом случае -- отстаньте от autotools. Он своё отработал и сейчас он свои функции не отрабатывает. Если в проекте изначально он был, то его поддерживать ещё можно. Но переводить на него те проекты, где он до этого не использовался -- это мазохизм









е свои функции не отрабатывает. Если в проекте изначально он был, то его поддерживать ещё можно. Но переводить на него те проекты, где он не использовался
Спасибо сказали:
Аватара пользователя
жучара
Сообщения: 937
ОС: астралинукс

Re: Несколько вопросов по статье "Разработка программного обеспечения для Linux. Инструментарий""

Сообщение жучара »

s.xbatob, что есть, то и ем. Было сказано что-нибудь читать. Вот что-нибудь и читаю.
Я просто читаю маны.
Спасибо сказали:
Ответить