http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf

Вот, например.

A type whose size cannot be represented by std::size_t is ill-formed (since C++14) круто)

c99, секции 7.17 и 7.18.3 неужель в гугле забанили?

Сеньк)

граждане, подскажите, плз, как собрать glibc? ../configure --enable-static --disable-shared --host=mipsel-elf32 --with-binutild=~/Tools4x/mipsel-elf32/bin CFLAGS='-mips32 -EL -c -Wa,-mdebug -O3 -fno-delayed-branch -fno-builtin -Wa,-ahl -Wa,-O0 -Wa,--mc24r2' ARCH=mips Ругается, что мол "GNU С library пока для вашей платформы недоступна"

для начала надо glibc-ports еще

ну и компилер под мипс

так там же есть в sysdeps /mips/mips32

А компилятор естественно есть

уху. Последняя версия ports 2.16 и в 2.16 glibc нету ещё мипса

чо?

Найти glibc-ports старше 2.16 http://ftp.gnu.org/gnu/glibc/

Короче, теперь ругается на configure: error: Operating system elf32 is not supported

если поменять --host=mipsel-elf32 то тогда он пытается юзать не тот префикс для тулзов

То есть, если сделать так: --host=mipsel-elf32-none Получаем checking for mipsel-elf32-none-g++... no checking for mipsel-elf32-none-c++... no checking for mipsel-elf32-none-gpp... no checking for mipsel-elf32-none-aCC... no checking for mipsel-elf32-none-CC... no checking for mipsel-elf32-none-cxx... no checking for mipsel-elf32-none-cc++... no checking for mipsel-elf32-none-cl.exe... no checking for mipsel-elf32-none-FCC... no checking for mipsel-elf32-none-KCC... no

ну возьми 2.27 glibc там все есть

ну а ничего что я её и пытаюсь собрать?

ты ничего не написал

Упс. Пардон. Но, вроде, логично, что я пытаюсь собрать последнюю версию.

Короче, как объяснить конфигуратору, что мне нафиг не нужен linux?

а что ты вообще хочешь сделать то

возьми openwrt и не сношай мозг

и вообще для ембеддеда лучше uclibc-ng, newlib или musl

боюсь, нам не разрешат воткнуть на то, что летает openwrt. Спасибо за ценный совет

а glibc нам надо собрать просто потому, что она у нас есть в собранном виде, от мультикора. Но собрана она немного не с теми флагами.

Народ, за что отвечает флаг -g у линкера gcc? За то же, что и компилятор? Открыл доки на опции линкера gcc, но там ни слова.

Народ, за что отвечает флаг -g у линкера gcc? За то же, что и компилятор? Открыл доки на опции линкера gcc, но там ни слова.

man ld -g Ignored. Provided for compatibility with other tools.

отладочные символы вроде

man ld -g Ignored. Provided for compatibility with other tools.

О как, спасибо.

Народ, за что отвечает флаг -g у линкера gcc? За то же, что и компилятор? Открыл доки на опции линкера gcc, но там ни слова.

-g у КОМПИЛЯТОРА отвечает за генерацию отладочной информации. -s у ЛИНКЕРА отвечает за вырезание (strip) отладочной информации.

-g у КОМПИЛЯТОРА отвечает за генерацию отладочной информации. -s у ЛИНКЕРА отвечает за вырезание (strip) отладочной информации.

Я как бэ спросил про флаг -g не у КОМПИЛЯТОРА, а у ЛИНКЕРА. Про -s я даже не писал.

Там одни и те же флаги.

И запускаешь ты порой не линкер, а только компилятор.

Короче , -g -O0 - отладочный билд. -O2(3) -s - релизный билд.

Зачем ты пытаешься ответить на то, что я не спрашивал и уже на отвеченный вопрос?

Зачем ты пытаешься ответить на то, что я не спрашивал и уже на отвеченный вопрос?

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

Зачем ты пытаешься ответить на то, что я не спрашивал и уже на отвеченный вопрос?

он бот

напиши @MasterZiv /thread

и бот прерывает тред с тем, кто это написал

и вообще для ембеддеда лучше uclibc-ng, newlib или musl

чем лучше? их разве не 1,5 инвалида пишет, которым баги править некогда?

Зачем ты пытаешься ответить на то, что я не спрашивал и уже на отвеченный вопрос?

Я предвосхищаю...

статически все линковать это хорошая идея в условиях недостатка оперативки на встроенной системе?

статически все линковать это хорошая идея в условиях недостатка оперативки на встроенной системе?

Наоборот, плохая

статически все линковать это хорошая идея в условиях недостатка оперативки на встроенной системе?

Правда, зависит от операционной системы... Там какая?

я не применительно к конкретному случаю musl и newlib это же библиотеки си, разработанные с прицелом на статическую линковку?

uclibc на мемори футпринт в ущерб бустродействию?

Правда, зависит от операционной системы... Там какая?

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

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

