Ориентированная на LLVM стандартная библиотека C++ теперь во FreeBSD

Самый древний C++, с которым сталкивался лично я - Borland C++ 3.0 (1991). Он был заметно беднее современного C++, но главное-то - он был, и он работал.

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

Человек - игрушка Бога. Этому - то и надо следовать. Надо жить играя.

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

всё правильно делали

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

Например, в студии до 2008 года нельзя было сделать так:

for (int i = 0; i < 2; ++i)
    putchar('#');
for (int i = 0; i < 2; ++i)
    putchar('*');
// i считается ужо объявленной

ура. наконец-то выпил гпль из бзди не за горами. ура.

В какой именно студии?

А теперь скажите мне, как осуществить такую вещь: только система собирается LLVM/Clang и библиотеку libc++, соответственно. Программы из коллекции портов нужно чтобы собирались с помощью предварительно установленного GCC 4.7 (последний снапшот) — тоже из портов. Ведь в этом случае возможны коллизии между системной библиотекой libc++ и библиотеками из binutils, которые в зависимостях с GCC 4.7, ведь так? Как этого избежать?

бздят в муку и делают пыль, якобы живые :D

У нас, это у кого?

Как этого избежать?

Очевидно, в системе будет два libc++: одна от Clang, вторая от gcc

ура. наконец-то выпил гпль из бзди не за горами. ура.

закоперастить не терпеццо?

коллизии между системной библиотекой libc++ и библиотеками из binutils, которые в зависимостях с GCC 4.7, ведь так? Как этого избежать?

Ты гонишь. Какие библиотеки в binutils? /usr/lib/libbfd-2.22-system.so, /usr/lib/libopcodes-2.22-system.so ? GCC-ная libc++ называется libstdc++

Я не в курсе о назначении binutils и слабо представляю себе организацию программного окружения времени выполнения для C/C++ программ. Расскажите, какие коллизии могут ожидать совместное сосуществование программ в одной системе, откомпилированных с помощью LLVM/Clang и GCC 4.x? На каком уровне такие коллизии разрешаются и возможно ли это разрешение?

Ты издеваешься? :-)

binutils - это компоновщики ld, gold, программы для работы с ELF-ами (readelf, ...) и проч.

Проблему теоретически *могут* быть, если, например, библиотека и программа её использующая собраны разными компиляторами (или с разными оптимизациями), но я такого никогда не встречал (только предупреждение у Апача, да Перл с Питоном заипали своими -K PIC, а так всё работало).

Программы C++ линкуются с библиотекой C++, которая всегда идёт с компилятором, *и* с библиотекой C, которая является частью системы (есть GNU libc, есть Solaris libc, FreeBSD libc). Программы на чистом C линкуются только с libc.

При этом, под libc часто понимают не только собственно libc.so.X, но и всякие ld.so.1, libsocket.so.1, libresolv.so.2 и проч.

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

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

Вопрос: *.h файлы нужны постоянно в системе и при работе программ, или без них можно обойтись во всех случаях кроме сборки? Есть ли из этого правила исключения?

binutils - это компоновщики ld, gold, программы для работы с ELF-ами (readelf, ...) и проч.

То есть binutils нужны ТОЛЬКО на этапе компиляции (компоновки) и сборки. Весь RT-слой (времени выполнения программ) находится в составе системного Clang и/или установленного GCC? Я правильно понимаю?

Если в FreeBSD полностью отказались от GNU-подсистемы сборки и RT-слоя, то что должно измениться в системе в этом случае? (У меня были ошибки установщика на этапе make installworld, когда что-то не срослось с ld*. С чем это связано я не знаю. Прошу объяснить.)

Хедеры .h или .hpp (крестовые) во время сборки пережёвывает препроцессор перед собственно компиляцией, после этого они не нужны.

в составе системного Clang и/или установленного GCC?

Можно подключить библиотеку не входящую в состав этих пакетов. Можно собрать статически, втянув либу в бинарник. В этих случаях бинарнику пофигу, чем он собран.

ошибки установщика на этапе make installworld, когда что-то не срослось с ld*

Линковщик мог не найти какие-то либы или не состыковались символы в вызывающих модулях и в вызываемых.

Если в FreeBSD полностью отказались от GNU-подсистемы сборки и RT-слоя, то что должно измениться в системе в этом случае?

У тебя не будет GNU-подсистемы сборки и RT-слоя :-)

Ибо всё основное стандартизировано: ELF, DSO и проч.

что-то не срослось с ld*

Гадать не буду.

ld тоже разные бывают. Например GNU ld (из binutils) поддерживает простые понятные mapfiles для библиотек, в общем-то в этих файлах для GNU ld указываются только версии символов. Solaris ld гораздо заковыристый: его мапфайлы имеют свой язык препроцессинга (как CPP, но начинаются с $), direct binding, filters, capabilities и проч. херь, которая результат закрытых сорцов и стремления сохранить обратную совместимость.

Плюс, с недавних пор GNU ld имеет проблему http://sourceware.org/bugzilla/show_bug.cgi?id=12548, по крайней мере на Солярке, и я склонен считать, что ни Солярка, ни GNU ld тут не виноваты (и не Дреппер ;-)

У тебя не будет GNU-подсистемы сборки и RT-слоя :-)

Это понятно. Но такая смена подсистем ворзможна в работающей системе? То есть безошибочное выполнение «make installworld» и последующий «reboot» не повлияет на следующую загрузку и работу системы и установленных программ? Не превратит ли переход от одной системы сборки и времени выполнения до этого работающую систему в набор незапускаемых файликов?

Если компилятор генерирует правильный код, то нет.

Illumos вполне себе перешёл с SolarisStudio на GCC.

Сделай zfs clone ;-)

Сделай zfs clone ;-)

Да я уже делал несколько раз «zfs rollback system/fixpoint» из-за ошибок установки ядра и/или системы на этапе «make installkernel installworld». Хотя всё компилировалось чудесно. Сейчас такие проблемы возникают только иногда, когда в /etc/src.conf что-то меняю/добавляю.

В идеале хотелось бы собирать саму систему и ядро с помощью системного LLVM/Clang 3.1, а программное обеспечение из коллекции портов с помощью GCC 4.x (тоже из коллекции, но не знаю, какая версия более подходящая).

chromium и openoffice можно форкнуть и допилить (со вторым так и сделали).

А вот как форкнуть макось?

Вопрос: *.h файлы нужны постоянно в системе и при работе программ...

Тебя подменили?!!!

Не превратит ли переход от одной системы сборки и времени выполнения до этого работающую систему в набор незапускаемых файликов?

По идее, системные *.so удаляются во FreeBSD только по «make delete-old(-libs)». А именно это и есть библиотеки времени выполнения.

Да я уже делал несколько раз «zfs rollback system/fixpoint» из-за ошибок установки ядра и/или системы на этапе «make installkernel installworld».

IMHO, можно было и не делать. Ошибки при установке - они чаще всего из-за кривых путей/проверок в Makefile-ах. Устраняется элементарным зырканием в них и перезапуском установки.

Были, правда, на моей памяти косяки и покруче, но это было от того, что время на машине резко назад дернул и с i386 на amd64 вживую переползал. ;-)

закоперастить не терпеццо?

Избавиться от анально огороженного гомна не терпеццо.