Linux C++ Как обернуть свои классы, использующие стороние библиотеки, в библиотеку?

Ну так замени

target_link_libraries(foo -lcurl)

target_link_libraries(foo "-Wl,--whole-archive" curl "-Wl,--no-whole-archive")

Тогда по идее все сработает. Для бинаря будешь писать только

project(hello_world)
set(SOURCE_EXE main.cpp) 
target_link_libraries(test foo)
add_executable(test ${SOURCE_EXE})

Вообще мне нужно вот это. http://habrahabr.ru/post/155467/ Пример 5. Внешние библиотеки и объектные файлы Я вроде все так делаю,но у ме не работает...Не могли бы Вы поправить как-то мой файл?

что за секция установки?

Скомпиляй только библиотечку. В секцию установки добавь эту библиотечку. А еще лучше оформи библиотеку отдельно, оставив только секцию установки. То есть?

C cmake было бы здорово, но может кто-то подскажет как мне подключить собранную мной библиотеку просто к проекту?

За 5 часов можно было бы прочитать руководство cmake

похоже это первый кандидат в мой игнор лист.

Masha слово man тебе знакомо?

Я пробовала компилить отдельно код клиента с полученной библиотекой libfoo.a

g++ -g *.cpp -o test -O2 -lfoo -lrt

всё больше и больше женского пола.

сиськи уже были?

Ответ на: комментарий от Masha 02.10.2013 18:22:18 Скомпиляй только библиотечку. В секцию установки добавь эту библиотечку. А еще лучше оформи библиотеку отдельно, оставив только секцию установки. То есть?

Masha (02.10.2013 18:28:26)

Тихо сам с собою я веду беседу...

Только ССЗБ вручную пишет Makefile!

разок полезно написать...

сиськи уже были?

похоже не будет. Расходимся поцаны...

ЗЫЖ по теме всё сказали уже...

Тебя ещё не задолбало?

Самое простое - при линковке указать напрямую библиотеку:

$gcc -o mega_app mega_app.cpp /home/masha/lib/libcurl/libcurl.a

http://pastebin.com/s2ejseNn

Это не позвояет статически прилинковать curl.

Хмм, а никого не смущает, что в A.h содержится

#include <curl/curl.h>

и устанавливать curl для использования библиотеки все равно придется.

Видимо, также никого не смущает плохая переносимость получившегося бинарника при использовании неродного компилятора. Это второе «хмм».

динамическую g++ -shared A.cpp -lcurl -o liba.so

статическую g++ -c A.cpp -o a.o && ar rcs liba.a a.o

клиент g++ client.cpp -la -lcurl -o client

и устанавливать curl для использования библиотеки все равно придется.

тогда так

1. скомпилять curl статиком

./configure --enable-static --prefix $HOME/build/curl make make install

я собираю с такими флагами --enable-static --disable-ldap --disable-ldaps --without-ssl --without-zlib --without-gnutls --without-nss --without-libssh2 --without-librtmp --without-libidn --disable-nls --disable-rtsp --disable-verbose

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

2. собрать свою либу: g++ -shared A.cpp $HOME/build/curl/lib/libcurl.a -o liba.so

если твоя либа статическая — то просто при сборке клиента подкидывай ему и свою либу, и curl.

т.е.

g++ client.cpp liba.a libcurl.a -o client

Почему в треде ни одного комментария про отсутствие стандартного ABI в C++?

это будет следующий вопрос ТСа :D

извини, ответил нечаянно не тебе, а abalakin, пост Linux C++ Как обернуть свои классы, использующие стороние библиотеки, в библиотеку? (комментарий) тебе адресован :D

и насчет cmake ничего не подскажу, я его ненавижу лютой ненавистью.

Дараѓой! Бабе дали задание — прокормить целую воинскую часть! Вот и выполняет. Ну, а там само собой разумеется, что помимо МСВС 2008-го года выпуска есть еще и более древние варианты…

насчет cmake ничего не подскажу, я его ненавижу лютой ненавистью

Ты руками пишешь Makefile'ы? Гы.

А вообще, это же извращение: линковать curl куда-то статически! Ну покажи мне машину, где нет libcurl! Это что — МСВС начала этого тысячелетия?

во-первых, таки есть машины где нет libcurl. например венда и андроид. насчет линукса не уверен. в базовую систему он не входит обычно, вроде.

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

в-третьих, если линкуешь динамически — придется, как Зенитару, собирать свой проект на дремучей центоси, т.к. только там есть достаточно древняя версия курла, чтобы твоя программа запустилась на других компах (где нет последней версии).

Ты руками пишешь Makefile'ы? Гы.

ну не ногами же их писать, в самом деле.

Не удается найти h-файл fatal error: A.h: No such file or directory compilation terminated.

тебе придется A.h со своей библиотекой раздавать в любом случае. а include curl перенеси в cpp.

например венда и андроид

Мы тут как бы на ЛОРе сидим, и мастдаища не касаемся. Как и остальных анально огороженных поделок.

никогда не знаешь какая версия курла окажется у юзера

И таки шо? Сложно проверить? Cmake тебе зачем?

дремучая

Хай обновляет.

придется, как Зенитару, собирать свой проект на дремучей центоси

Извращенец!

Ты — реальный извращенец! Писать Makefile'ы в тысячи строк вручную — это полный бульбец!

Мы тут как бы на ЛОРе сидим, и мастдаища не касаемся. Как и остальных анально огороженных поделок.

ну не все же, как ты, ограничивают себя только лором и линуксом.

И таки шо? Сложно проверить? Cmake тебе зачем?

я предпочитаю юзерам отдавать бинари, а не исходники.

Писать Makefile'ы в тысячи строк вручную — это полный бульбец!

а прикинь, если вножную - это просто мега-бульбец!

насчет тысяч строк ты таки загнул...

$ find ~/prj/deadbeef -name "Makefile.am" | xargs wc -l | awk '{printf "%03d %s\n", $1, $2}' | sort | tail -n 1
406 /home/waker/prj/deadbeef/plugins/gme/Makefile.am

(бОльшая часть строк — имена файлов, которые я ессно вручную не пишу)

Нет ты.

Ну вы народ даете, девушку совсем заморочили 1. автотулз легки и приятны по сравнению с cmake и писать под него значительно легче, 2. штатными средствами никак не сделать статическую либу, содержащую все зависимости. можно руками arом разобрать архивы и собрать в один, но будет огромный размер, к тому же не все либы принципиально могут так работать. Конкретный curl так можно включить, если у него позволяет лицензия.

Проблема в другом. Планируется сделать библиотеку => для доступа к классам/функциям нужен *.h. Но! в A.h уже *включено* требование curl.h => надо ставить curl не зависимо от типа сборки. Epic fail.

Одно из решений проблемы примитивное — написать новый заголовочный файл («обертку») в который выводить только внешние функции, а сам класс А «спрятать». Например, что то такое

#ifndef _MYLIB_A_H_
#define _MYLIB_A_H_

#ifdef __cplusplus
class A;
typedef A_ptr* A;
extern "C"{ // неплохо бы позаботиться о тех кто не любит С++
#else
typedewf A_ptr* void;
#endif
A_ptr *mylib_create_A(); // вызывает конструктор
void mylib_delete_A(A_ptr *); // вызывает деструктор
void mylib_A_Method(A_ptr *); // пошли методы класса
...
#ifdef __cplusplus
}
class mylibA // класс для пользователя
{
  A_ptr *self;
public:
  mylibA() { self=mylib_create_A(); }
  ~mylibA(){ mylib_delete_A(self);  }
  void Method() { mylib_A_Method(self); }
};
#endif

#endif

• curl нигде не упоминается и не нужен, а собирать можно хоть статически, хоть динамически (только предоставить библиотеку curl тоже придется);
• библиотеку можно использовать из любых языков/компиляторов без пересборки бинарников — С-ые функции вызываются откуда хочешь, а вот у С++ функций переносимость хуже;
• ABI библиотеки фиксирован и его испортить сложно, чтобы в исходном классе A не менялось — полезно для развития библиотеки;
• дополнительный префикс у класса mylibA и функций позволяет избежать конфликта имен у пользователей. При этом неплохо бы пометить все внутренние классы/функции как не экспортируемые.

Соответственно, сам файл A.h (и класс A) отдавать наружу совершенно не обязательно.

И таки шо? Сложно проверить? Cmake тебе зачем?

я предпочитаю юзерам отдавать бинари, а не исходники.

Хмм, если не open-source, то Ваше личное дело, хотя иногда приходится и исходниками делиться ...

А вообще-то cmake — наиболее простой кросс-платформенный полуавтоматический инструмент для поиска/задания всех зависимостей, флагов, опций и пр ... Ручками бывает сложно, когда проект может зависеть от пары десятков внешних библиотек (которые можно выборочно отключать), и предоставляет десяток бинарных файлов (исполняемых и библиотек)

Опс, в классе mylibA должно быть конечно же

A_ptr self;

а что, CMakeList.txt вы не руками пишете, или я чето не догоняю?

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

а что, CMakeList.txt вы не руками пишете, или я чето не догоняю?

