Фишка в GCC

Может пора уже наконец почитать какую-нибудь книгу или мануал?

Что трудно ответить, а поговориьть нескем да?

нет
правильно

g++ CXXFLAGS sources.cpp LDFLAGS -o output

тогда и другим проще и сами не запутаетесь

> g++ CXXFLAGS sources.cpp LDFLAGS -o output
> тогда и другим проще и сами не запутаетесь

эмм... а что, стандартные g++ -o foo .... уже совсем не котируется?

афтору: открой для себя команду man. чес слово.

// wbr

Ну уж если верить манам то это некорректно так как должно быть так:
gcc [-c|-S|-E] [-std=standard]
[-g] [-pg] [-Olevel]
[-Wwarn...] [-pedantic]
[-Idir...] [-Ldir...]
[-Dmacro[=defn]...] [-Umacro]
[-foption...] [-mmachine-option...]
[-o outfile] [@file] infile...

У вас как минимум -o output стоит не там где надо. А вот где ставить опции для подключаемых библиотек сказано очень расплывчато, так что пруфлинк пожалуйста к вашему утверждению.

Да QT кстати собтрается сначала указывая библиотеки а потом уже исходники т. е. типа так g++ ... -lsomething .. smth.cpp :)

Афтар команду ман знает и эти маны уже до дыр протер, выключаем ЛОР-эффект плиз.

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

А поговорить на ЛОРе стало не с кем, это да...

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

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

> Я не буду обсуждать уровень Ваших ответов
Можно на "ты" (с маленькой буквы)

По озвученному тобой вопросу я думаю, что все, что ты передаешь компилятору считается входными файлами (исходниками). Исключение - параметры, начинающиеся с символа "-" и их аргументы. Нет никакой разницы в каком порядке ты передашь все это в командной строке. GCC редко позволяет выстрелить себе в ногу на столь ранней стадии.

> У вас есть пруфлинк подтверждающий правильную последовательность? Вы сами мне в мане нужное место показать сможете?

я матерюсь но не ленюсь и таки поднимаю свой зад с кресла. и ввожу что бы вы думали? www.google.com + g++ options. и первое же, что я вижу - это онлайн ман. его можно посмотреть и по man g++ - не важно.

http://linux.die.net/man/1/g++

Synopsis

gcc [-c|-S|-E] [-std=standard] [-g] [-pg] [-Olevel] [-Wwarn...] [-pedantic] [-Idir...] [-Ldir...] [-Dmacro[=defn]...] [-Umacro] [-foption...] [-mmachine-option...] [-o outfile] infile...

-llibrary
-l library
Search the library named library when linking. (The second alternative with the library as a separate argument is only for POSIX compliance and is not recommended.)

It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o searches library z after file foo.o but before bar.o. If bar.o refers to functions in z, those functions may not be loaded.

The linker searches a standard list of directories for the library, which is actually a file named liblibrary.a. The linker then uses this file as if it had been specified precisely by name.

The directories searched include several standard system directories plus any that you specify with -L.

Normally the files found this way are library files---archive files whose members are object files. The linker handles an archive file by scanning through it for members which define symbols that have so far been referenced but not defined. But if the file that is found is an ordinary object file, it is linked in the usual fashion. The only difference between using an -l option and specifying a file name is that -l surrounds library with lib and .a and searches several directories.

я потратил на изыскания ровно пять минут. три из них я наливал пиво в кружку.

// wbr

> По озвученному тобой вопросу я думаю, что все, что ты передаешь компилятору считается входными файлами (исходниками). Исключение - параметры, начинающиеся с символа "-" и их аргументы. Нет никакой разницы в каком порядке ты передашь все это в командной строке. GCC редко позволяет выстрелить себе в ногу на столь ранней стадии.

отвечу коротко: разница есть.

// wbr

Это мы уже читали. Спасибо что нашел, только я говорю туманно написано, а главное еще и не прада так как такой код:
#include <pthread.h>

void* m(void*)
{
return 0;
}

int main()
{
pthread_t th;
pthread_create(&th, 0, m, 0);
return 0;
}

одинаково пантово собирается что так:
g++ -lpthread -o test test.cc
что так:
g++ -o test test.cc -lpthread
А в мане написано, что:
Thus, foo.o -lz bar.o searches library z after file foo.o but before bar.o. If bar.o refers to functions in z, those functions may not be loaded.
Т. е. g++ -lpthread -o test test.cc работать не должно так как мой test собирается с использованием функции из pthread (если в этом кто-то сомневается попытайтесь скомпились без pthread и будете посланы компоновщиком). Для педантов могу сказать что и такое удачно работает что так:
g++ -c -o test.o test.cc
g++ -o test test.o -lpthread
что так:
g++ -c -o test.o test.cc
g++ -lpthread -o test test.o
а второе работать согласно тому что вы нагуглили работать не должно. Так что пользы от этой части мана как от козла молока. (Так что кружки пива мало, надо еще что-то...)

> Thus, foo.o -lz bar.o searches library z after file foo.o but before bar.o. If bar.o refers to functions in z, those functions may not be loaded.