я не применительно к конкретному случаю musl и newlib это же библиотеки си, разработанные с прицелом на статическую линковку?

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

https://stackoverflow.com/questions/3430400/linux-static-linking-is-dead

https://stackoverflow.com/questions/3430400/linux-static-linking-is-dead

Это мягко говоря гон...

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

очень интересная теория

https://stackoverflow.com/questions/3430400/linux-static-linking-is-dead

В смысле у парня там проблемы, и он полагает, что всё должна решить статическая линковка. Ну...

https://stackoverflow.com/questions/3430400/linux-static-linking-is-dead

Нужно рассказать этим людям о том, что происходит в мире go lang. То-то удивятся.

в гугле даже не подозревают, что их подход не работает на линуксе.

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

го на глибси не завязан, там все свое носят с собой

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

Ну тут 2 вопроса: 1) какие проблемы с юникодом? 2) Какие проблемы со статической линковкой?

го на глибси не завязан, там все свое носят с собой

В этом вроде как и есть весь смысл статической линковки.

го на глибси не завязан, там все свое носят с собой

Хочет быть не завязан, но кое-где все ещё висит зависимость

Хочет быть не завязан, но кое-где все ещё висит зависимость

Разве? По-моему, там даже calling convention другой.

Хочет быть не завязан, но кое-где все ещё висит зависимость

впрочем, могу ошибаться.

Ну то есть собрал приложение а в ldd все ещё pthreads

Ну тут 2 вопроса: 1) какие проблемы с юникодом? 2) Какие проблемы со статической линковкой?

libicu на одних системах 53 версии, на других 55 версии, на третьих 57 версии. И никак не хотела линковаться статически. Уже не помню, как поборол. Наверное Qt целиком скомпиллировал без этой зависимости.

libicu на одних системах 53 версии, на других 55 версии, на третьих 57 версии. И никак не хотела линковаться статически. Уже не помню, как поборол. Наверное Qt целиком скомпиллировал без этой зависимости.

Самый лучший способ борьбы давно придуман — надо линковаться динамически)

Самый лучший способ борьбы давно придуман — надо линковаться динамически)

Это не решало проблему. В отдельных дистрибутивах не было пакетов для конкретного номера этой библиотеки.

Это не решало проблему. В отдельных дистрибутивах не было пакетов для конкретного номера этой библиотеки.

А зачем тебе конкретный номер этой библиотеки?

А зачем тебе конкретный номер этой библиотеки?

Я не знаю, как так получилось. После компиляции мой проект хотел конкретную версию libicu. А тащить ее рядом был не вариант, потому что там под сотню мегабайт.

Я не знаю, как так получилось. После компиляции мой проект хотел конкретную версию libicu. А тащить ее рядом был не вариант, потому что там под сотню мегабайт.

Феерично...

Нет, это вполне логично.

а ты не пробовал принести проекту жертву?

Версии ICU несовместимы между собой же. Вот и были пакеты отдельно для 48, 52, 53, 55, 57. Но не везде. Непонятно как задать этот депенданс. Долго бился над статической линковкой, не смог, и в итоге перекомпиллировал Qt c iconv вместо icu.

Не, там изи. При смене мелкой версии ломать Api норм.

Ребят, по c++ подскажите нубику пожалуйста, я ведь правильно понимаю, что нельзя прям в вызове функции инициализировать новый массив в виде аргумента из существующих переменных? Вопрос возник из-за аналогии с питоновским вызовом, где можно лист прям сконструировать в вызове вот так: foo([a1,b2])

Кто мы-то?

Ребят, по c++ подскажите нубику пожалуйста, я ведь правильно понимаю, что нельзя прям в вызове функции инициализировать новый массив в виде аргумента из существующих переменных? Вопрос возник из-за аналогии с питоновским вызовом, где можно лист прям сконструировать в вызове вот так: foo([a1,b2])

Можно, если статитечкий массив с заданым размером описан в качестве параметра функции

описан, а можно тогда пример такого вызова?

Ребят, по c++ подскажите нубику пожалуйста, я ведь правильно понимаю, что нельзя прям в вызове функции инициализировать новый массив в виде аргумента из существующих переменных? Вопрос возник из-за аналогии с питоновским вызовом, где можно лист прям сконструировать в вызове вот так: foo([a1,b2])

foo({a1, b2})

foo({a1, b2})

хмм, так просто?

Я думал надо указывать тип массива

Спасибо, попробую

хмм, так просто?

В массиве хранятся однотипные данные(кроме случаев с полиморфизмом), тип будет сдедуцирован(насколько я понимаю)

В проекте xalan-c в одном месте использовался VLA и не компиллируется вижуал студией. Душа болит, что делать не знаю.

хмм, так просто?

void func(const int(&arr)[2]); void gunc() { func({1,2}); }

void func(const int(&arr)[2]); void gunc() { func({1,2}); }

вооот, это уже похоже на правду!))

для void func(const int arr[2]); уже не прокатывает, ибо тип arr мутирует в просто const int*