cocos2d / cocos2d-x-3rd-party-libs-src

Dependencies of cocos2d-x.
142 stars 169 forks source link

Update GLFW to 3.3 #177

Closed ayuusweetfish closed 5 years ago

ayuusweetfish commented 5 years ago

Hi!

This patch upgrades GLFW to 3.3 and closes cocos2d/cocos2d-x#19610. Apparently one of the patches in contrib/ has made its way upstream, and the context for another has changed. They have been removed and updated respectively.

I have tested the change on macOS (10.13.5) and Ubuntu (16.04.1) (forgive me for not upgrading > <). GLFW is not built on other platforms so no worries there ^ ^

minggo commented 5 years ago

Thanks, we will test it. Have you tested on mac?

ayuusweetfish commented 5 years ago

Yes, I have tested on macOS with both v3 and v4, and also on Linux with v3.

minggo commented 5 years ago

It's wired, @Mee-gu said it can not work on mac os. How did you build the lib? Is there any special steps?

ayuusweetfish commented 5 years ago

No, just ./build.sh -p=mac --libs=glfw from build/ in the source tree.

What errors are raised there?

Mee-gu commented 5 years ago

@kawa-yoiko I did exactly what you said, but no response when calling glfwCreateWindow.

Mee-gu commented 5 years ago

@kawa-yoiko I cherry-pick the commit and generate glfw lib by the way ./build.sh -p=mac --libs=glfw from build/ directory. Then copy and replace include files from ./build/mac/glfw3/include/GLFW/*.h to myLocalPath/external/glfw3/include/mac/, replace lib from ./build/mac/glfw3/prebuilt/libglfw3.a to myLocalPath/external/glfw3/prebuilt/mac/libglfw3.a.

When running cpp-test in v4, it will no response when calling glfwCreateWindow in GLViewImpl::initWithRect function.

ayuusweetfish commented 5 years ago

@Mee-gu It's strange 🤔 Have you tried to build a debug version of GLFW and trace inside?

I'm re-running a clean build right now to see if I can reproduce...

Mee-gu commented 5 years ago

@kawa-yoiko yep, I m going to attach the GLFW source to my project and step inside.

ayuusweetfish commented 5 years ago

I have no problem starting up a newly built cpp-tests with a newly compiled GLFW on current v3 branch. My GLFW binary is here, you may try it if you don't mind.

I have no idea about possible causes now > < Hope you can trace it down...

rh101 commented 5 years ago

I just applied this patch to the libs src, and compiled GLFW 3.3, then copied the header files and libglfw3.a into the cocos2d/external/glfw mac specific folders, overwriting the old files. Then I created a new game, and compiled it, and it worked fine. This is using masOS 10.14.4 and Xcode 10.2.1 with cocos2d-x v3.17.2.

Mee-gu commented 5 years ago

@kawa-yoiko @rh101 It still no working either by using your GLFW binary or by compiling GLFW source. And it can't run on my colleague's mac as well. I trace the GLFW source code, found it blocked at [NSApp run] in _glfwPlatformCreateWindow(Line 897 in cocoa_window.m). The stack as follows: image Is there any solution to the problem?

rh101 commented 5 years ago

@Mee-gu Any chance you can upload the compiled project somewhere? I can download and run it on my macOS system to see what happens.

Mee-gu commented 5 years ago

@rh101 Maybe you can try my glfw3 library. Just unzip to the cocos2d-x/external/ and replace glfw3 folder.

rh101 commented 5 years ago

No worries, I'll download it and test it out soon.

Mee-gu commented 5 years ago

@rh101 Thank you. How about the result?

rh101 commented 5 years ago

@Mee-gu It just finished compiling, and it's running with the library and header files in that zip file you uploaded.

image

Mee-gu commented 5 years ago

@rh101 In addition to copying library and header files to cocos2d-x/external/glfw3, what else steps do you have?

rh101 commented 5 years ago

Nothing special. I just created a game as follows:

cocos new gamename -p com.example.gamename -l cpp -d .

then I compiled it

ayuusweetfish commented 5 years ago

Same here. I can build and run cpp-tests with @Mee-gu's binary. I have confirmed that the MD5 sums of produced cpp-tests binaries are different. I'm on macOS 10.13.5.

However, SIGSTOP doesn't mean a crash, it is most likely sent by the debugger; maybe you can try running without one, or try to continue execution anyway. I noticed this is an initial breakpoint in LLDB after a process attach command, so perhaps it is simply a misconfiguration or bug in the debugger (see this possibly related SO post).

Mee-gu commented 5 years ago

@kawa-yoiko @rh101 Thank you for your patient reply. Indeed, create a game by cocos new gamename -p com.example.gamename -l cpp -d . then compile it and run, everything is fine. But if you using the cmake command to build the engine from cocos2d-x and run the cpp-test, the problem will be reproduced. This issue was fixed in PR.

rh101 commented 5 years ago

@Mee-gu I'm really glad you found the reason for this issue! So, that means the GLFW 3.3 updates are going ahead, is that correct?

Mee-gu commented 5 years ago

@rh101 yep, @minggo will review my PR and the glfw library will be upgraded to 3.3 soon.

rh101 commented 5 years ago

Please don't forget about this cocos2d-x PR as well

ayuusweetfish commented 5 years ago

Thanks to all of you for testing and reviewing!

I used GNU Make instead of Xcode, which seems the reason I cannot reproduce 😝