если в foo и z объявлена функция с именем X, то в:
foo.o -lz - она будет взята из foo
-lz foo.o - она будет взята из z

что называется кто первый попал того и тапки. IMHO проще некуда.

// wbr

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

и специально для жителей отдалённых аулов повторяем:

если вы у себя переопределите ф-ю pthread_create() И поставите объектный файл ДО -lpthread, то вы похерите pthread. но если вы этого не делаете - а вы этого не делаете - то пох.

// wbr

Да, согласен, мой косяк.

Для С++ это бред сивой кобылы так как в одной и той же области видимости не может быть определено ДВУХ ОДИНАКОВЫХ функций а значит в foo и z не может быть определений одной и той же (с учетом полной квалификации имени по его области видимости) функции при компоновке корректного на этапе компиляции проекта. Нет если набрать кучу левых объектников и попытаться их скомпановать то... только кому оно надо?

А вообще-то для тех кто плохо знает инглицкий дословно написано что: "Таким образом, foo.o -lz bar.o ищет библиотеку z после файла foo.o но перед bar.o. Если bar.o ссылается на функцию из z, то функция может быть не загружена" Я чего-то и намека в этой фразе не вижу на ту хрень что вы только что написали. Может я не тот англицкий знаю? словариком по которому вы маны переводите не заделитесь?

> Для С++ это бред сивой кобылы так как в одной и той же области видимости не может быть определено

Области видимости здесь ни причем.

А теперь еще раз из отдаленных аулов:
А вот такое:
#include <pthread.h>

void a() {}
void b() {}
void c() {}

int main()
{
pthread_atfork(a,b,c);
return 0;
}
собрать как
g++ -lpthread -o test test.cc
хрен вам:
/tmp/cc5Px3To.o: In function `main':
test.cc:(.text+0x26): undefined reference to `pthread_atfork'
в то время как:
g++ -o test test.cc -lpthread
работает на ура.

PS:
g++ -###
Используются внутренние спецификации.
Целевая архитектура: x86_64-suse-linux
Параметры конфигурации: ../configure --prefix=/home/kde-devel/kde --infodir=/home/kde-devel/kde/share/info --mandir=/home/kde-devel/kde/share/man --libdir=/home/kde-devel/kde/lib64 --libexecdir=/home/kde-devel/kde/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/home/kde-devel/kde/include/c++/4.4 --enable-ssp --with-slibdir=/home/kde-devel/kde/lib64 --enable-__cxa_atexit --enable-libstdcxx-allocator=new --enable-version-specific-runtime-libs --program-suffix=-4.4 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=core2 --build=x86_64-suse-linux
Модель многопоточности: posix
gcc версия 4.4.1 20090423 (prerelease) (GCC)
uname -a
Linux tosh-u300 2.6.27.21-tosh-u300_kvm #2 SMP PREEMPT Sat May 9 19:53:44 MSD 2009 x86_64 x86_64 x86_64 GNU/Linux
Система OpenSUSE 11.1

Да согласен погорячился. Нельзя давать два определения в одной единице трансляции. Про первый абзац того поста признаю НЕ ПРАВ.

Короче, погуглил, почитал ман по ld, заглянул даже в "An Introduction to GCC" и выяснил, что да, библиотеки должны передаваться компилеру/линкеру после исходников/объектов, зависящих от них. Однако, есть ситуации, когда линкер может иногда кое-какие вещи разрулить сам - вне зависимости от порядка передачи библиотек. Я собрал тестовую статическую либу и у меня не получилось компильнуть использующий ее исходник, передав в командной строке -llibrary до собственно исходника. С pthread это иногда прокатывает, иногда нет.

Таким образом, желательно всегда передавать либы в конце и не е**ать себе мозг.

открой для себя pkg-config

Да для случая статической компоновки я с вами полностью согласен, про это все написано, но для случая разделяемых библиотек увы все вилами по воде. Вопрос поднятый здесь возник потому, что продемонстрированный пример (оба примера) отлично компиляться обоими методами под фряхой с gcc 4.2.1, а при порте проекта под linux возникла такая вот трабла. Отсих неясно считать это багом или нет, а если да то чего?

>Таким образом, желательно всегда передавать либы в конце и не е**ать себе мозг

Вашими устами да медбы пить. Как только вот ваш тезис донести до всех автомакефалоплодильщиков типа qmake например, а то неудобно каждый раз руками их шедевры править.

> ...для случая разделяемых библиотек...
Я не знаю как сделано во бздях, но в линуксе конкретно функция pthread_atfork находится в статической библиотеке, отсюда и твоя проблема, наверное.

> ...типа qmake...
У меня во всех мейкфайлах, сгенеренных qmake'ом, либы линкеру передаются в конце.

Ответ на этот вопрос можно найти в man ld, и ответ уже был озвучен: поиск символов компоновщиком производится слева направо в один проход.

При динамической линковке разницу ощутить сложно, при статической сразу появится куча ругани на unresolved symbols.

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

http://www.altlinux.org/TypicalPackagingErrors/LinkingError