Issues on building the application

[vshashi01]

Hi, when I try to build the application, I get some error related to the CGO's C.free function. Any idea how i can resolve this?

I am new to CGO.

Thank you,

[tinyzimmer]

For whatever it's worth, I still have some memory leak issues I need to hammer out.

That being said, this looks like you either have CGO_ENABLED=0 set in your environment (though I think that would produce a different error), or more likely you are missing kernel headers, specifically stdlib.h. That free function belongs to the system, not CGO, if I understand correctly. I'm not sure what satisfies this on Windows, to be honest, but I know it's gotta be there somewhere. My guess is you need a MinGW compiler.

[vshashi01]

I was using a MinGW compile as expected. And indeed other packages that uses CGO is able to compile as expected. I tried to change tune and tried this on my Ubuntu machine, here I get a completely different error instead. Any idea on this instead?

[tinyzimmer]

This looks like what I fixed over the weekend (maybe do an extra pull?). But I think it was also only there due to a bug in go1.15.4.

I have go1.15.6 installed right now and just compiled some of the examples on my arch box with zero problems.

[tinyzimmer]

Ah I see it, yea I never tagged the fix I did over the weekend, let me do that so it'll play nicer with go modules. There is now v0.1.3 but like I said, you may be able to just update your go version also.

EDIT: Nevermind I did tag it, and I guess it was last week, but yea v0.1.3 has the fix to that bug

[vshashi01]

Updatedto v0.1.3 and I am compiling on Go 1.15.6. Ran into a different problem now.

[tinyzimmer]

Lol these are gstreamer version issues. When I was first slapping it all together I think I ultimately decided that it wouldn't work below 1.18, since that was latest when I was playing. Ultimately, I think this package should be structured in a way to allow going back a little further since a lot of OS repos are behind.

The machine running the code doesn't need to be on that version, but you'll need the latest development libraries to compile.

[vshashi01]

Okay but I am on gstreamer version 1.18 on my Windows platform.
I have attached my console output for both gstreamer version and go env.

The initial C.free errors were a simple problem of not including stdlib.h in Windows environment. I have fixed that, however, now I am running into a problem specific to type signatures.

Note: I am currently trying to build directly from your main branch. Will still poke around and see if I can get this to build.

Edit: Forgot to add the errors previously.

[tinyzimmer]

TIL from what you just showed me that either my code doesn't support windows, or the specific compiler you are using. Is weird coz I could have sworn I had tested it on Windows before, but perhaps I was in WSL and don't remember clearly.

There are things that could be done to mitigate those errors, I'll just have to dig into it later and it will likely require some code moving into the C files with OS checks. Feel free to open a PR if you figure it out before I do.

[vshashi01]

After looking at it closer, I think the fix should be as easy as replacing the C.gulong calls to C.gsize calls for the type related errors, since they are the Glib equivalent of size_t anyways.

For example in the function below.

// NewBufferFromBytes returns a new buffer from the given byte slice.
func NewBufferFromBytes(b []byte) *Buffer {
	str := string(b)
	p := unsafe.Pointer(C.CString(str))
	// memory is freed by gstreamer after building the new buffer
	//OLD buf := C.gst_buffer_new_wrapped((C.gpointer)(p), C.gulong(len(str)))
	buf := C.gst_buffer_new_wrapped((C.gpointer)(p), C.gsize(len(str))) //NEW
	return wrapBuffer(buf)
}

As for the error related to C.free, I was only able to resolve it once I included stdlib.h in the gst.go.h file.

After these changes I was able to compile it successfully on Windows.

Let me know if this fixes are okay for you, then I will send a PR with my changes.

[tinyzimmer]

After looking at it closer, I think the fix should be as easy as replacing the C.gulong calls to C.gsize calls for the type related errors, since they are the Glib equivalent of size_t anyways.

This makes sense. Nice find!

As for the error related to C.free, I was only able to resolve it once I included stdlib.h in the gst.go.h file.

This confuses the crap out of me. Mainly, because I know it was working fine on *nix because stdlib.h was already included in the gstreamer headers. The fact that Windows needs it explicitly just seems odd. That being said, the code does use functions from it so not a terrible idea to re-declare it for clarity. It only makes me wonder how Windows is coping with all the glib stuff that I'm also not including explicitly 😕.

