Проблемка: пытаюсь запустить проект в моментиксе, а компилятор выдаёт: unknown symbol: __stack_chk_guard ldd:FATAL: Could not resolve all symbols

Впервые такое вижу.

Могу завтра у коллег спросить

Будет очень круто!!!Большое спасибо!

А то ни один проект не грузится..

И тут решил скампилять с помощью MSYS2 juCi++... Я никогда бы не думал, что чутка возненавижу cmake.

Всё либы есть, но эта хреновина их не находит.

чутка?

Ага. Самую малость

Просто ещё раз убедился, что не всегда автогенераторы Makefile-ов являются панацеей при разработке.

у нас на работе вообще своя билд-система, не связанная с Makefile-ами

Норм.

for (size_t i = n - 1; i < n ; --i) { ... }

for (size_t i = n - 1; i < n ; --i) { ... }

Мило.

загадка: почему вот этот код сегфолтится? (с -mavx2 и -O3, как минимум) Бонусные очки за способ исправить vector<__m256i> v; for (int i = 0; i < 100; ++i) { v.emplace_back(); }

загадка: почему вот этот код сегфолтится? (с -mavx2 и -O3, как минимум) Бонусные очки за способ исправить vector<__m256i> v; for (int i = 0; i < 100; ++i) { v.emplace_back(); }

хм

а где аргумент в emplace_back ?

а где аргумент в emplace_back ?

дефолтный конструктор вызываю

у emplace_back (Args&&...) аргументы

а __m256i для не знающих это что? )

понятно что 256 битный инт

гцц авх интегер ?

это векторный тип, может содержать 32 x uint8_t, 16 x uint16_t или 8 x uint32_t

загадка: почему вот этот код сегфолтится? (с -mavx2 и -O3, как минимум) Бонусные очки за способ исправить vector<__m256i> v; for (int i = 0; i < 100; ++i) { v.emplace_back(); }

не проще ли reserve в таком случае сделать?

это векторный тип, может содержать 32 x uint8_t, 16 x uint16_t или 8 x uint32_t

или 4 x uint64_t

не проще ли reserve в таком случае сделать?

не поможет, с некоторой вероятность засегфолтится

точнее vector<__m256i> v(100);

хм

не поможет, с некоторой вероятность засегфолтится

на машине на которой есть avx2? :)

да)

да прост тут билдили онду херню с полной оптимизацией fpu, на старых процах где такого не было тоже падало )

уточняю

надо подумать тогда лол

это да

но тут не этот случай)

c выравниванием косяк?

c выравниванием косяк?

точно

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

директивы для __m256i нужные проставлены в либе, как я понимаю, но это не поможет

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

а, т.е. ты сам еще не разобрался ? :)

я разобрался что проблема с выравниванием и как починить, но почему конкретно компилятор натыкается на эту проблему при простом перекидывании данных туда-сюда в памяти - непонятно :)

рассказывай давай )

кастомный аллокатор ? )

стандартный аллокатор выравнивает только по sizeof(align_t), который на моей машине 16

если вместо него воткнуть boost::alignment::aligned_allocator<__m256i> то все работает корректно)

если вместо него воткнуть boost::alignment::aligned_allocator<__m256i> то все работает корректно)

охохо, а без буста хорошее тестовое задание выйдет лол

в принципе, свой аналогичный аллокатор написать тоже несложно

благо есть std::align и (местами) posix_memalign

благо есть std::align и (местами) posix_memalign

ваш посикс не посикс не под никсами)

и да, это первый раз когда мне в работе пригодился кастомный аллокатор)

ваш посикс не посикс не под никсами)

поэтому местами

Можно выделить на страницу больше и положить метадату в конец (типа оригинальный поинтер) и руками выровнять

внутри буста пачка #ifdef'ов на десяток разных случаев

и да, это первый раз когда мне в работе пригодился кастомный аллокатор)

думаю в геймдеве их активно должны юзать, поидее, надоп оглядеть сорцы UE4 на это )

думаю в геймдеве их активно должны юзать, поидее, надоп оглядеть сорцы UE4 на это )

в винде есть _aligned_malloc

