Closed joolswills closed 7 years ago
6852c602b9238fe7386d47155715ef480473f55d is the first bad commit
commit 6852c602b9238fe7386d47155715ef480473f55d
Author: Florent Castelli <florent.castelli@gmail.com>
Date: Wed Oct 12 17:30:18 2016 +0200
glew: Move to ext
:100644 100644 e335358d5d7331d72df2d87bd859dc15b439c4c8 cbda75bb1f062db63be9571c4d7eaf4a6a6cb49a M .ycm_extra_conf.py
:100644 100644 c81809a5d8427461923636dd717e36b180a6d771 39318dd94b1f33725cc542fb5fa2a895351c3282 M CMakeLists.txt
:040000 040000 6444439e500c1501af7dff256e0f5e119e3c66b8 e468745d398abdea204c47bbe7e3c4f29b25fb97 M Core
:040000 040000 24244376fb23f329489e5c49f4435e20fd4f76ed edc57679844de21b3114860e9ae81788dc792aee M GPU
:040000 040000 66801c105360f758f2deabf27fe9d9c10c899638 d25c1216a76cf98b762283013b7ac9f99d405145 M UI
:040000 040000 a762fdd906d5a90ac526643975c103463bbb61e4 38801b591c9e2fb994be643aeadec3abb5b28bc3 M Windows
:040000 040000 8ada7a258b5431fa3aecd294efd7b897df13686a cd25fbd025b49bafe9d37aff8cf9b90c04f5df04 M ext
:040000 040000 9fa10d5f18dea4dca4d7599623879c8d80043150 78fe620ae4938d40ad5c25f3e7de89d358b03c86 M headless
:040000 040000 e29cb916d27f5a5723dcbb61ead674f411a80387 837a2b78e3d22d387935a333aca881648c451286 M unittest
Weird, got to be another link order problem? @Orphis
Well, it works on CI, so I don't think so. Can you remove your build folder and retry?
Same here on Fedora 25 x86_64. Rebuilding does not help.
I can confirm - my original report above was from a fresh build.
Did you actually remove the build folder to refresh the CMake cache or just "make clean"? Here, "cmake .. -GNinja && ninja" works just fine. If you are passing options like USING_GLES2, then the glew target won't be defined and you'll have similar problems.
Also, try to give me the output of "make VERBOSE=1" so I can see the link command line that is failing.
It was originally a fresh checkout when I got the error. I have just tried it again with a new build folder and am still getting the error. here is the linking part with verbose on.
[100%] Linking CXX executable PPSSPPSDL
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/PPSSPPSDL.dir/link.txt --verbose=1
/usr/bin/c++ -std=c++11 -O3 -DNDEBUG -O3 -D_NDEBUG CMakeFiles/PPSSPPSDL.dir/android/jni/TestRunner.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/NativeApp.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/BackgroundAudio.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/DevScreens.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/DisplayLayoutEditor.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/DisplayLayoutScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/EmuScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/GameInfoCache.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/MainScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/MiscScreens.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/PauseScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/GameScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/GameSettingsScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/TiltAnalogSettingsScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/TiltEventProcessor.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/TouchControlLayoutScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/TouchControlVisibilityScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/GamepadEmu.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/OnScreenDisplay.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/ControlMappingScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/RemoteISOScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/ReportScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/SavedataScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/Store.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/CwCheatScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/InstallZipScreen.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/ProfilerDraw.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/ui_atlas.cpp.o CMakeFiles/PPSSPPSDL.dir/UI/ComboKeyMappingScreen.cpp.o -o PPSSPPSDL lib/libCore.a -lpthread lib/libCommon.a lib/libsnappy.a lib/libnative.a /usr/local/lib/libSDL2.so /usr/lib/x86_64-linux-gnu/libzip.so /usr/lib/x86_64-linux-gnu/libz.so lib/libpng17.a lib/librg_etc1.a lib/libvjson.a lib/libudis86.a -lrt lib/libkirk.a lib/libcityhash.a lib/libsfmt19937.a lib/libxbrz.a lib/libxxhash.a lib/libglslang.a /usr/lib/x86_64-linux-gnu/libGLU.so /usr/lib/x86_64-linux-gnu/libGL.so -ldl ../ffmpeg/linux/x86_64/lib/libavformat.a ../ffmpeg/linux/x86_64/lib/libavcodec.a ../ffmpeg/linux/x86_64/lib/libswresample.a ../ffmpeg/linux/x86_64/lib/libswscale.a ../ffmpeg/linux/x86_64/lib/libavutil.a -Wl,-rpath,/usr/local/lib
I could repro the issue. The code path when using the system GLEW library was not tested and the one bundled is used in CI. I'm working on a fix!
It's really not much benefit to use the system GLEW, we could also just always use the bundled one and avoid issues like this... I know it's not clean, but still :) Also I really want to switch to a better GL loader in the future anyway.
Well, it is kind of important to Linux packagers. We could argue that we can optimize binaries better using a static build with LTO though and then remove it... I'm facing some CMake issues with this and I started a thread on their mailing list, but it's going to take a while to have a fix considering maintainers are on holidays!
Well, it could be a temporary solution until the CMake guys respond..
How's this going @Orphis ?
I pushed a fix to ignore the system one, so it should be fine. I could push another fix to make it available again if people show interest.
Good enough for me, closing.
I guess it's missing a link library.
currently git bisecting.