Обьектники сгенеренные g++ какой версии можно линковать ld а не g++?

Если использовать сишные интерфейсы и не использовать глобальных объектов, то особых проблем быть с линковкой плюсовых объектников быть не должно.

А какие проблемы из «неособых» могут быть?

Объектники, сгенеренные g++ любой версии можно линковать ld:

% cat one.c  
#include <stdio.h>

extern void hello();

int main()
{
  hello();
  return 0;
}
% cat two.cpp
#include <iostream>

extern "C"
void hello()
{
  std::cout << "Hello, World!" << std::endl;
}
% gcc -c -o one.o one.c
% g++ -c -o two.o two.cpp
% ld -o main -lc /usr/lib64/crt1.o /usr/lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/crtbegin.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/crtend.o /usr/lib64/crtn.o one.o two.o -lc -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2 -lstdc++ -dynamic-linker /lib64/ld-linux-x86-64.so.2
% ./main 
Hello, World!

а что, жцц когда-то *сам* линкует?

а если речь идет об опциях линковки твоего жцц, вот полезная вещь:

$ g++ -### test.c
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1) 
COLLECT_GCC_OPTIONS='-shared-libgcc' '-mtune=generic'
 "/usr/lib/gcc/i486-linux-gnu/4.3.2/cc1plus" "-quiet" "-D_GNU_SOURCE" "test.c" "-quiet" "-dumpbase" "test.c" "-mtune=generic" "-auxbase" "test" "-o" "/tmp/ccxMlWr5.s"
COLLECT_GCC_OPTIONS='-shared-libgcc' '-mtune=generic'
 "as" "-Qy" "-o" "/tmp/ccipVp2a.o" "/tmp/ccxMlWr5.s"
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-shared-libgcc' '-mtune=generic'
 "/usr/lib/gcc/i486-linux-gnu/4.3.2/collect2" "--eh-frame-hdr" "-m" "elf_i386" "--hash-style=both" "-dynamic-linker" "/lib/ld-linux.so.2" "/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crt1.o" "/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crti.o" "/usr/lib/gcc/i486-linux-gnu/4.3.2/crtbegin.o" "-L/usr/lib/gcc/i486-linux-gnu/4.3.2" "-L/usr/lib/gcc/i486-linux-gnu/4.3.2" "-L/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib" "-L/lib/../lib" "-L/usr/lib/../lib" "-L/usr/lib/gcc/i486-linux-gnu/4.3.2/../../.." "/tmp/ccipVp2a.o" "-lstdc++" "-lm" "-lgcc_s" "-lgcc" "-lc" "-lgcc_s" "-lgcc" "/usr/lib/gcc/i486-linux-gnu/4.3.2/crtend.o" "/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crtn.o"

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

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

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

Дело тут не в линкере, а в его опциях. Например, в плюсах за вызов конструкторов и деструкторов глобальных объектов отвечает runtime, поэтому в случае уже имеющегося сишного приложения нужно изменить при линковке объектники runtime'a.

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

g++ ничего не линкует, а вызывает тот же ld с необходимыми для линковки параметрами.

Т.о. учи матчась и не задавай тупые вопросы.

в случае g++ версии до 4.3 включительно линковки плюсового рантайма через ld недостаточно чтобы плюсовый код работал как слинкованый через g++. Это прямым текстом прописано в документации на версию 4.3 и более ранние. В первую очередь за это я и не люблю C++.

я понимаю что студенты внимательно читают маны, но это не единственный вид документации описывающий поведение g++.

>я понимаю что студенты внимательно читают маны, но это не единственный вид документации описывающий поведение g++

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

> Это прямым текстом прописано в документации на версию 4.3 и более ранние.

Ссылку дайте посмотреть.

например http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Linking-a-Mixed-C_002b_002b-_0026-...

читать первый абзац. И обратите внимание что аналогичное извращение не требуется при смешивани С и Ada или C и Objective-C

толи мы смотрели разные версии толи вы не смотрели сырцы g++ ...

Первое предложение: Usually the linker of the C++ development system must be used to link mixed applications because most C++ systems will resolve elaboration issues (such as calling constructors on global class instances) transparently during the link phase.

В вольном изложении на русском языке будет: Нужно использовать линкер из вашей системы С++, потому что при его использовании такие вещи, как например вызов конструкторов глобальных объектов, решаются прозрачно.

А теперь объясните мне, где здесь написано про некорректность работы ld?

я не говорю что ld некооректно будет работать, ld просто не будет резольвить elaboration issues, что достаточно для сегфолта.

g++ при разрешении elaboration issues создает долнительный временный обьектник который передается ld.

Или вот еще цитата из доки на gcc:

There are also elaboration issues in C++ that are handled automatically. This automatic handling has the advantage of being simpler to use, but the C++ programmer has no control over elaboration. ..., a C++ compiler would simply construct a program that malfunctioned at run time.

вобщем будь у мне нехватает контроля над elaboration issues

> g++ при разрешении elaboration issues создает долнительный временный обьектник который передается ld.

откуда дровишки? где найти минимальный пример с «долнительным временным обьектником»?

> ..., a C++ compiler would simply construct a program that malfunctioned at run time.

и за троеточием, похоже, было самое важное: Where gnatbind might complain there was no valid order of elaboration,

все это вполнем можно понять как плевок в сторону компилятора плюсов в адрес того, что он может сделать дефектную инициализацию глобальных объектов, а гнат пожалуется на это; ну и что? это недочет в стандарте языка, причем тут линковка с си?