пжди

http://en.cppreference.com/w/c/memory/aligned_alloc

а это?

Можно выделить на страницу больше и положить метадату в конец (типа оригинальный поинтер) и руками выровнять

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

а тьфу

там же вектор

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

Особенно когда аллокатор бадди или слаб внутри...

http://en.cppreference.com/w/c/memory/aligned_alloc

в виндовс его тоже нет, а так-то можно его в свой аллокатор завернуть тоже

в виндовс его тоже нет, а так-то можно его в свой аллокатор завернуть тоже

(или не было до какой-то версии, не уверен)

в виндовс его тоже нет, а так-то можно его в свой аллокатор завернуть тоже

ой, не обратил внимания что С11 а не С++ лол

внутри буста пачка #ifdef'ов на десяток разных случаев

во #if defined(BOOST_ALIGN_USE_ALLOCATE) #include <boost/align/detail/aligned_alloc.hpp> #elif defined(_MSC_VER) && !defined(UNDER_CE) #include <boost/align/detail/aligned_alloc_msvc.hpp> #elif defined(__MINGW32__) && (__MSVCRT_VERSION__ >= 0x0700) #include <boost/align/detail/aligned_alloc_msvc.hpp> #elif MAC_OS_X_VERSION_MIN_REQUIRED >= 1090 #include <boost/align/detail/aligned_alloc_posix.hpp> #elif MAC_OS_X_VERSION_MIN_REQUIRED >= 1060 #include <boost/align/detail/aligned_alloc_macos.hpp> #elif defined(__ANDROID__) #include <boost/align/detail/aligned_alloc_android.hpp> #elif defined(__SunOS_5_11) || defined(__SunOS_5_12) #include <boost/align/detail/aligned_alloc_posix.hpp> #elif defined(sun) || defined(__sun) #include <boost/align/detail/aligned_alloc_sunos.hpp> #elif (_POSIX_C_SOURCE >= 200112L) || (_XOPEN_SOURCE >= 600) #include <boost/align/detail/aligned_alloc_posix.hpp> #else #include <boost/align/detail/aligned_alloc.hpp> #endif

ERROR: S client not available

Можно выделить на страницу больше и положить метадату в конец (типа оригинальный поинтер) и руками выровнять

в boost/align/detail/aligned_alloc.hpp как раз это и написано

хм, идею для бота придумал, надо алексу написать

Всё либы есть, но эта хреновина их не находит.

указывай пути, cmake находит их только если они стандартные, а mingw может ставить куда угодно

у меня juci собралась с одного пинка

И тут решил скампилять с помощью MSYS2 juCi++... Я никогда бы не думал, что чутка возненавижу cmake.

да гтк под виндой такое

поэтому хоть и заявленно кроссплатформа, но все же

если вместо него воткнуть boost::alignment::aligned_allocator<__m256i> то все работает корректно)

целый буст тащить ради одного маленького аллокатора...

целый буст тащить ради одного маленького аллокатора...

зачем целый то?

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

целый буст тащить ради одного маленького аллокатора...

разумеется, перед продакшном я буст уберу

разумеется

у меня juci собралась с одного пинка

Там походу не все модули были для cmake.

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

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

Там походу не все модули были для cmake.

я просто по readme прощелкал brew install, cmake, ninja и оно собралось и даже работает

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

я что то пропустил? и есть норм менеджеры либ для С++ ?

я просто по readme прощелкал brew install, cmake, ninja и оно собралось и даже работает

Ок, тогда сегодня вечером гляну.

я что то пропустил? и есть норм менеджеры либ для С++ ?

Conan, например, перспективная.

я что то пропустил? и есть норм менеджеры либ для С++ ?

есть примерно десяток, все примерно 20% юзабельности

Conan, например, перспективная.

да такое себе

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

мне не нравится что это поверх богомерзкого cmake делают

но ничем я бы не стал пользоваться для своего проекта

абсолютно все

потому что cmake рулит

он херовый же

очень

он практичный и удобный

он практичный и удобный

толсто

и к нему есть туева гора модулей

уже написанных и работающих

а для вашего гипа - нету