ok, figured it out I think, I had to create a build folder inside the go package and drop in libwhisper.a there

Hi Chris, happy new year. So there is a "Makefile" in the bindings/go directory which will do all of this for you. In that directory, you can run:

• make all to build the library and examples and put the result in a build temporary folder;
• make test to run the unit tests
• make modtidy and make clean to clean things up.

If you are placing your code in the "examples" folder you can build it with:

• make examples/stream which builds the example and puts the result in the build directory.

I hope that helps!

I wanted to use this binding in my project. Also had problem to build it with missing header and cannot find -lwhisper.

I realized the CGO directives in the source files require the header to be in $SRCDIR/../.. and the libwhisper.a in build. So I cloned the repo into my Go package root, compiled the bindings using make whisper in the Go bindings package and then in my root project go.mod added:

replace github.com/ggerganov/whisper.cpp/bindings/go => ./whisper.cpp/bindings/go

Now I was able to compile it program with just go build.

Yeah, I've put in a PR #379 now which removes the hard-coded paths from the .go file in preference for setting the C_INCLUDE_PATH and LIBRARY_PATH variables which invoking the go toolchain, and included some documentation to describe this. I hope that helps!

thanks, that worked great! Is there any way I can help with the streaming part of this?

@chrisbward I added a very basic streaming example here:

https://github.com/djthorpe/go-whisper/

It creates all sorts of crashes (I need to look into thread safety, I assume it's bacause I am launching goroutines where I shouldn't). But may help you a bit more.

As you can notice, in the dependencies folder on the left I stored bot .h and .a files.
Also, given the tree on the left, the path should be correct..

I must mention that, even if I try to run the package tests from the original repository, with the original path, it fails from the same reason..

Thanks @mbaxamb3333 can you run the following and see what happens, in a fresh empty directory:

git clone https://github.com/ggerganov/whisper.cpp.git
cd whisper.cpp/bindings/go
make test

I'd be interested to see if that compiles. If it doesn't work, can you send me the output?

On OSX, following those steps, I get

 $ make all
Clean
Mkdir build
Mkdir models
Build whisper
make[1]: *** No rule to make target `libwhisper.a'. Stop.
make: *** [whisper] Error 2

On OSX, following those steps, I get

 $ make all
Clean
Mkdir build
Mkdir models
Build whisper
make[1]: *** No rule to make target `libwhisper.a'. Stop.
make: *** [whisper] Error 2

I encountered the same error, and it seems that the Go bindings are no longer being maintained.

Great. In that case, I would take a look at the Makefile in the bindings/go directory and see what it is doing differently to make it work. The most important part of the makefile is as follows:

C_INCLUDE_PATH=${INCLUDE_PATH} LIBRARY_PATH=${LIBRARY_PATH} go build <folder>

It's really just important that INCLUDE_PATH contains the file whisper.h and the LIBRARY_PATH contains the file libwhisper.a - these should be on the same line as the "go build" command.

Could this hard coded processors = 0 contributes to the slowness? Any reason we cannot use Whisper_full_parallel at this moment?

image

I made three samples and tested their performance on MLK's full "I have a dream" speech:

• binding libwhisper.so directly and using cgo: 24s
• using the "low-level" bindings: 31s
• using the "high-level" bindings: 55s

So there's a significant cost to using either of the official bindings. I'm not sure where the cost comes in on the low-level bindings, because my cgo looks extremely similar to what it's doing, but it's repeatably much faster.

All programs are available here (I've linked directly to the version I used for these tests)

The default example program gives 27s (!) when run with time ./whisper-cpp -m ~/.local/share/blisper/ggml-small.bin samples/mlk_ihaveadream_long.wav, which should be the roughly equivalent call. Not sure why my cgo program is running faster than it.

@jaybinks on a 53 minute gil strang lecture, with the large model this time, on my Mac OS laptop, plugged in:

whisper-cpp main (4-thread default): 14:15
whisper-cpp main (8 threads): 18:45
binding libwhisper.so directly, 2 CPUs (4-thread default): 12:38
binding libwhisper.so directly, 1 CPU (4-thread default): 14:25
low-level bindings: 62:28
high-level bindings: I cut it off because it didn't see to be going. very long.

system_info from whisper-cpp:

system_info: n_threads = 4 / 10 | AVX = 0 | AVX2 = 0 | AVX512 = 0 | FMA = 0 | NEON = 1 | ARM_FMA = 1 | F16C = 0 | FP16_VA = 1 | WASM_SIMD = 0 | BLAS = 1 | SSE3 = 0 | VSX = 0 | COREML = 0 | 
main: processing 'samples/strang.wav' (51080185 samples, 3192.5 sec), 4 threads, 1 processors, lang = en, task = transcribe, timestamps = 1
whisper_print_timings: load time = 1080.02 ms
whisper_print_timings: fallbacks = 9 p / 5 h
whisper_print_timings: mel time = 3814.76 ms
whisper_print_timings: sample time = 4009.11 ms / 9769 runs ( 0.41 ms per run)
whisper_print_timings: encode time = 446511.75 ms / 126 runs ( 3543.74 ms per run)
whisper_print_timings: decode time = 390127.31 ms / 9760 runs ( 39.97 ms per run)
whisper_print_timings: total time = 845733.56 ms
./whisper-cpp -m ~/.local/share/blisper/ggml-large.bin samples/strang.wav 3471.29s user 36.83s system 414% cpu 14:05.80 total

I noticed that whisper-cpp spread the work across all my processors but kept them only about half-utilized. Possibly because it had only 4 threads on my 8-processor machine?

With 8 threads, it clearly does a better job of keeping the processors busy, but actually took longer (?):

whisper_print_timings: load time = 1570.18 ms
whisper_print_timings: fallbacks = 9 p / 5 h
whisper_print_timings: mel time = 2104.77 ms
whisper_print_timings: sample time = 4008.01 ms / 9769 runs ( 0.41 ms per run)
whisper_print_timings: encode time = 672592.88 ms / 126 runs ( 5338.04 ms per run)
whisper_print_timings: decode time = 445225.22 ms / 9760 runs ( 45.62 ms per run)
whisper_print_timings: total time = 1125743.62 ms
./whisper-cpp --threads 8 -m ~/.local/share/blisper/ggml-large.bin 8434.05s user 43.55s system 753% cpu 18:45.81 total

system_info from sotest (custom bindings):

2 CPUs

AVX = 0 | AVX2 = 0 | AVX512 = 0 | FMA = 0 | NEON = 1 | ARM_FMA = 1 | F16C = 0 | FP16_VA = 1 | WASM_SIMD = 0 | BLAS = 1 | SSE3 = 0 | VSX = 0 | COREML = 0 | 
./sotest -model large ../samples/strang.wav /dev/stdout 5336.24s user 79.33s system 714% cpu 12:37.85 total

1 CPU

./sotest -model large ../samples/strang.wav /dev/stdout 3446.45s user 49.32s system 403% cpu 14:25.43 total

low-level bindings

With the "low-level" bindings 62m 28s:
./lltest -model large ../samples/strang.wav /dev/stdout 7388.36s user 90.48s system 199% cpu 1:02:27.94 total

Hardware and OS info:

$ sw_vers && system_profiler SPHardwareDataType  9:45AM
ProductName:		macOS
ProductVersion:		13.4
BuildVersion:		22F66
Hardware:
 Hardware Overview:
 Model Name: MacBook Pro
 Model Identifier: MacBookPro18,4
 Model Number: Z15H00107LL/A
 Chip: Apple M1 Max
 Total Number of Cores: 10 (8 performance and 2 efficiency)
 Memory: 32 GB

For kicks, I edited the bindings to remove the progress callbacks on the theory that that caused frequent calls across the go -> C boundary, and that dropped the time for the low-level bindings to 14:19 from 62:28 - pretty conclusive evidence that they are a major issue.

Here's the diff:

--- whisper.go	2023年06月26日 08:49:04
+++ whisper.2.go	2023年06月29日 15:43:00
@@ -326,10 +326,10 @@
 // It seems this approach can offer some speedup in some cases.
 // However, the transcription accuracy can be worse at the beginning and end of each chunk.
 func (ctx *Context) Whisper_full_parallel(params Params, samples []float32, processors int, encoderBeginCallback func() bool, newSegmentCallback func(int)) error {
-	registerEncoderBeginCallback(ctx, encoderBeginCallback)
-	registerNewSegmentCallback(ctx, newSegmentCallback)
-	defer registerEncoderBeginCallback(ctx, nil)
-	defer registerNewSegmentCallback(ctx, nil)
+	// registerEncoderBeginCallback(ctx, encoderBeginCallback)
+	// registerNewSegmentCallback(ctx, newSegmentCallback)
+	// defer registerEncoderBeginCallback(ctx, nil)
+	// defer registerNewSegmentCallback(ctx, nil)
 
 	if C.whisper_full_parallel((*C.struct_whisper_context)(ctx), (C.struct_whisper_full_params)(params), (*C.float)(&samples[0]), C.int(len(samples)), C.int(processors)) == 0 {
 		return nil

The C api does not have the concept of model. It only has whisper_context created by WHISPER_API struct whisper_context * whisper_init_from_file(const char * path_model);. However in Go, we create a Model instance by loading the model file, we can then use Model.NewContext() to create one or more contexts - this encourages reusing of the same model instance, which seem consistent with the C api?

I haven't looked into the Go API in details, but regarding the C API, you should be able to achieve what you need by simply setting params.no_context = true when calling whisper_full():

https://github.com/ggerganov/whisper.cpp/blob/86ef64a8555e2fb11d47bf17bf7a208501006a4c/whisper.h#L248

This will tell whisper to ignore any past transcriptions (i.e. clear the state).

2yrs in the future and i'm stuck on the same issue, according to the documentation (cpp) multi threading on one model should be possible if you use different contexts, and is unstable when doing it in one context.
But the above piece of code doesn't work, go crashes when two contexts are busy at the same time..

Hi, the above code might work if there was a "WaitGroup" in there? What is the crash you're getting?

var wg sync.WaitGroup
for i := 0; i < 10; i++{
 wg.Add(1)
 go func(){ // new goroutine
 defer wg.Done()
 ctx := whisper.NewContext()
 ctx.Process(...)
 }()
}
// Wait for all goroutines to finish
wg.Wait()

lol such good sense, I agree

does make it a little more platform restricted...I can see why it'd be good to at least make sure the full compile works.

Sorry I missed this message, github discussions doesn't thread correctly via email it seems, so I got no notification about it.

Using jfk.wav from the whisper.cpp repository, whisper-cpp built with make on commit 3998465, and blisper v0.0.1 from here, on a small file blisper is about 15% slower

$ hyperfine 'blisper -model large jfk.wav /tmp/a.srt'
Benchmark 1: blisper -model large jfk.wav /tmp/a.srt
 Time (mean ± σ): 10.264 s ± 0.244 s [User: 36.698 s, System: 1.280 s]
 Range (min ... max): 9.911 s ... 10.717 s 10 runs
 
$ hyperfine 'whisper-cpp --model ~/.local/share/blisper/ggml-large.bin -of /tmp/a.srt jfk.wav'
Benchmark 1: whisper-cpp --model ~/.local/share/blisper/ggml-large.bin -of /tmp/a.srt jfk.wav
 Time (mean ± σ): 9.025 s ± 0.383 s [User: 26.350 s, System: 6.531 s]
 Range (min ... max): 8.329 s ... 9.428 s 10 runs

When I run make test in the go/buildings folder, it succeeds!

image

I'm not an expert, but it seems like that's just a warning and the build is working

Thanks for the reply, but make whisper doesn't generate a binary file, so I think there's something wrong with it

The execution of make whisper reads :

whisper: mkdir
	@echo Build whisper
	@${MAKE} -C ... /... libwhisper.a

Then in the parent directory, it should generate a target file called libwhisper.a, but it doesn't do what I expect it to do.

Try ./build/go-whisper -model models/ggml-base.bin -language ru samples/speech.wav

• flags go before arguments
• flags only use one dash

I'm getting the same error in different scenario, I used the bindings and I'm running this command:

LIBRARY_PATH=./whisper.cpp C_INCLUDE_PATH=./whisper.cpp go build .

And I get this output:

/opt/homebrew/Cellar/go/1.21.0/libexec/pkg/tool/darwin_arm64/link: running cc failed: exit status 1
ld: Undefined symbols:
 _MTLCopyAllDevices, referenced from:
 _ggml_metal_init in libwhisper.a[7](ggml-metal.o)
 _MTLCreateSystemDefaultDevice, referenced from:
 _ggml_backend_metal_buffer_type_alloc_buffer in libwhisper.a[7](ggml-metal.o)
 _ggml_backend_metal_buffer_type_get_max_size in libwhisper.a[7](ggml-metal.o)
 _ggml_backend_metal_buffer_from_ptr in libwhisper.a[7](ggml-metal.o)
 _ggml_metal_init in libwhisper.a[7](ggml-metal.o)
 _OBJC_CLASS_$_MTLCaptureDescriptor, referenced from:
 in libwhisper.a[7](ggml-metal.o)
 _OBJC_CLASS_$_MTLCaptureManager, referenced from:
 in libwhisper.a[7](ggml-metal.o)
 _OBJC_CLASS_$_MTLCompileOptions, referenced from:
 in libwhisper.a[7](ggml-metal.o)
 _OBJC_CLASS_$_MTLComputePassDescriptor, referenced from:
 in libwhisper.a[7](ggml-metal.o)
 _OBJC_CLASS_$_NSBundle, referenced from:
 in libwhisper.a[7](ggml-metal.o)
 _OBJC_CLASS_$_NSProcessInfo, referenced from:
 in libwhisper.a[7](ggml-metal.o)
 _OBJC_CLASS_$_NSString, referenced from:
 in libwhisper.a[7](ggml-metal.o)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [build] Error 1

#1899 Related issue.

Hey, that's a different thing - and very related to your OS and docker setup, not with metal and mac os + arm. In any case look at docker capabilities to enable gpu access - that's very dependent on drivers and so on: https://docs.docker.com/compose/gpu-support/

no GPU, just Intel CPU for the inference. I suspect the AVX or F16C capacity is not leveraged by the golang binary.

system_info: n_threads = 24 / 24 | AVX = 1 | AVX2 = 1 | AVX512 = 0 | FMA = 1 | NEON = 0 | ARM_FMA = 0 | METAL = 0 | F16C = 1 | FP16_VA = 0 | WASM_SIMD = 0 | BLAS = 0 | SSE3 = 1 | SSSE3 = 1 | VSX = 0 | CUDA = 0 | COREML = 0 | OPENVINO = 0

from the log, it looks like the AVX is already enabled when building libwhisper.a
Is any flag need to be set when building the final binary? Thanks.

RUN C_INCLUDE_PATH="/app/whisper.cpp2/" LIBRARY_PATH="/app/whisper.cpp2/" go build -ldflags "-linkmode 'external' -extldflags '-static'" -v -o myapp

#11 [libbuilder 5/6] RUN make whisper
#11 0.172 Mkdir build
#11 0.173 Mkdir models
#11 0.175 Build whisper
#11 0.176 make[1]: Entering directory '/whisper.cpp'
#11 0.191 I whisper.cpp build info: 
#11 0.191 I UNAME_S: Linux
#11 0.191 I UNAME_P: unknown
#11 0.191 I UNAME_M: x86_64
#11 0.191 I CFLAGS: -I. -O3 -DNDEBUG -std=c11 -fPIC -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -pthread -mavx -mavx2 -mfma -mf16c -msse3 -mssse3
#11 0.191 I CXXFLAGS: -I. -I./examples -O3 -DNDEBUG -std=c++11 -fPIC -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -pthread -mavx -mavx2 -mfma -mf16c -msse3 -mssse3
#11 0.191 I LDFLAGS: 
#11 0.191 I CC: cc (Alpine 13.2.1_git20231014) 13.2.1 20231014
#11 0.191 I CXX: g++ (Alpine 13.2.1_git20231014) 13.2.1 20231014
#11 0.191 
#11 0.192 cc -I. -O3 -DNDEBUG -std=c11 -fPIC -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -pthread -mavx -mavx2 -mfma -mf16c -msse3 -mssse3 -c ggml.c -o ggml.o
#11 11.77 cc -I. -O3 -DNDEBUG -std=c11 -fPIC -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -pthread -mavx -mavx2 -mfma -mf16c -msse3 -mssse3 -c ggml-alloc.c -o ggml-alloc.o
#11 12.55 cc -I. -O3 -DNDEBUG -std=c11 -fPIC -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -pthread -mavx -mavx2 -mfma -mf16c -msse3 -mssse3 -c ggml-backend.c -o ggml-backend.o
#11 13.73 cc -I. -O3 -DNDEBUG -std=c11 -fPIC -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -pthread -mavx -mavx2 -mfma -mf16c -msse3 -mssse3 -c ggml-quants.c -o ggml-quants.o
#11 21.87 g++ -I. -I./examples -O3 -DNDEBUG -std=c++11 -fPIC -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -pthread -mavx -mavx2 -mfma -mf16c -msse3 -mssse3 -c whisper.cpp -o whisper.o
#11 37.16 ar rcs libwhisper.a ggml.o ggml-alloc.o ggml-backend.o ggml-quants.o whisper.o
#11 37.17 make[1]: Leaving directory '/whisper.cpp'
#11 DONE 37.3s

It would also be awesome if it could take all common audio codecs/formats (AC3, DTS, DTS-HD MA, TrueHD, TrueHD Atmos, OGG/OGA, MP4/M4A, ASF/WMA, MP3, FLAC, ALAC, DST, OPUS) of another process, that would be able to take in anything and convert it to WAV, so it can process it :)

At least it would be cool on the long run. So this can be used for analysing every Video/Playbook and eighter create subtitles, or just to index the words it contains.

I'm not the author but based on my usage, live streaming would be possible if you buffered chunks (as in each 10s streaming you run the model on a goroutine). Converting from stream to chunks would be on your own. I think that even Context.Process taking a full buffer and its segment/progress callbacks can be wrapped with an io.Reader.
Running the model over the whole wav file takes a long time because it is expensive on CPU and GPU, with impressive improvements depending on your hardware (I got a 10x speed bump testing the same code on a mac M1 vs mac M3), but AFAIK it doesn't benefit of any live tuning/feedback so by my tests you get a pretty decent result chopping a wav file (which you can test with /bin/dd locally).
I figure that while you are streaming if you can detect silence or volume drops it would prevent mid-tokens.
About converting formats I think that the choice is to have the library understand the most basic/available format so we can overlay specialized libraries with their optimization to understand other formats and containers. I've been piping audio from ffmpeg. Hope that helps.

You make your Go code read float32 from standard input which is what the whisper model reads

Then feed it from ffmpeg -hide_banner -i i.mp4 -ac 1 -ar 16k -f f32le - | myGoCode
or any other float stream you can come up with
(little endian hardware)

use large-v3-turbo model of 2024-12: it’s ×ばつ better

With Core ML on M, you be ×ばつ at 20% CPU load
— the host can still be used normally or compile things

On Linux Intel cpu whisper will eat all cores 0%id, 2 GiB RAM and still only do ×ばつ
— Quantize no faster

Core ML is ×ばつ and 80% of the cpu better

It looks like it's not linking with the CUDA-version of GGML - so you should build GGML with:

GGML_CUDA=1 make libggml.a

And that might make the CUDA-enabled version of ggml

This didn't help, unfortunately.

Sorry to hear that. I do have an example of buiding with CUDA enabled libggml / libwhisper / go bindings in my project here, if that's at all useful?

https://github.com/mutablelogic/go-whisper

I use pkgconfig to bind to all the libraries needed and I start by generating all the pkgconfig files first.

Thanks David, appreciate your taking the time to reply. Will check out your project to see if I can get some pointers.

Hey! If anyone is still interested:
I submitted a patch which finally allows us to compile the go examples with cuda support in this pr: #2416

Definitely still interested! Thank you very much! Will take a look.

Here are commands for macOS 15.2: Core ML and OpenMP
#2689 (comment)

Looked into it a bit and you need to replace the following in bindings/go/Makefile:33:
@${MAKE} -C ../.. libwhisper.a -> @${MAKE} -C ../.. build

But now if I run make test I get the following error:
/tmp/go-build2035026264/b001/go.test: error while loading shared libraries: libwhisper.so.1: cannot open shared object file: No such file or directory

I also took a look at this. Version 1.7.3 of whisper.cpp has deprecated building via Makefile, so the new way to do it is to update the Makefile targets is:

whisper: mkdir
	@echo Build whisper
	@cmake -S ../.. -B ${BUILD_DIR} -DBUILD_SHARED_LIBS=0
	@cmake --build ${BUILD_DIR} -j --config Release	

On my system, this places some libraries in the build folder, which are required to link (relative to ${BUILD_DIR}):

• GGML ggml/src/libggml.a, ggml/src/libggml-cpu.a, ggml/src/libggml-base.a
• GGML Extensions ggml/src/ggml-blas/libggml-blas.a, ggml/src/ggml-metal/libggml-metal.a,
• Whisper src/libwhisper.a

I know from also compiling with CUDA that there are other libraries created when GPU-specific features are also included. The whisper process creates a file ${BUILD_DIR}/whisper.pc which can be used to bind the go bindings to whisper, but only if you install whisper first, or you could I guess fix-up this file in a new Makefile target.

The bigger issue is that the go bindings are out-of-date as the whisper API has changed. I have written some new bindings here but didn't test them enough to merge them back into the whisper.ccp repo.

With a bit more testing, a modified version of the whisper.pc file would look something like this (testing on my MacOS x86):

prefix=${PATH_TO}/whisper.cpp
exec_prefix=${prefix}/bindings/go
libdir=${exec_prefix}/build
Name: whisper
Description: Port of OpenAI's Whisper model in C/C++
Version: 1.7.3
Libs: -L${libdir}/src -lwhisper -L${libdir}/ggml/src -lggml -lggml-base -lggml-cpu -L${libdir}/ggml/src/ggml-metal -lggml-metal -L${libdir}/ggml/src/ggml-blas -lggml-blas 
Cflags: -I${prefix}/include -I${prefix}/ggml/include

Not sure yet how you'd like to create this pkgconfig file. I have some examples in my own repo on using go generate to do this, but not sure it's the right long-term approach, given all the variations of GGML extensions.

The include directory flags are as follows, replacing ${prefix} with the repository path (whisper.cpp)

-I${prefix}/include -I${prefix}/ggml/include

Thank you for your reply. I executed the following command:

$env:CGO_CFLAGS = "-I F:/proj/whisper/whisper.cpp/include -I F:/proj/whisper/whisper.cpp/ggml/include -I F:/proj/echo/lib"

With this setup, the error about missing ggml.h was resolved. However, now I am encountering a new issue: undefined references to various ggml methods. The error messages are as follows (there are many similar errors, so I am only providing a snippet):

。。。many similar error logs
F:/proj/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: F:\\proj\\echo\\lib/libwhisper.a(whisper.cpp.obj):whisper.cpp:(.text+0x21b23): undefined reference to `ggml_backend_dev_name'
F:/proj/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: F:\\proj\\echo\\lib/libwhisper.a(whisper.cpp.obj):whisper.cpp:(.text+0x21c0e): undefined reference to `ggml_backend_tensor_set'
F:/proj/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: F:\\proj\\echo\\lib/libwhisper.a(whisper.cpp.obj):whisper.cpp:(.text+0x21ccd): undefined reference to `ggml_backend_alloc_ctx_tensors'
F:/proj/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: F:\\proj\\echo\\lib/libwhisper.a(whisper.cpp.obj):whisper.cpp:(.text+0x2b12e): undefined reference to `ggml_backend_buffer_free'
F:/proj/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: F:\\proj\\echo\\lib/libwhisper.a(whisper.cpp.obj):whisper.cpp:(.text+0x2b258): undefined reference to `ggml_backend_buffer_clear'
F:/proj/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: F:\\proj\\echo\\lib/libwhisper.a(whisper.cpp.obj):whisper.cpp:(.text+0x2b455): undefined reference to `ggml_time_us'
F:/proj/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: F:\\proj\\echo\\lib/libwhisper.a(whisper.cpp.obj):whisper.cpp:(.text+0x2b646): undefined reference to `ggml_time_us'
F:/proj/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: F:\\proj\\echo\\lib/libwhisper.a(whisper.cpp.obj):whisper.cpp:(.text+0x2b6ca): undefined reference to `ggml_time_us'
F:/proj/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: F:\\proj\\echo\\lib/libwhisper.a(whisper.cpp.obj):whisper.cpp:(.text+0x2c33b): undefined reference to `ggml_time_us'
F:/proj/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: F:\\proj\\echo\\lib/libwhisper.a(whisper.cpp.obj):whisper.cpp:(.text+0x2c4ae): undefined reference to `ggml_time_us'
F:/proj/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: F:\\proj\\echo\\lib/libwhisper.a(whisper.cpp.obj):whisper.cpp:(.text+0x2c7b1): more undefined references to `ggml_time_us' follow
F:/proj/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: F:\\proj\\echo\\lib/libwhisper.a(whisper.cpp.obj):whisper.cpp:(.text+0x1108d): undefined reference to `ggml_log_set'
collect2.exe: error: ld returned 1 exit status

I have also tried copying all ggml-related files into my project's lib directory and linking them, but I encountered the same errors.

Do you have any suggestions on how I can resolve this issue? Thank you in advance for your help!

Yes, you'll also need to link the GGML libraries. The library flags (CGO_ LDFLAGS) will be something like:

-L${prefix}/ggml -lggml

but it depends on the version of whisper.cpp (you can see the discussion above about the recent changes to building)

Thanks for your willingness to help, even though it didn’t quite solve my issue. For me, looking into the Makefile is still a bit challenging, but I’ll try with ChatGPT’s assistance.

By the way, why is this Go building tool in such a nearly unmaintained state? I thought Go was supposed to be a pretty popular language!

It's popular, but known to have a "difficult" time binding with third party libraries :-( Good luck and let me know if you need some more help.

Hello @resolutecacke, do you have something for

ework Metal -framework Foundation -framework CoreGraphics -O2 -g -framework CoreFoundation
clang: error: unsupported option '-fopenmp'
make: *** [run] Error 1

Maybe? I running on M1 Pro and I run using: C_INCLUDE_PATH="/.../projects/whisper.cpp/include" LIBRARY_PATH="/.../projects/whisper.cpp/bindings/go/build/src" CGO_CFLAGS="-I /.../projects/whisper.cpp/include -I /.../projects/whisper.cpp/ggml/include" go run ./cmd/serve

I'm stupid, I'm using default clang, you need to use llvm ^