Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Works with 64-bit Windows (without pkg-config) but doesn't work with 32-bit Windows. #27

Closed
stever opened this issue Nov 2, 2012 · 85 comments

Comments

@stever
Copy link

stever commented Nov 2, 2012

Hello. I've been having trouble with getting this to work on Windows using 32-bit and then found that it works on 64-bit Windows even without pkg-config (which incidentally I had got installed though I'm not sure that could help after all). Having learned more about the current head revision I understand that it works without pkg-config on Windows however I could not get it to work with 32-bit Windows and I get a stream of error messages like "__divdi3: not defined". My understanding of C and cgo is patchy and I'm not sure what this means. I couldn't see why it should be different on 32-bit Windows but perhaps some other compiler option is required.

I resolved my problems by discarding pkg-config and the static compilation on Windows and use the DLL instead, which is what other platforms are using anyway. So instead of the #cgo pkg-config line I'm using "#cgo LDFLAGS: -lsqlite3" having the environment set up with the include files on the path for gcc (LIBRARY_PATH and C_INCLUDE_PATH). The little work with cgo that I've done so far this works best with the smallest of changes to the source-code across platforms.

I've never used pkg-config before and while I had no trouble with it on other platforms on Windows it was a struggle getting an environment set up. Wouldn't this be better without pkg-config?

In any case the current head revision doesn't appear to work for 32-bit Windows and the static compilation as an exception for Windows seems unnecessarily complicated. Maybe you can get it to work but I wonder if this is the wrong direction to go.

@matrixik
Copy link
Contributor

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

@mattn
Copy link
Owner

mattn commented Nov 29, 2012

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

@stever
Copy link
Author

stever commented Nov 29, 2012

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

@mattn
Copy link
Owner

mattn commented Nov 29, 2012

Oh, ok, I'll check it soon.

@mattn
Copy link
Owner

mattn commented Nov 29, 2012

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

@mattn
Copy link
Owner

mattn commented Nov 29, 2012

@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

@stever
Copy link
Author

stever commented Nov 29, 2012

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.

@mattn
Copy link
Owner

mattn commented Nov 29, 2012

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

@stever
Copy link
Author

stever commented Nov 29, 2012

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

@mattn
Copy link
Owner

mattn commented Nov 29, 2012

Hmm, inversed result?

@stever
Copy link
Author

stever commented Nov 29, 2012

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.

@mattn
Copy link
Owner

mattn commented Nov 29, 2012

What version of go?

@stever
Copy link
Author

stever commented Nov 29, 2012

1.0.3

@mattn
Copy link
Owner

mattn commented Nov 29, 2012

Me too...

@mattn
Copy link
Owner

mattn commented Nov 29, 2012

Ah, but I'm using hg tip.

@srinathh
Copy link

srinathh commented Dec 5, 2012

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

@mattn
Copy link
Owner

mattn commented Dec 6, 2012

That flags is already put in sqlite3_windows.go

@srinathh
Copy link

srinathh commented Dec 6, 2012

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?

@matrixik
Copy link
Contributor

matrixik commented Dec 6, 2012

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

@mattn
Copy link
Owner

mattn commented Dec 7, 2012

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

@mattn
Copy link
Owner

mattn commented Dec 7, 2012

@srinathdevelopment

maybe because of -lgcc_s?

I guess it so.

@matrixik
Copy link
Contributor

matrixik commented Dec 7, 2012

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)

@mattn
Copy link
Owner

mattn commented Dec 7, 2012

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

@stever
Copy link
Author

stever commented Dec 7, 2012

@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.

@mattn
Copy link
Owner

mattn commented Dec 7, 2012

@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?

@stever
Copy link
Author

stever commented Dec 7, 2012

@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.

@mattn
Copy link
Owner

mattn commented Dec 7, 2012

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

@stever
Copy link
Author

stever commented Dec 7, 2012

@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.

@mattn
Copy link
Owner

mattn commented Dec 7, 2012

I'm confusing...

@stever
Copy link
Author

stever commented Dec 7, 2012

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.

@mattn
Copy link
Owner

mattn commented Dec 10, 2012

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

@mattn
Copy link
Owner

mattn commented Dec 10, 2012

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

@stever
Copy link
Author

stever commented Dec 10, 2012

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>    

@mattn
Copy link
Owner

mattn commented Dec 10, 2012

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

@stever
Copy link
Author

stever commented Dec 10, 2012

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

@mattn
Copy link
Owner

mattn commented Dec 10, 2012

<g> OMG

@stever
Copy link
Author

stever commented Dec 10, 2012

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.

@mattn
Copy link
Owner

mattn commented Dec 10, 2012

Hmm, maybe I must write __divdi3 on my code.

@stever
Copy link
Author

stever commented Dec 10, 2012

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

@stever
Copy link
Author

stever commented Dec 10, 2012

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)

@stever
Copy link
Author

stever commented Dec 10, 2012

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

@mattn
Copy link
Owner

mattn commented Dec 10, 2012

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

@stever
Copy link
Author

stever commented Dec 10, 2012

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

@mattn
Copy link
Owner

mattn commented Dec 10, 2012

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

@mattn
Copy link
Owner

mattn commented Dec 14, 2012

@stever
Copy link
Author

stever commented Dec 14, 2012

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.

@stever
Copy link
Author

stever commented Dec 14, 2012

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.

@matrixik
Copy link
Contributor

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

@mattn
Copy link
Owner

mattn commented Feb 13, 2013

Did you make sure this issue on hg tip?

@matrixik
Copy link
Contributor

Working without problems on tip.

Best regards,
Dobrosław Żybort

@mattn
Copy link
Owner

mattn commented Feb 13, 2013

@matrixik thank you! is this closable?

@matrixik
Copy link
Contributor

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

mattn added a commit that referenced this issue Feb 13, 2013
@mattn
Copy link
Owner

mattn commented Feb 13, 2013

Thank you all.

@MstrVLT
Copy link

MstrVLT commented Feb 26, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants