g++ без libstdc++ — можно ли это сделать? - очень настраиваемая облегченная libstdc++, из которой я могу легко извлечь что-то, также поможет

Да, такие вещи, как operator new и operator delete, действительно определены в C++, не в C, поэтому было бы абсурдно иметь их в библиотеке времени выполнения для C, а не для C++ (то же самое для " чистый виртуальный», используемый для четкой диагностики неправомерных вызовов чисто виртуальных методов и т. д.). Если вы компонуете весь свой исполняемый файл без доступа к динамической библиотеке, компоновщик должен (надеюсь, в зависимости от того, насколько модульно закодирована библиотека времени выполнения C++) выбирать и выбирать самую минимальную часть стандартной библиотеки C++, которую вы используете в своем коде (и чем меньше специфических функций C++ вы используете, таких как new, подразумевающий delete для вызовов деструктора и т. д., тем больше у вас шансов избежать извлечения больших кусков библиотеки, конечно;-).

Может быть, этот ответ немного запоздал, но...

Писать программы на С++ без libstdС++ легко. Я делаю это десятилетиями. Просто избегайте связывания с libstdc++. Это просто: либо используйте для линковки gcc вместо g++, либо предоставьте поддельную libstdc++ только с новыми, del и некоторыми другими функциями.

Вот пример того, как вы можете заменить базовую функциональность libstdc++ прозрачной оболочкой для malloc:

#include <stdlib.h>

// MSVC uses __cdecl calling convention for new/delete :-O
#ifdef _MSC_VER
#  define NEWDEL_CALL __cdecl
#else
#  define NEWDEL_CALL
#endif

extern "C" void __cxa_pure_virtual ()
{
    abort ();
}

void * NEWDEL_CALL operator new (size_t size)
{
    return malloc (size);
}

void * NEWDEL_CALL operator new [] (size_t size)
{
    return malloc (size);
}

void NEWDEL_CALL operator delete (void *p)
{
    if (p) free (p);
}

void NEWDEL_CALL operator delete [] (void *p)
{
    if (p) free (p);
}

void NEWDEL_CALL operator delete (void *p, size_t)
{
    if (p) free (p);
}

Теперь поместите это в файл с именем, скажем, libstd--.cpp, и соберите свой собственный libstdc++.a:

gcc -c -O libstdc--.cpp
ar crs libstdc++.a libstdc--.o

Тогда вы можете попробовать простой тест:

class A
{
    int *x;

public:
    A () { x = new int [10]; }
    ~A () { delete [] x; }
};

int main ()
{
    A a;
    return 0;
}

Скомпилируйте и посмотрите, что связано:

g++ -g test.cpp -o test -L.

# ldd ./test
    linux-vdso.so.1 (0x00007ffed0b8d000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f4d18df0000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4d18bd9000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f4d18823000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f4d1913b000)

Эй, смотри, ма, никакого libstdc++!

В качестве альтернативы вы можете избежать использования фальшивого libstdc++, связавшись с gcc вместо g++ и указав libstdc--.o в командной строке компоновщика, чтобы ваш код мог найти замену news и удалить.

Попробуйте связать с libsupc++.a. Это голая библиотека C++ support, без тяжеловесных функций iostreams или чего-то подобного.

Я не уверен, но я полагаю, что использование этого вместо libstdc++.a позволит получить «автономную» реализацию C++, в отличие от «размещенной» или полной реализации, как определено в пункте 1 стандарта.

Вот хорошее объяснение:

http://www.trilithium.com/johan/2005/06/static-libstdc/

В статье объясняется более подробно, но одной из основных причин для этого является то, что специфичные для C++ библиотеки имеют тенденцию быть менее стабильными, чем базовый материал libc. Это может помочь уменьшить проблемы с зависимостями.

Другой подход может состоять в том, чтобы "статифицировать" вашу программу. Это означает встроить все библиотеки в статический исполняемый файл, и таким образом ваш код всегда будет использовать glibc, который был в машине, которую вы использовали для компиляции. Единственное, что вам нужно, это совместимое ядро ​​​​на работающей машине. Я знаю две программы для этого, одна с открытым исходным кодом:

• Статификатор эльфов

а другой - коммерческое программное обеспечение:

• Горностай

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