dolphin-emu - если кому-нибудь нечем заняться

My compiler is fine and cute! Did you know about LSB standard that guarantees backward compatibility?

Я бы на месте разраба не был столь дружелюбен и послал бы на хер за такой бред (к тому же безграмотный бред).

С чего ты взял, что это баг? Ничего, что C++ на месте не стоит?

А что за дискриминация? Windows 2001 года отлично поддерживается у них! А Linux только 2010 года и старше!

Потому что свежий цхх-рантайм несложно поставить в ХР, ёпт. Да и собрать нужный гцц в твоём некродистрибутиве наверно можно. Так что не ной.

относительно Windows, linux — это (сексуальное) меньшинство

> собрать нужный гцц в твоём некродистрибутиве наверно можно

Всё давно собрано и играется.

> Так что не ной.

Тема - предложение исправить ошибку в десяти строчках кода. Если никому это не нужно - все просто пройдут мимо.

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

--jit->GetBlockCache()->InvalidateICache(bp.iAddress, 4); ++jit->GetBlockCache()->InvalidateICache(bp->iAddress, 4);

Спасибо. У меня глупый вопрос - этот код только для старого GCC и ломается совместимость с новым, или теперь должно работать во всех GCC 4?

diff --git a/Source/Core/Common/Src/BreakPoints.cpp b/Source/Core/Common/Src/BreakPoints.cpp
index 62fadef..6321c26 100644
--- a/Source/Core/Common/Src/BreakPoints.cpp
+++ b/Source/Core/Common/Src/BreakPoints.cpp
@@ -114,12 +114,10 @@ void BreakPoints::Clear()
 {
        if (jit)
        {
-               std::for_each(m_BreakPoints.begin(), m_BreakPoints.end(),
-                       [](const TBreakPoint& bp)
-                       {
-                               jit->GetBlockCache()->InvalidateICache(bp.iAddress, 4);
-                       }
-               );
+               for (TBreakPoints::iterator i = m_BreakPoints.begin(); i != m_BreakPoints.end(); i++)
+               {
+                       jit->GetBlockCache()->InvalidateICache(i->iAddress, 4);
+               }
        }
        
        m_BreakPoints.clear();

// Пора бы уже выкинуть GCC 4.4

У меня глупый вопрос - этот код только для старого GCC и ломается совместимость с новым, или теперь должно работать во всех GCC 4?

В репозитории код из стандарта C++11 - используется lambda function. Предложенный код не ломает совместимость.

В RHEL 6 как раз GCC 4.4. Стабильность, энтерпрайс. А проприетарное По компилируют в CentOS 5, где GCC 4.1, потому что стандарт LSB.

Сейчас буду пробовать твой патч!

Попробовал патч из сообщения, на которое я пишу ответ.

Scanning dependencies of target common
[ 53%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Src/BreakPoints.cpp.o
/data/Разобраться/dolphin_emulator/dolphin-emu/Source/Core/Common/Src/BreakPoints.cpp: In member function ‘void BreakPoints::Clear()’:
/data/Разобраться/dolphin_emulator/dolphin-emu/Source/Core/Common/Src/BreakPoints.cpp:119: ошибка: ‘class __gnu_cxx::__normal_iterator<TBreakPoint*, std::vector<TBreakPoint, std::allocator<TBreakPoint> > >’ has no member named ‘iAddress’
make[2]: *** [Source/Core/Common/CMakeFiles/common.dir/Src/BreakPoints.cpp.o] Ошибка 1
make[1]: *** [Source/Core/Common/CMakeFiles/common.dir/all] Ошибка 2
make: *** [all] Ошибка 2
zenitur@athlon64x2 /data/Разобраться/dolphin_emulator/dolphin-emu/build $

маразм крепчал.
тебе в job

Scanning dependencies of target common
[ 53%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Src/BreakPoints.cpp.o
[ 54%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Src/CDUtils.cpp.o

Ага, с твоим патчем пошло компилироваться дальше и даже Warning'а не написало. Если скомпилируется до конца то можно даже в апстрим отправить.

Scanning dependencies of target common
[ 53%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Src/BreakPoints.cpp.o
[ 54%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Src/CDUtils.cpp.o
[ 54%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Src/ColorUtil.cpp.o
[ 54%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Src/ConsoleListener.cpp.o
[ 54%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Src/FileSearch.cpp.o
[ 54%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Src/FileUtil.cpp.o
[ 54%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Src/Hash.cpp.o
[ 54%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Src/IniFile.cpp.o
[ 54%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Src/LogManager.cpp.o
[ 55%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Src/MathUtil.cpp.o
[ 55%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Src/MemArena.cpp.o
In file included from /data/Разобраться/dolphin_emulator/dolphin-emu/Source/Core/Common/Src/MemArena.cpp:20:
/data/Разобраться/dolphin_emulator/dolphin-emu/Source/Core/Common/Src/MemArena.h:36: ошибка: нет декларации ‘nullptr’ в этой области видимости
/data/Разобраться/dolphin_emulator/dolphin-emu/Source/Core/Common/Src/MemArena.cpp: In member function ‘void* MemArena::CreateView(s64, size_t, void*)’:
/data/Разобраться/dolphin_emulator/dolphin-emu/Source/Core/Common/Src/MemArena.cpp:106: ошибка: нет декларации ‘nullptr’ в этой области видимости
/data/Разобраться/dolphin_emulator/dolphin-emu/Source/Core/Common/Src/MemArena.cpp: In function ‘bool Memory_TryBase(u8*, const MemoryView*, int, u32, MemArena*)’:
/data/Разобраться/dolphin_emulator/dolphin-emu/Source/Core/Common/Src/MemArena.cpp:198: ошибка: аргумент по умолчанию для параметра 2 ‘void* MemArena::CreateView(s64, size_t, void*)’ еще не был проанализирован
make[2]: *** [Source/Core/Common/CMakeFiles/common.dir/Src/MemArena.cpp.o] Ошибка 1
make[1]: *** [Source/Core/Common/CMakeFiles/common.dir/all] Ошибка 2
make: *** [all] Ошибка 2
zenitur@athlon64x2 /data/Разобраться/dolphin_emulator/dolphin-emu/build $

Спасибо что потратил своё время на фикс той ошибки, но похоже их будет ещё очень много. Так что бесполезно.

Если скомпилируется до конца то можно даже в апстрим отправить.

Ты тупой что ли? Если бы автор хотел писать по старому стандарту, он бы по нему писал.

Я не знаю по какому стандарту пишут программы и библиотеки другие люди, но у них компилируется везде. Ну там сто компонентов X.org, опенофис, GTK, Qt, libjpeg, libopenssl. Им не важно, GCC 4.1 у меня или 4.7.

нет декларации ‘nullptr’ в этой области видимости

Всё просто :) Надо где-нибудь (в глобальном хедере) еще дописать

#ifndef nullptr
#include <cstddef>
#define nullptr NULL
#endif

Но поддерживаю анонимуса. Новые стандарты на то они и новые.

А как запускать на том же CentOS'е? Класть в архив с бинарником libstdc++.so.6?

Класть в архив с бинарником libstdc++.so.6?

Ээ.. зачем? Оно же в процессе билда уже слинковалось с системным libstdc++

Получилось, только не в глобальном хедере, а в MemArena.h. Глобальный я не умею искать. Дополнено: о, всё, нашёл. Common.h. Готово! libcommon.a.

Они заботятся о совместимости. Но это не значит, что они обязаны это делать, просто их продукты очень много где используются, в том числе в системах, где основным компиляторм является gcc 3.x. А уж авторы развлекательного софта вроде игр и эмуляторов не обязаны тем более.

И в итоге часть программ компилируются только со всеми старыми библиотеками и компиляторами, а другая часть - только с новыми. Например, недавно мне понадобилась открытая библиотека nvtt (не помню для чего именно). Ради неё пришлось установить старый libglew, скомпилировать и вернуть прежний - изменялось только последнее число версии, сломалась совместимость с минорным релизом. Обратный же пример - этот эмулятор.

Недавно подруга восстанавливала удалённые файлы и она попросила меня помочь восстановить повреждённые файлы. Дал ей ссылку, восстановила. Программы там в основном 2005 года, конечно же для винды. В линуксе половина из них бы не скомпилировалась, а анонимусы на ЛОРе в ответ на просьбы помочь запустить ответили бы что «не нужно, протухло» и «не развивается - значит умерло».

Получается что релиз какой-либо программы запускается с компилятором плюс набором системных библиотек только того года выпуска, что и сам релиз программы. А если плюс или минус год-два - всё, не работает. Что же будет ещё через несколько лет?! Вот такой вот Open Source. За исключением некоторых ключевых системных компонентов, перечисленных выше. Вот поэтому и нужен LSB и стандартизация.

Заведи себе ЖЖ и пиши там

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

Для rhel 5 и 6 есть тру-энтерпрайзный devtoolset с gcc-4.7.

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

Интересно, поюзаю! В CentOS 5 доступен, или только в RHEL?

Есть собранный для CentOS: people.centos.org/tru/devtools-1.1/

> Ничего, что C++ на месте не стоит?

Знающие люди, скажите. C++ - это как веб-стандарты? Действительно ли оправдана злость программиста, которого попросили обеспечить поддержку компилятора 2010 года в своей программе, можно ли здесь проводить аналогию с IE6?

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

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