Прикол в том, что CMakeList.txt пишется легко и непринужденно. А Makefile вручную писать — жуткий ад, особенно если нужно кучу зависимостей учесть.

Скажем (было у меня такое), нужно тебе узнать, есть ли у пользователя CUDA, а если есть, то что за возможности у видеокарты. При помощи cmake это легко делается, а если вручную в Makefile писать, боюсь, получится несколько страниц!

более говняной билд-системы еще поискать надо

А что искать? autotools же!

Вот — всего десяток строчек. Причем, в отличие от языка Makefile, язык cmake понятен.

я использую autotools для больших проектов, и plain makefiles для мелких.

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

Причем, в отличие от языка Makefile, язык cmake понятен.

может тебе еще и питон нравится? а то я такие аргументы часто слышу от питонистов, что мол «язык перл непонятен».

мне вот все понятно, и make, и automake, и cmake. и из них cmake самый идиотский.

Ну ты даешь! Да, cmake не идеален. Но autotools точно мудаками создан: если на тестирование и генерирование Makefile'а у cmake уходит пару секунд, то automake будет минуты три возиться! Вот оно — извращение!

если на тестирование и генерирование Makefile'а у cmake уходит пару секунд, то automake будет минуты три возиться

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

а cmake за кажущейся простотой позволяет писать кривые makefiles, которые в итоге работают только на машине девелопера.

а что насчет идиотского синтаксиса вместо --prefix, который каждый раз гуглить приходится, ибо запомнить нереально?

пробовал ли ты когда-нибудь собрать серию взаимо-зависимых cmake проектов куда-нибудь в $HOME/build? попробуй, получишь много радости.

медленно, зато надежно

Не медленно, а жутко медленно. Cmake лучше.

а cmake за кажущейся простотой позволяет писать кривые makefiles

А то ты не напишешь кривые makefile'ы в автомейке!

что насчет идиотского синтаксиса

Один раз потратил время, набросал "рыбу", а потом постоянно ею пользуешься. Удобно.

пробовал ли ты когда-нибудь собрать серию взаимо-зависимых cmake проектов куда-нибудь в $HOME/build?

Нафига?

А то ты не напишешь кривые makefile'ы в автомейке!

а автотулсах есть средства тестирования, чтобы убедиться, что makefiles не кривые, до релиза. вероятность выпустить проект с кривой системой сборки на порядок ниже, чем с cmake.

Один раз потратил время, набросал «рыбу», а потом постоянно ею пользуешься. Удобно.

что за рыба еще?

Нафига?

как нафига? в cmake ведь нету make uninstall, не так ли? во всяком случае, по умолчанию точно нет, и большинство девелоперов не парятся.

если насрал в /usr каким-то дерьмом — его ведь уже не вытащить оттуда.

если я хочу попробовать новую версию какого-то проекта - я собираю и запускаю в $HOME.

(тут наверное стоит уточнить — собираю и запускаю в $HOME только если есть нормальная работающая система сборки. с cmake это пока у меня ни разу не получилось сделать)

что за рыба еще?

CMakeLists.txt, который ты везде используешь с минимальными правками. Удобно.

в cmake ведь нету make uninstall, не так ли?

Да ну!

Не медленно, а жутко медленно. Cmake лучше.

Cmake быстрее, потому что он НИЧЕГО не делает.

Основное время работы при конфигурирование пакета - это компиляция и запуск маленьких программок.

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

Меня как раз волнует полное время сборки, а не то куда оно потрачено. У cmake с этим лучше.

а cmake за кажущейся простотой позволяет писать кривые makefiles, которые в итоге работают только на машине девелопера.

Ой, все программы можно написать криво ... Но мой опыт показывает, что переносимость и удобство у cmake выше.

а что насчет идиотского синтаксиса вместо --prefix, который каждый раз гуглить приходится, ибо запомнить нереально?

Зачем если есть cmake-gui ?

пробовал ли ты когда-нибудь собрать серию взаимо-зависимых cmake проектов куда-нибудь в $HOME/build? попробуй, получишь много радости.

Не поверите, но приходится это делать регулярно причем на куче систем (Ubuntu i386, Ubuntu amd64, WinXP 32bit и Win7 64bit).

CMakeLists.txt, который ты везде используешь с минимальными правками. Удобно.

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

и я пользуюсь разными компьютерами, на разных осях, в разных местах. поэтому написать некий cmakelists.txt, который я буду везде использовать, несколько затруднительно. его на флешке тогда придется таскать, или хранить в каком-то дропбоксе, а это ничем не лучше чем гуглить каждый раз.

Да ну!

читать умеешь?

по дефолту его нет. во многих проектах его нет.

вобщем, еще один минус cmake.