Recreate of issue #203

[tdolby]

Bumped into the same issue as described in #203 while building with gccgo on ppc64 (big endian):

$ go get github.com/mattn/go-sqlite3
$ go install src/github.com/mattn/go-sqlite3/_example/simple/simple.go
# command-line-arguments
/usr/bin/ld: $WORK/libgo-sqlite3.a893956317(sqlite3-binding.o): undefined reference to symbol 'pthread_mutexattr_destroy@@GLIBC_2.3'
/usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

but as @ianlancetaylor rightly pointed out, this ought not to be happening because libpthread should be linked in automatically. The code works fine on linux-amd64 with gccgo 5.3.0 (go v1.4.2), but not on linux-ppc64 with gcc-6.1.0 (go v1.6.1).

The simplest solution does seem to be to add -lpthread into LDFLAGS in this package, but if you'd rather I chase the gccgo side of things instead then this issue can be closed; it seemed worth providing the recreate (missing from #203) just in case it helps (even if it's just a misconfiguration of gccgo).

Version for gccgo:

$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=/usr/contrib/libexec/gcc/powerpc64-unknown-linux-gnu/6.1.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ../gcc-6.1.0/configure --prefix=/usr/contrib --enable-languages=c,c++,go --disable-multilib
Thread model: posix
gcc version 6.1.0 (GCC) 

libgo ldd output:

$ ldd /usr/contrib/lib64/libgo.so
        linux-vdso64.so.1 (0x00003fff9d5a0000)
        libpthread.so.0 => /lib64/power6/libpthread.so.0 (0x00003fff9bfb0000)
        libm.so.6 => /lib64/power6/libm.so.6 (0x00003fff9bec0000)
        libgcc_s.so.1 => /usr/contrib/lib64/libgcc_s.so.1 (0x00003fff9be80000)
        libc.so.6 => /lib64/power6/libc.so.6 (0x00003fff9bc60000)
        /lib64/ld64.so.1 (0x0000000028430000)

[gjrtimmer]

@tdolby can you please checkout branch fix/306 and try to compile for linux-ppc64.

[gjrtimmer]

@tdolby any update ?

[tdolby]

@gjrtimmer Sorry - missed the first notification :( I'll try and test this early next week.

[gjrtimmer]

@tdolby I hope the fix works for you.

[gjrtimmer]

@tdolby I rebased fix/306 with the latest master.

[gjrtimmer]

@tdolby fix/306 branch successful with Travis-CI we will await your test.

[gjrtimmer]

@tdolby Any success ?

[tdolby]

Having issues building now, as it looks like the world has moved on: when I run

$ go get github.com/mattn/go-sqlite3

I now get

package context: unrecognized import path "context" (import path does not begin with hostname)

which looks like I need go 1.7 and can't build with gccgo 6.1.0 . . .

I shall try and get gcc7 going and see how it works there.

[tdolby]

I don't have gcc7 working yet, but I have applied your branch changes on top of release 1.2 (which does work with go 1.6) and they build successfully. From the perspective of the original environment, your fix is looking good, and works for ppc64.

From the perspective of current source, I haven't confirmed that the solution still works with current master code and recent GCC versions; I can try and get that going if it's worthwhile?

[gjrtimmer]

@tdolby I think you should give it a try, I will incorperate the fix at least into the current v2.0.0 branch I'm building

[gjrtimmer]

@tdolby made small change, included the options within sqlite3_other.go instead of separate files and included ppc64le also. Would it be too much to do a quick retest after you pull the latest change from fix/306 ? I also created a PR so when Travis-CI is successful you can start using the master branch.

[tdolby]

No problem - I'm building gccgo 7.3 right now but can certainly try out the new changes on that version and also 6.1.0.

[gjrtimmer]

@tdolby Sounds great, PR is awaiting your test and approval.

[gjrtimmer]

Add

Enhancement:

• ppc
• ppc64
• ppc64le

[gjrtimmer]

@tdolby any update on latest test ?

[tdolby]

Yes - just finished testing everything with gccgo 6.1, 7.3, and 8.1 on ppc64, and everything works as expected. The patched sqllite3 1.2 source works for all compilers, and the current 306 source works for 7.3 and 8.1 due to language constraints described above stopping 6.1 from working.

Thanks for fixing this!