Anyways. feel free to send the PR over and I can test it out on my setups also.

[darkvertex]

Hi! I'm on Windows 10 with go-gst v0.1.9 and Go 1.15.6 and had the C.free errors as well:

github.com\tinyzimmer\go-gst\gst\cgo_exports.go:86:9: could not determine kind of name for C.free

I see this issue was closed but I'm not sure it's truly fixed in the current version.

If I go in cgo_exports.go and change:

/*
#include <gst/gst.h>
*/
import "C"

to:

/*
#include <stdlib.h>
#include <gst/gst.h>
*/
import "C"

the C.free error goes away and I get new errors:

vendor\github.com\tinyzimmer\go-gst\gst\cgo_exports.go:277:67: cannot use _Ctype_ulong(unsafe.Sizeof(uintptr(0))) (type 
_Ctype_ulong) as type _Ctype_ulonglong in assignment

Then I did a search&replace of C.gulong( for C.gsize( everywhere, which turned out to be in cgo_exports.go, gst_pad.go and in glib.go of pkg go-glib and now I get new errors:

vendor\github.com\tinyzimmer\go-glib\glib\glib.go:685:52: cannot use _Ctype_ulonglong(handle) (type _Ctype_ulonglong) as type _Ctype_ulong in assignment
vendor\github.com\tinyzimmer\go-glib\glib\glib.go:690:52: cannot use _Ctype_ulonglong(handle) (type _Ctype_ulonglong) as type _Ctype_ulong in assignment
vendor\github.com\tinyzimmer\go-glib\glib\glib.go:695:52: cannot use _Ctype_ulonglong(handle) (type _Ctype_ulonglong) as type _Ctype_ulong in assignment

[vshashi01]

I just pulled the latest master (0.1.9), indeed there is a type errror at line 277 in cgo.exports.go! But I think you should just replaced the C.gulong( call that is showing the error and not in all the files. Then it should compile fine. If you managed to fix this issue, maybe can send a PR with the changes?

About the problem related to the includes, I made a stupid mistake in my PR, indeed it didnt actually fix the issue. It seems that gst.h never includes stdlib.h at all and on my machine, I have manually edited the gst.h file to include stdlib for some reason (I cant remember why) and that made it look like the problem was solved in go-gst and I can compile fine. I think we need a better way to solve the include issue @tinyzimmer. Maybe we should include stdlib.h in wherever necessary as well?

[tinyzimmer]

I'll need to improve the actions or something to try to catch these errors on multiple systems. I do most of my development on Linux where these issues don't arise. When I put a gulong it's because the docs say gulong and I just don't even think about it.

Including stdlib.h in gst.go.h is effectively including it everywhere. The cgo_exports file itself behaves a little differently so maybe it needs its own.

I'll do a commit switching all of those ulong (in the glib package and here) as well as seeing if an explicit stdlib include in cgo_exports works. Will chime in here with a tag for yall to test.

[tinyzimmer]

Let me know if v0.1.10 works any better.

[vshashi01]

Probably need similar change in the glib library as well?

Strangely I didnt have this issue just now.

[tinyzimmer]

I did it there too. go.mod is updated to a new tag. It was things like this which led me to fork it in the first place to make this easier.

…

On Mon, Jan 11, 2021, 07:22 Shashi ***@***.***> wrote: [image: image] <https://user-images.githubusercontent.com/28664567/104148990-8c4c8600-540f-11eb-956c-f9a7eca48949.png> Probably need similar change in the glib library as well? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJFREMYXS4FFE56QKJU2VQDSZKDJRANCNFSM4VC2VQTA> .

[vshashi01]

Created #8 as a reference for all the changes I needed to make it compile on Windows. It seems your changes to glib is not needed actually since the original g_signal_handler_block() was always expected to take in a gulong and not gsize.

[tinyzimmer]

I've replaced the v0.1.10 tag with the fixes - let me know if it works out

[vshashi01]

Works for me. @darkvertex Please check as well just incase.

[darkvertex]

Works for me. @darkvertex Please check as well just incase.

Got good news and bad news... First the good news: v0.2.0 works! 🥳 (I tried the sample that produces random colored frames and I see them, yay!)

Now the bad news, the older version v0.1.10 gave me build errors:

C:\Users\alan\go\pkg\mod\github.com\tinyzimmer\[email protected]\glib\glib.go:685:52: cannot use _Ctype_ulonglong(handle) (type _Ctype_ulonglong) as type _Ctype_ulong in assignment
C:\Users\alan\go\pkg\mod\github.com\tinyzimmer\[email protected]\glib\glib.go:690:52: cannot use _Ctype_ulonglong(handle) (type _Ctype_ulonglong) as type _Ctype_ulong in assignment
C:\Users\alan\go\pkg\mod\github.com\tinyzimmer\[email protected]\glib\glib.go:695:52: cannot use _Ctype_ulonglong(handle) (type _Ctype_ulonglong) as type _Ctype_ulong in assignment

So I don't know what else you changed between v0.1.10 to v0.2.0, but I guess you fixed it! 🤷

[darkvertex]

In case someone new comes looking for how to make it work in Windows, this worked for me:

1. Install https://gstreamer.freedesktop.org/data/pkg/windows/1.18.0/mingw/gstreamer-1.0-mingw-x86_64-1.18.0.msi for the gstreamer precompiled binaries and dlls. (You will only need this one to run the resulting .exe with.)
2. Install https://gstreamer.freedesktop.org/data/pkg/windows/1.18.0/mingw/gstreamer-1.0-devel-mingw-x86_64-1.18.0.msi for the devel headers. (You will need this one to compile your .exe, but not afterwards, in theory.)
3. Go into C:\gstreamer\1.0\mingw_x86_64\lib\pkgconfig with VSCode and do a mass search & replace within all *.pc files of c:/projects/repos/cerbero.git/build/dist/mingw_x86_64 to your actual install path, which should be C:/gstreamer/1.0/mingw_x86_64 -- (This should only edit the prefix= lines, in theory.)
4. Grab one of the many Go examples of this library, drop your main.go and then make a new compile.bat file -- making sure GSTREAMER_ROOT defined below does in fact exist at that path:

@ECHO OFF
set GSTREAMER_ROOT=C:/gstreamer/1.0/mingw_x86_64
set CGO_ENABLED=1
set PKG_CONFIG_PATH=%GSTREAMER_ROOT%/lib/pkgconfig
go build -v -o gstdemo.exe

5. Run compile.bat to build your gstdemo.exe. -- (Go brew a tea or refill your coffee; this may take a couple minutes.)
6. The resulting gstdemo.exe is compiled with SHARED libs, so it is NOT STATIC and it will not run right away if you doubleclick it. -- To set your env "just right", make a new file launch.bat:

@ECHO OFF
set GSTREAMER_ROOT=C:/gstreamer/1.0/mingw_x86_64
set GST_PLUGIN_PATH_1_0=%GSTREAMER_ROOT%/lib/gstreamer-1.0
set GST_PLUGIN_SYSTEM_PATH_1_0=%GSTREAMER_ROOT%/lib/gstreamer-1.0
set PATH=%PATH%;%GSTREAMER_ROOT%/bin
set GST_REGISTRY_1_0=%HOME%/.cache/gstreamer-1.0/gstreamer-cerbero-registry
set GST_PLUGIN_SCANNER_1_0=%GSTREAMER_ROOT%/libexec/gstreamer-1.0/gst-plugin-scanner
set GIO_EXTRA_MODULES=%GSTREAMER_ROOT%/lib/gio/modules

.\gstdemo.exe

7. Doubleclick launch.bat and in theory it should be running now! Ctrl+C twice or close the window to quit.

NOTE: If you're missing a compatible compiler, installing MinGW-w64 from Chocolatey worked for me and Go's cgo compiler seemed to detect it. -- You will also need pkg-config and there's one in Chocolatey that works well and has no dependencies.

[tinyzimmer]

Thanks for the rundown. I'll find some way to adapt this into the docs 😄

[darkvertex]

Cool. The more people that can enjoy this nice module the better! :)

Just edited my previous comment to mention that pkg-config is also needed and linking to the one I use from Chocolatey that worked for me.

[vshashi01]

@darkvertex Any luck getting the Delve debugger working for the example in your setup on Windows machine?

[tinyzimmer]

FWIW - debugging cgo calls is very hard to do. I haven't tried in delve personally, but other tools have a really hard time discerning what's happening between go land and C land.

On another note that may end up being related here - I'm in the middle of moving a bunch of the glib specific stuff into the glib bindings and pulling them out of here. Because of the way go modules works and my own laziness, it's producing a few tags in the process. Once I'm done making these changes and a few others I have planned I'll probably do a v0.3.0.

From the sound of it, you all aren't using much of the areas I'm messing around with. But if you do notice a recent tag breaks Windows compatibility again give me a shout.

[vshashi01]

@tinyzimmer Indeed I am aware of the problem of debugging C calls. But all I am trying to do is get the debugger work for my own application logic. For some reason the delve debugger is unable to link the gst.go.h object file sucessfully so I get an "undefined reference" error for every function and variable in gst.go.h. Hence I was asking if he managed to get it working

[soerenbrockmann]

I am getting this error when running the example program on the Readme:

go run main.go
# github.com/tinyzimmer/go-gst/gst
../../go/pkg/mod/github.com/tinyzimmer/[email protected]/gst/gst_debug.go:14:63: warning: format string is not a string literal (potentially insecure) [-Wformat-security]
../../go/pkg/mod/github.com/tinyzimmer/[email protected]/gst/gst_debug.go:14:63: note: treat the string as an argument to avoid this
# github.com/tinyzimmer/go-gst/gst
../../go/pkg/mod/github.com/tinyzimmer/[email protected]/gst/gst_pad.go:38:100: warning: all paths through this function will call itself [-Winfinite-recursion]
# github.com/tinyzimmer/go-gst/gst
../../go/pkg/mod/github.com/tinyzimmer/[email protected]/gst/gst_clock.go:209:9: constant -1 overflows _Ctype_ulonglong
../../go/pkg/mod/github.com/tinyzimmer/[email protected]/gst/gst_clock.go:219:9: constant -1 overflows _Ctype_ulonglong

Any idea how to fix it?

[tinyzimmer]

I'm guessing you are on Windows because I am not getting these errors on Linux. I think those first three messages are benign, but the last two confuse me a bit. Specifically because it is yelling at a constant that is declared in Gstreamer and not in the bindings themselves.

I'll see if I can work around this somehow and ping here when there is a tag.

[tinyzimmer]

Ok, so I finally set up my own Windows environment for testing these things (in case that was the platform you are on). What is weird is I wasn't able to reproduce this. I was able to compile the examples without issue, and I also didn't get the warnings.

That being said, I've tried something different for the two fatals you got in gst_clock.go and it's up on v0.2.24. I've also finally updated the README with Windows information, so once we figure this new issue out I'll probably close this guy.

[soerenbrockmann]

Sorry, I forgot to add more details.

• I am working on Mac Big Sur V 11.2.1.
• I installed Gstreamer v1.18.3 runtime with brew and the dev version as downloaded package.

When I installed the runtime version as dowloaded package the path to gstreamer-1.0 was not found. Not sure whether this is the cause.

Do I have to the the PKG_CONFIG_PATH on Mac as well?

[tinyzimmer]

I'll check on my mac. I'm not sure to be honest. Homebrew should put the files in the right place. If the files are in a non-standard location, you would need to set it. But you'd have gotten different errors.

[tinyzimmer]

So on my mac just now, I did get this warning:

gst/gst_pad.go:38:100: warning: all paths through this function will call itself [-Winfinite-recursion]

Which I don't get on Linux or Windows, so I'll try to look into the source of that later. But beyond that, it did compile on the latest tag. Are you still having the same problem on v0.2.24?

EDIT: To add, I was able to reproduce the issue you did have on v0.2.23.

[soerenbrockmann]

It works with v0.2.24. Thanks a lot :-)

[flyqie]

PS C:\> choco install msys2
PS C:\> mingw64
$ pacman -S mingw-w64-x86_64-gtk3 mingw-w64-x86_64-toolchain base-devel glib2-devel
$ echo 'export PATH=/c/Program\ Files/Go/bin:$PATH' >> ~/.bashrc
$ echo 'export PATH=/c/Program\ Files/Git/bin:$PATH' >> ~/.bashrc
$ source ~/.bashrc
$ sed -i -e 's/-Wl,-luuid/-luuid/g' /mingw64/lib/pkgconfig/gdk-3.0.pc # This fixes a bug in pkgconfig
$ pacman -S mingw-w64-x86_64-gstreamer mingw-w64-x86_64-gst-libav mingw-w64-x86_64-gst-plugins-good mingw-w64-x86_64-gst-plugins-bad mingw-w64-x86_64-gst-plugins-ugly

Finally, add C:\tools\msys64\mingw64\bin to your Windows environment variables (not in mingw64!).

You should now be able to compile and run (without setting any additional environment variables).

The compiled binaries are still dynamically linked, but you can manually copy the relevant dll files from C:\tools\msys64\mingw64 for distribution (for me I copied lib/gio, lib/gstreamer-1.0 , bin/*.dll, the full version is not small but reusable, enough for me).

This method worked for me (Windows10 x64), but I can't make sure it works for everyone.

The following links helped me, thanks a lot:

https://github.com/pion/example-webrtc-applications/tree/master/gstreamer-send

https://github.com/gotk3/gotk3/wiki/Installing-on-Windows

[danijelk00]

I'm trying to run the launch example using Golang and go-gst library on Windows, but I keep getting an error.

Steps I did:

1. I created a new main.go file using the code snippet from (Quickstart:[https://github.com/go-gst/go-gst])

2. From the above comment I did the following:
   "Go into C:\gstreamer\1.0\mingw_x86_64\lib\pkgconfig with VSCode and do a mass search & replace within all *.pc files of c:/projects/repos/cerbero.git/build/dist/mingw_x86_64 to your actual install path, which should be C:/gstreamer/1.0/mingw_x86_64 -- (This should only edit the prefix= lines, in theory.)"

3. Then I set all environment variables manually:
   PS C:\Users?\Desktop\gst windows> $env:PKG_CONFIG_PATH='C:\gstreamer\1.0\mingw_x86_64\lib\pkgconfig'
   PS C:\Users?\Desktop\gst windows> echo $env:PKG_CONFIG_PATH
   C:\gstreamer\1.0\mingw_x86_64\lib\pkgconfig
   PS C:\Users?\Desktop\gst windows> $env:CGO_ENABLED=1
   PS C:\Users?\Desktop\gst windows> echo $env:CGO_ENABLED
   1
   PS C:\Users?\Desktop\gst windows> $env:GSTREAMER_ROOT='C:/gstreamer/1.0/mingw_x86_64'
   PS C:\Users?\Desktop\gst windows> echo $env:GSTREAMER_ROOT
   C:/gstreamer/1.0/mingw_x86_64

4. I called go mod init main & go mod tidy

5. And tried to run the code using go run main.go

6. I got the following error:

PS C:\Users?\Desktop\gst windows> go build -v
main

main

C:\Program Files\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
C:/ProgramData/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld. exe: C:/ProgramData/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/ ../lib/crt2.o:crtexe.c:(.rdata$.refptr.__mingw_app_type[.refptr.__mingw_app_type]+0x0): undefined reference to __mingw_app_type' C:/ProgramData/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld. exe: C:/ProgramData/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/ ../lib/crt2.o:crtexe.c:(.rdata$.refptr.__mingw_initltssuo_force[.refptr.__mingw_initltssuo_force]+0x0): undefined reference to __mingw_initltssuo_force'
C:/ProgramData/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld. exe: C:/ProgramData/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/ ../lib/crt2.o:crtexe.c:(.rdata$.refptr.__mingw_initltsdyn_force[.refptr.__mingw_initltsdyn_force]+0x0): undefined reference to __mingw_initltsdyn_force' C:/ProgramData/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld. exe: C:/ProgramData/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/ ../lib/crt2.o:crtexe.c:(.rdata$.refptr.__mingw_initltsdrot_force[.refptr.__mingw_initltsdrot_force]+0x0): undefined reference to __mingw_initltsdrot_force'
collect2.exe: error: ld returned 1 exit status