FAQ
Hi,

Here is a statically-linked package to open a OpenGL canvas and process
events.

http://code.google.com/p/glcv-go

You can get it with:

go get code.google.com/p/glcv-go/canvas

Run the examples with:

cd src/pkg/code.google.com/p/glcv-go/examples
go run test.go

I haven't tested the Windows/X11 code because I only have a Mac handy right
now. Feedback on results/patches would be great.

It isn't tied to a specific OpenGL package (only the tests are).

The tricky part was statically-linking on OSX. The linker has problems with
Objective C and my (uber-dirty) solution was to use clang -rewrite-objc and
modify manually the resulting mess.
I still have to change the critical paths so they don't call
sel_registerName() and friends, but...

Comments/suggestions welcome.

Regards,
Jorge

--

Search Discussions

  • Erwin at Nov 14, 2012 at 7:49 pm


    Here is a statically-linked package to open a OpenGL canvas and process
    events.

    Statically linked meaning that the window system interface is completely
    contained in the final Go executable?
    If so, very interesting!

    --
  • Jorge Acereda at Nov 14, 2012 at 8:25 pm

    On Wednesday, November 14, 2012 8:49:14 PM UTC+1, notnot wrote:
    Here is a statically-linked package to open a OpenGL canvas and process
    events.

    Statically linked meaning that the window system interface is completely
    contained in the final Go executable?
    If so, very interesting!
    Of course not, I could say 'linking dinamically only to "standard"
    libraries', but then you could say libX11 isn't present on all unix
    installations.
    Would 'go-gettable' be a better term?

    --
  • Jorge Acereda at Nov 14, 2012 at 9:00 pm
    Forgot to say that the library I'm wrapping also has code for Android, IOS
    and NPAPI (browser plugins). So, if anyone has interest in getting OpenGL
    Go code running on those this might be a good start. If anyone wants to try
    any of those routes, I'd appreciate the patches/comments.

    On Wednesday, November 14, 2012 6:02:52 PM UTC+1, Jorge Acereda wrote:

    Hi,

    Here is a statically-linked package to open a OpenGL canvas and process
    events.

    http://code.google.com/p/glcv-go

    You can get it with:

    go get code.google.com/p/glcv-go/canvas

    Run the examples with:

    cd src/pkg/code.google.com/p/glcv-go/examples
    go run test.go

    I haven't tested the Windows/X11 code because I only have a Mac handy
    right now. Feedback on results/patches would be great.

    It isn't tied to a specific OpenGL package (only the tests are).

    The tricky part was statically-linking on OSX. The linker has problems
    with Objective C and my (uber-dirty) solution was to use clang
    -rewrite-objc and modify manually the resulting mess.
    I still have to change the critical paths so they don't call
    sel_registerName() and friends, but...

    Comments/suggestions welcome.

    Regards,
    Jorge
    --
  • Ken Allen at Nov 24, 2012 at 9:27 pm
    I tried this on 32 bit windows and it compiles fine but trying to go run
    either of the examples results in a bunch of vsnprintf and snprintf not
    defined errors. The changes to go build to use the system linker to build
    the final executable can't come fast enough - this kind of thing will be so
    much easier.
    On Wednesday, November 14, 2012 12:02:52 PM UTC-5, Jorge Acereda wrote:

    Hi,

    Here is a statically-linked package to open a OpenGL canvas and process
    events.

    http://code.google.com/p/glcv-go

    You can get it with:

    go get code.google.com/p/glcv-go/canvas

    Run the examples with:

    cd src/pkg/code.google.com/p/glcv-go/examples
    go run test.go

    I haven't tested the Windows/X11 code because I only have a Mac handy
    right now. Feedback on results/patches would be great.

    It isn't tied to a specific OpenGL package (only the tests are).

    The tricky part was statically-linking on OSX. The linker has problems
    with Objective C and my (uber-dirty) solution was to use clang
    -rewrite-objc and modify manually the resulting mess.
    I still have to change the critical paths so they don't call
    sel_registerName() and friends, but...

    Comments/suggestions welcome.

    Regards,
    Jorge
    --
  • Jorge Acereda at Nov 24, 2012 at 11:30 pm

    On Nov 24, 2012, at 10:27 PM, Ken Allen wrote:

    I tried this on 32 bit windows and it compiles fine but trying to go run either of the examples results in a bunch of vsnprintf and snprintf not defined errors. The changes to go build to use the system linker to build the final executable can't come fast enough - this kind of thing will be so much easier.
    Count with my vote for raising the priority of the 'use the system linker' issue...

    Can you try again?

    hg pull
    hg up
    del \go\pkg\windows_386\code.google.com\p\glcv-go\cv.a
    go run cvtest.go

    I don't know why deleting the cv.a library is necessary...
    On Wednesday, November 14, 2012 12:02:52 PM UTC-5, Jorge Acereda wrote:
    Hi,

    Here is a statically-linked package to open a OpenGL canvas and process events.

    http://code.google.com/p/glcv-go

    You can get it with:

    go get code.google.com/p/glcv-go/canvas

    Run the examples with:

    cd src/pkg/code.google.com/p/glcv-go/examples
    go run test.go

    I haven't tested the Windows/X11 code because I only have a Mac handy right now. Feedback on results/patches would be great.

    It isn't tied to a specific OpenGL package (only the tests are).

    The tricky part was statically-linking on OSX. The linker has problems with Objective C and my (uber-dirty) solution was to use clang -rewrite-objc and modify manually the resulting mess.
    I still have to change the critical paths so they don't call sel_registerName() and friends, but...

    Comments/suggestions welcome.

    Regards,
    Jorge


    --
    --
  • Ken Allen at Nov 25, 2012 at 2:26 am
    Well it runs now, that's an improvement! Everything works properly until
    quiting - the term event is received by the handler and then this panic
    occurs:

    panic: runtime error: call of nil func value
    [signal 0xc0000005 code=0x0 addr=0x0 pc=0x0]

    goroutine 1 [syscall]:
    code.google.com/p/glcv-go/cv._Cfunc_run(0x415f65, 0x416698)

    C:/Users/savage/AppData/Local/Temp/go-build189869535/code.google.com/p/glcv-go/cv/_obj/_cgo_defun.c:170
    +0x31
    code.google.com/p/glcv-go/cv.Run(0x416698, 0x4018c4)
    cv.go:22 +0x28
    code.google.com/p/glcv-go/canvas.(*Canvas).Go()

    B:/Command/work/go/src/code.google.com/p/glcv-go/canvas/canvas.go:53 +0x29
    main.main()

    B:/Command/work/go/src/code.google.com/p/glcv-go/examples/test.go:86 +0x80

    goroutine 2 [syscall]:
    created by runtime.main

    C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist579160455/go/src/pkg/runtime/proc.c:221
    exit status 2

    --
  • Jorge Acereda at Nov 27, 2012 at 11:44 pm

    On Nov 25, 2012, at 3:26 AM, Ken Allen wrote:

    Well it runs now, that's an improvement! Everything works properly until quiting - the term event is received by the handler and then this panic occurs:
    Hmmm... I can't reproduce it on XP + Virtual Box...
    What are you running? Anyone else gets the crash?
    I have improved the API a bit, but I guess the crash should still be there...
    panic: runtime error: call of nil func value
    [signal 0xc0000005 code=0x0 addr=0x0 pc=0x0]

    goroutine 1 [syscall]:
    code.google.com/p/glcv-go/cv._Cfunc_run(0x415f65, 0x416698)
    C:/Users/savage/AppData/Local/Temp/go-build189869535/code.google.com/p/glcv-go/cv/_obj/_cgo_defun.c:170 +0x31
    code.google.com/p/glcv-go/cv.Run(0x416698, 0x4018c4)
    cv.go:22 +0x28
    code.google.com/p/glcv-go/canvas.(*Canvas).Go()
    B:/Command/work/go/src/code.google.com/p/glcv-go/canvas/canvas.go:53 +0x29
    main.main()
    B:/Command/work/go/src/code.google.com/p/glcv-go/examples/test.go:86 +0x80

    goroutine 2 [syscall]:
    created by runtime.main
    C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist579160455/go/src/pkg/runtime/proc.c:221
    exit status 2

    --
    --
  • Ken Allen at Nov 28, 2012 at 1:24 am
    I'm running Vista 32bit (yeah I know, gross). I updated to your latest code
    and the crash is indeed still present. Something you changed also makes gcc
    compile in some kind of stack checking that causes __chkstk_ms(0): not
    defined errors. I fixed that by adding the following line to cv.go:

    #cgo windows CFLAGS: -fno-stack-check -fno-stack-protector
    -mno-stack-arg-probe

    My gcc is 4.6.2 if that matters. Since you can't duplicate I'll poke at it
    and see if I can find the cause.
    On Tuesday, November 27, 2012 6:44:50 PM UTC-5, Jorge Acereda wrote:

    On Nov 25, 2012, at 3:26 AM, Ken Allen wrote:

    Well it runs now, that's an improvement! Everything works properly until
    quiting - the term event is received by the handler and then this panic
    occurs:
    Hmmm... I can't reproduce it on XP + Virtual Box...
    What are you running? Anyone else gets the crash?
    I have improved the API a bit, but I guess the crash should still be
    there...
    panic: runtime error: call of nil func value
    [signal 0xc0000005 code=0x0 addr=0x0 pc=0x0]

    goroutine 1 [syscall]:
    code.google.com/p/glcv-go/cv._Cfunc_run(0x415f65, 0x416698)
    C:/Users/savage/AppData/Local/Temp/go-build189869535/
    code.google.com/p/glcv-go/cv/_obj/_cgo_defun.c:170 +0x31
    code.google.com/p/glcv-go/cv.Run(0x416698, 0x4018c4)
    cv.go:22 +0x28
    code.google.com/p/glcv-go/canvas.(*Canvas).Go()
    B:/Command/work/go/src/
    code.google.com/p/glcv-go/canvas/canvas.go:53 +0x29
    main.main()
    B:/Command/work/go/src/
    code.google.com/p/glcv-go/examples/test.go:86 +0x80
    goroutine 2 [syscall]:
    created by runtime.main
    C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist579160455/go/src/pkg/runtime/proc.c:221
    exit status 2

    --
    --
  • Ken Allen at Nov 28, 2012 at 3:17 am
    Well I've tried everything I could think of, with no luck. I've tried with
    both go 1.0.3 and tip, with no difference. I inserted some printfs and
    discovered that cvrun doesn't seem to be returning to cvRun. I determined
    this by printfing the return value from cvInject(CVE_TERM), returning it,
    then printfing it again in cvRun. It never prints the second time. I can
    only guess that something is smashing the stack and writing the return
    address to 0. I think that might be what's causing go to think that a nil
    func value was called because the signal handling code seems to treat all
    access violations where the PC is 0 that way.

    I tried dr. memory but it didn't pick up anything obvious. gdb was less
    than useful as well.

    If I get the chance I'll try this at work tomorrow, I have Windows 7 x64
    there.

    --
  • Jorge Acereda at Nov 29, 2012 at 9:37 pm

    On Nov 28, 2012, at 4:17 AM, Ken Allen wrote:

    Well I've tried everything I could think of, with no luck. I've tried with both go 1.0.3 and tip, with no difference. I inserted some printfs and discovered that cvrun doesn't seem to be returning to cvRun. I determined this by printfing the return value from cvInject(CVE_TERM), returning it, then printfing it again in cvRun. It never prints the second time. I can only guess that something is smashing the stack and writing the return address to 0. I think that might be what's causing go to think that a nil func value was called because the signal handling code seems to treat all access violations where the PC is 0 that way.

    I tried dr. memory but it didn't pick up anything obvious. gdb was less than useful as well.
    Hi Ken,

    Thanks for your efforts.

    I tried valgrind on OSX and didn't catch anything either, the bug is probably in the windows-specific code.

    Perhaps gdb can help here, but it's a bit tricky.
    Assuming it can be reproduced with the library test, I would try to catch it as follows:

    cd cv\glcv
    mk-win.bat
    gdb b\test
    b cvrun # break at cvrun function
    r # run
    p $ebp+4 # print address of return address
    watch *(void**)$1 # and set a hardware breakpoint there
    c # continue

    As soon as it reaches the watchpoint:

    bt # print backtrace


    If I get the chance I'll try this at work tomorrow, I have Windows 7 x64 there.

    --
    --
  • Ken Allen at Jan 13, 2013 at 7:58 pm
    I had some time to kill today so I dug into this some more. For some reason
    calling wglSwapIntervalEXT blows away the stack, at least enough to zero
    the return address for cvrun, causing this problem. I checked the return
    value of wglGetProcAddress and it's not null so the function is there to be
    called. I checked the return of swapinterval and it's 1 regardless if I
    pass 1 or 0 to it.

    I don't think vsync will be needed for the majority of things that I'm
    interested in making so I'm satisfied using a custom version with the vsync
    setup removed. However, if I come up with a reason for it failing I'll be
    sure to let you know.
    On Thursday, November 29, 2012 4:36:59 PM UTC-5, Jorge Acereda wrote:

    On Nov 28, 2012, at 4:17 AM, Ken Allen wrote:

    Well I've tried everything I could think of, with no luck. I've tried
    with both go 1.0.3 and tip, with no difference. I inserted some printfs and
    discovered that cvrun doesn't seem to be returning to cvRun. I determined
    this by printfing the return value from cvInject(CVE_TERM), returning it,
    then printfing it again in cvRun. It never prints the second time. I can
    only guess that something is smashing the stack and writing the return
    address to 0. I think that might be what's causing go to think that a nil
    func value was called because the signal handling code seems to treat all
    access violations where the PC is 0 that way.
    I tried dr. memory but it didn't pick up anything obvious. gdb was less
    than useful as well.

    Hi Ken,

    Thanks for your efforts.

    I tried valgrind on OSX and didn't catch anything either, the bug is
    probably in the windows-specific code.

    Perhaps gdb can help here, but it's a bit tricky.
    Assuming it can be reproduced with the library test, I would try to catch
    it as follows:

    cd cv\glcv
    mk-win.bat
    gdb b\test
    b cvrun # break at cvrun function
    r # run
    p $ebp+4 # print address of return address
    watch *(void**)$1 # and set a hardware breakpoint there
    c # continue

    As soon as it reaches the watchpoint:

    bt # print backtrace


    If I get the chance I'll try this at work tomorrow, I have Windows 7 x64 there.
    --
    --
  • Jorge Acereda at Jan 14, 2013 at 9:08 pm
    Hi Ken,
    On Jan 13, 2013, at 8:58 PM, Ken Allen wrote:

    I had some time to kill today so I dug into this some more. For some reason calling wglSwapIntervalEXT blows away the stack, at least enough to zero the return address for cvrun, causing this problem. I checked the return value of wglGetProcAddress and it's not null so the function is there to be called. I checked the return of swapinterval and it's 1 regardless if I pass 1 or 0 to it.
    Great, I think I know what's going on. The usual __stdcall problem. Can you pull/up again and recheck?

    Thanks!

    --
  • Ken Allen at Jan 15, 2013 at 1:49 am
    Fantastic, that fixed it! Thanks for your help!
    On Monday, January 14, 2013 4:08:30 PM UTC-5, Jorge Acereda wrote:

    Hi Ken,
    On Jan 13, 2013, at 8:58 PM, Ken Allen wrote:

    I had some time to kill today so I dug into this some more. For some
    reason calling wglSwapIntervalEXT blows away the stack, at least enough to
    zero the return address for cvrun, causing this problem. I checked the
    return value of wglGetProcAddress and it's not null so the function is
    there to be called. I checked the return of swapinterval and it's 1
    regardless if I pass 1 or 0 to it.

    Great, I think I know what's going on. The usual __stdcall problem. Can
    you pull/up again and recheck?

    Thanks!
    --
  • André Moraes at Nov 30, 2012 at 11:14 am

    On Wed, Nov 14, 2012 at 3:02 PM, Jorge Acereda wrote:
    Hi,

    Here is a statically-linked package to open a OpenGL canvas and process
    events.
    Does CGo work's with static-linked C code now? Last time I checked it didn't.

    At least, not at all cases.


    --
    André Moraes
    http://amoraes.info

    --
  • Ian Lance Taylor at Nov 30, 2012 at 2:34 pm

    On Fri, Nov 30, 2012 at 3:14 AM, André Moraes wrote:
    On Wed, Nov 14, 2012 at 3:02 PM, Jorge Acereda wrote:
    Hi,

    Here is a statically-linked package to open a OpenGL canvas and process
    events.
    Does CGo work's with static-linked C code now? Last time I checked it didn't.

    At least, not at all cases.
    cgo should normally work with statically-linked C code, unless the
    code was compiled with -fPIC.

    Ian

    --
  • Jorge Acereda at Nov 30, 2012 at 5:17 pm

    On Nov 30, 2012, at 12:14 PM, André Moraes wrote:
    On Wed, Nov 14, 2012 at 3:02 PM, Jorge Acereda wrote:
    Hi,

    Here is a statically-linked package to open a OpenGL canvas and process
    events.
    Does CGo work's with static-linked C code now? Last time I checked it didn't.
    Do you mean on Mac? It seems the linker can't handle certain types of relocations, but if you avoid those it's ok.

    At least, not at all cases.


    --
    André Moraes
    http://amoraes.info
    --
  • Minux at Nov 30, 2012 at 5:20 pm

    On Sat, Dec 1, 2012 at 1:17 AM, Jorge Acereda wrote:
    On Nov 30, 2012, at 12:14 PM, André Moraes wrote:
    Does CGo work's with static-linked C code now? Last time I checked it
    didn't.
    Do you mean on Mac? It seems the linker can't handle certain types of
    relocations, but if you avoid those it's ok.
    FYI, the ultimate solution is
    https://code.google.com/p/go/issues/detail?id=4069

    --
  • Jorge Acereda at Nov 30, 2012 at 5:23 pm

    On Nov 30, 2012, at 6:19 PM, minux wrote:


    On Sat, Dec 1, 2012 at 1:17 AM, Jorge Acereda wrote:
    On Nov 30, 2012, at 12:14 PM, André Moraes wrote:
    Does CGo work's with static-linked C code now? Last time I checked it didn't.
    Do you mean on Mac? It seems the linker can't handle certain types of relocations, but if you avoid those it's ok.
    FYI, the ultimate solution is https://code.google.com/p/go/issues/detail?id=4069
    Yes, I'm eagerly awaiting for that feature.

    --
  • Yuri Kuznetsov at Dec 2, 2012 at 10:46 pm
    Thanks for your good work.

    Fix mistake at cv.go(14 line): #cgo linux LDFLAGS: -L/usr/X11R6/lib -lGL
    -lX11 -lXcursor
    add -lXcursor

    среда, 14 ноября 2012 г., 21:02:52 UTC+4 пользователь Jorge Acereda написал:
    Hi,

    Here is a statically-linked package to open a OpenGL canvas and process
    events.

    http://code.google.com/p/glcv-go

    You can get it with:

    go get code.google.com/p/glcv-go/canvas

    Run the examples with:

    cd src/pkg/code.google.com/p/glcv-go/examples
    go run test.go

    I haven't tested the Windows/X11 code because I only have a Mac handy
    right now. Feedback on results/patches would be great.

    It isn't tied to a specific OpenGL package (only the tests are).

    The tricky part was statically-linking on OSX. The linker has problems
    with Objective C and my (uber-dirty) solution was to use clang
    -rewrite-objc and modify manually the resulting mess.
    I still have to change the critical paths so they don't call
    sel_registerName() and friends, but...

    Comments/suggestions welcome.

    Regards,
    Jorge
    --
  • Jorge Acereda at Dec 2, 2012 at 11:14 pm

    On Dec 2, 2012, at 8:10 PM, Yuri Kuznetsov wrote:


    Thanks for your good work.

    Fix mistake at cv.go(14 line): #cgo linux LDFLAGS: -L/usr/X11R6/lib -lGL -lX11 -lXcursor
    add -lXcursor
    Fixed, thanks!

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 14, '12 at 5:02p
activeJan 15, '13 at 1:49a
posts21
users7
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase