Check here: https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/VNP6Mwz_B6o

I fixed __divdi3: not defined errors with adding -lgcc_s to LDFLAGS in C:\Go\src\pkg\github.com\mattn\go-sqlite3\sqlite3_windows.go file:

package sqlite

/*
#cgo CFLAGS: -I. -fno-stack-check -fno-stack-protector -mno-stack-arg-probe
#cgo LDFLAGS: -lmingwex -lmingw32  -lgcc_s
*/
import "C"

and then go install in that folder.

Best regards

Hmm, libgcc_s.a is provided for mingw64. it don't exists in my mingw/lib directory.

I can confirm that works for me on a 32-bit and 64-bit Windows now.

I have libgcc_s.a in "C:\MinGW\lib64" (mingw64) on the 64-bit system. On the 32-bit system I have "C:\MinGW\lib\gcc\mingw32\4.6.2\libgcc_s.a" in case that helps at all.

Thanks & Regards

Oh, ok, I'll check it soon.

Hmm, if linking libgcc_s.a on mingw32 32bit, example/main crash.

@stever If change as following, can it succeeded to build?

#cgo windows/386 CFLAGS: -I. -fno-stack-check -fno-stack-protector -mno-stack-arg-probe
#cgo windows/386 LDFLAGS: -lmingwex -lmingw32
#cgo windows/amd64 CFLAGS: -I. -fno-stack-check -fno-stack-protector -mno-stack-arg-probe
#cgo windows/amd64 LDFLAGS: -lmingwex -lmingw32  -lgcc_s

Build succeeded but then when I run the example it fails with similar error messages, on win32.

I think I need the -lgcc_s flag on win32 and not win64.

The example/main didn't crash for me when I ran it with this on either architecture. I made sure sqlite3.dll and include files were not on the path either in case that was having an effect. I have a fairly clean setup so far as I know and the suggestion from matrixik works for me.

I'm checking this issue on windows 32bit and It don't require libgcc_s.a for building.

Sure, seem to need to link to it on win32 though. I didn't need to link to it with win64.

Hmm, inversed result?

I don't know why linking libgcc_s.a on win32 crashes for you. Maybe we have different mingw32 versions? I've used a fairly recent mingw-get-inst installer.

What version of go?

1.0.3

Me too...

Ah, but I'm using hg tip.

Hi, just forked go-sqlite3 & added the following flags in sqlite3.go & was able to subsequently do a simple "go get" to install the package. Example compiles perfectly on win32 with standard MinGW. Had the same issues & soln. building Russ Cox's sqlite3 bindings... libgcc_s.a contains the "__divdi3" which gets rid of not found etc errors. Removing the stack protection gets rid of "__chkstk_ms" not found errors which i simply wasn't able to figure out (this is supposed to be defined in the standard libgcc.a which is included by default by MinGW but somehow wasn't getting linked)

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

That flags is already put in sqlite3_windows.go

hmmmm..... a simple "go get" was throwing a whole bunch of starting with __divdi3 type of errors on compiling the test program before i made this change. Wonder why.... maybe because of -lgcc_s?

@mattn no it's not, you didn't push it to github

@matrixik ? I didn't change anything. What you want?

@srinathdevelopment

maybe because of -lgcc_s?

I guess it so.

You didn't add -lgcc_s to sqlite3_windows.go
https://github.com/mattn/go-sqlite3/blob/master/sqlite3_windows.go
that's why @srinathdevelopment still see errors with go get (and I too)

@matrixik see above. if add -lgcc_s on win32, it occur crashed.

@mattn That's true for you, but is it true for others? Not true for me. It's only required in my win32 build but doesn't hurt to have it for both that and 64-bit windows too.

@stever if it occur on your environment just only, I'll change to

#cgo windows/386 CFLAGS: -I. -fno-stack-check -fno-stack-protector -mno-stack-arg-probe
#cgo windows/386 LDFLAGS: -lmingwex -lmingw32
#cgo windows/amd64 CFLAGS: -I. -fno-stack-check -fno-stack-protector -mno-stack-arg-probe
#cgo windows/amd64 LDFLAGS: -lmingwex -lmingw32  -lgcc_s

Is this ok?

@mattn Really is it needed in 64-bit windows at all? Weird that I have the complete opposite. I'll just fork it to work around the issue I have, but I'm not assuming right now I'm the only person that does. I've tested this on a bunch of computers with consistent results.

@stever Where did you get sqlite3.dll or header files ?

@mattn I've tested with an without my own sqlite3.dll and header files. I made a fork before just to remove the static include for windows here as a special case. However, on windows I still like this so right now I'm not using anything outside of your repository plus the '-lgcc_s' fix mentioned above.

I'm confusing...

Maybe I've confused you... I didn't/don't fully understand the problem but the suggested fix '-lgcc_s' worked for me and that's all I needed. It's neat to be able to include SQLite statically on windows so I prefer this than the DLL option that I had mentioned as my initial workaround. It would be ideal if the '-lgcc_s' fix work for you and everyone else.

It would be useful if other people will confirm there experience with this on 32-bit windows.

ok, -lgcc_s is removed, and it seems that you don't get fail to build. :)

When the build error happen? building example/main.go ? If it so, please show me the result of go build -x main.go.

No build error. Just errors when running. Here's the output:

C:\Users\Steve\Documents\Go\src\github.com\mattn\go-sqlite3\example>go run main.go
# command-line-arguments
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __moddi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __divdi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __moddi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __divdi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __divdi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __divdi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __divdi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __moddi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __divdi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __moddi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __moddi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __divdi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __divdi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __divdi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __divdi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __moddi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __moddi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __umoddi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __udivdi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __umoddi3: not defined
C:\Users\Steve\AppData\Local\Temp\go-build545176583/github.com/mattn/go-sqlite3.a(sqlite3_windows.)(.text): __udivdi3: not defined
too many errors

C:\Users\Steve\Documents\Go\src\github.com\mattn\go-sqlite3\example>    

If use #cgo LDFLAGS: -lgcc -lgcc_s -lmingwex, it can work ?

Actually no - same errors. Still, if I use #cgo LDFLAGS: -lmingwex -lmingw32 -lgcc_s it does. Seems interesting.

<g> OMG

Also built with #cgo LDFLAGS: -lmingwex -lmingw32 -lgcc -lgcc_s and the example doesn't work. It does work if I remove -lgcc to have #cgo LDFLAGS: -lmingwex -lmingw32 -lgcc_s

I'm using the command go install though and I'm not sure if that hides build errors. There was no ouput.

Hmm, maybe I must write __divdi3 on my code.

The example even works for me if all I use is #cgo LDFLAGS: -lgcc_s

I'm not so interested in having sqlite3 statically compiled over having it has a DLL dependency. Initially I made a fork and included the following info to help build 32-bit and 64-bit sqlite3.dll on Windows. Perhaps it is useful.

Download the SQLite amalgamation source
and compile using MinGW.

64-bit:

gcc -shared -DWIN64 -DNDEBUG -D_WINDOWS -D_USRDLL -DNO_TCL -D_CRT_SECURE_NO_DEPRECATE -DTHREADSAFE=1 -DTEMP_STORE=1 -DSQLITE_MAX_EXPR_DEPTH=0 -m64 -I. shell.c sqlite3.c -o sqlite3.dll -Wl,--out-implib,sqlite3.a

32-bit:

gcc -shared -DWIN32 -D_WINDOWS -D_USRDLL -DNO_TCL -D_CRT_SECURE_NO_DEPRECATE -DTHREADSAFE=1 -DTEMP_STORE=1 -DSQLITE_MAX_EXPR_DEPTH=0 -m32 -I. shell.c sqlite3.c -o sqlite3.dll -Wl,--out-implib,sqlite3.a

• Copy sqlite3.dll to a location included in LIBRARY_PATH.
• Copy sqlite3.h and sqlite3ext.h to a location included in C_INCLUDE_PATH.

See Compiling SQLite for Windows (64-bit)

I had struggled without the above info to make 32-bit and 64-bit versions of the sqlite3.dll which I required.

Probably, whether compiler use divdi3 or not, is related on CPU. On my
environment, the optimization is disabled maybe. And probably your is
enabled. i.e. divdi3 is not linked from libgcc.a on my environment,
And libgcc_s.a is linked not properly(compiler isn't expected).

On 12/10/12, Steven Robertson [email protected] wrote:

I had struggled without the above info to make 32-bit and 64-bit versions of
the sqlite3.dll which I required.

---

Reply to this email directly or view it on GitHub:
#27 (comment)

• Yasuhiro Matsumoto

I've only tested using Windows in VMware for 32-bit, though hosted on systems with both 64-bit Intel and AMD CPU.

I'll try to build without optimization of CPU arch in next time.

On 12/11/12, Steven Robertson [email protected] wrote:

I've only tested using Windows in VMware for 32-bit, though hosted on
systems with both 64-bit Intel and AMD CPU.

---

Reply to this email directly or view it on GitHub:
#27 (comment)

• Yasuhiro Matsumoto

minix let me know answer.

https://groups.google.com/d/msg/golang-nuts/5If6AoWD_mU/jjBq8XvBTUgJ

Ah, a resolved issue in Go. I'm not keen to compile Go on Windows, though maybe it's easy... I'll give it a go.

Actually, building tip from source is no problem. Just need Mercurial installed... and it works!

No need for the -lgcc_s flag at all with Go source tip revision, on either 32-bit Windows or 64-bit Windows.

Thanks for the resolution.

Trying install Go from source, fails on compilation time and even that it look like Go working I couldn't go get some packages (but go get github.com/gorilla/mux worked o_O ):

d:\Dropbox\_Politechnika>go get code.google.com/p/go.crypto/scrypt
package code.google.com/p/go.crypto/scrypt: Get https://code.google.com/p/go/source/checkout?repo=crypto: dial tcp 173.194.65.138:443: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

d:\Dropbox\_Politechnika>go get thegoods.biz/httpbuf
package thegoods.biz/httpbuf: unrecognized import path "thegoods.biz/httpbuf"

Move back to Windows installer and go get working again

But when I have Go installed from source go-sqlite3 worked OK without -lgcc_s flag.

I would leave that issue open until Go stable release will fix it (next year?).

Best regards

Did you make sure this issue on hg tip?

Working without problems on tip.

Best regards,
Dobrosław Żybort

@matrixik thank you! is this closable?

Yes.
But maybe you can add some info to readme that there can be problems with Go 1.0 on Windows with link to this issue (or specific post showing how to fix it).

Best regards,
Dobrosław Żybort

Thank you all.

https://medium.com/@yaravind/go-sqlite-on-windows-f91ef2dacfe