fabric-ca release 1.5 binary fails with sqlite3 error about fabric-ca HOT 11 CLOSED

I looked back at the v1.5.0 release binary and we can disregard it since @lindluni built it locally.

However, the issue remains even on Fabric CA v1.5.1 (go1.15.7) which I released through the release pipeline. I get error upon startup on my mac:

[ERROR] Error occurred initializing database: Failed to open sqlite3 DB: Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work. This is a stub

I then tried v1.4.9 (go1.14.10) and it works.

I've compared the v1.4.9 release pipeline build versus v1.5.1 release pipeline build and they look the same:

v1.4.9
https://dev.azure.com/Hyperledger/Fabric/_build/results?buildId=22607&view=logs&j=f441b665-1d0c-5977-cc64-878a77432c6b&t=7ffd72f8-da0f-500b-7a41-44129d5fb357
GOOS=darwin GOARCH=amd64 go build -o /__w/1/go/src/github.com/hyperledger/fabric-ca/release/darwin-amd64/bin/fabric-ca-server -tags "" -ldflags "-X github.com/hyperledger/fabric-ca/lib/metadata.Version=1.4.9" github.com/hyperledger/fabric-ca/cmd/fabric-ca-server cd release/darwin-amd64 && tar -czvf hyperledger-fabric-ca-darwin-amd64-1.4.9.tar.gz

v1.5.1
https://dev.azure.com/Hyperledger/Fabric/_build/results?buildId=39255&view=logs&j=f441b665-1d0c-5977-cc64-878a77432c6b&t=7ffd72f8-da0f-500b-7a41-44129d5fb357
GOOS=darwin GOARCH=amd64 go build -o /__w/1/go/src/github.com/hyperledger/fabric-ca/release/darwin-amd64/bin/fabric-ca-server -tags "" -ldflags "-X github.com/hyperledger/fabric-ca/lib/metadata.Version=1.5.1" github.com/hyperledger/fabric-ca/cmd/fabric-ca-server cd release/darwin-amd64 && tar -czvf hyperledger-fabric-ca-darwin-amd64-1.5.1.tar.gz

Looking at the cgo docs it says:

The cgo tool is enabled by default for native builds on systems where it is expected to work. It is disabled by default when cross-compiling. You can control this by setting the CGO_ENABLED environment variable when running the go tool: set it to 1 to enable the use of cgo, and to 0 to disable it.

And:

When cross-compiling, you must specify a C cross-compiler for cgo to use. You can do this by setting the generic CC_FOR_TARGET or the more specific CC_FOR_${GOOS}_${GOARCH}.

It sounds like these settings are required, but as far as I know we have never set either of these, so I actually can't explain why it works in the case of v1.4.9.

Any ideas @lindluni @mastersingh24 @sykesm ?

from fabric-ca.

The simple solution is to just run the pipeline across all three platforms. We just do the binary build on a Windows machine, a Mac machine, and a Linux machine. Which is possible to do in azure devops. I'm driving right now but when I get home this evening I'll put something together for it, unless somebody else wants to do it. The cross compilation is the issue you need a native C cross-compiler if you don't explicitly disable cgo.

from fabric-ca.

I guess I shouldn't say the simplest solution, the simplest solution is to just disable cgo. But if I recall correctly one of the databases systems reach into cgo now for something.

from fabric-ca.

Thanks @lindluni , yeah sqlite requires cgo. Any idea how the cross compilation actually worked in v1.4.9?

from fabric-ca.

It didn't, we updated sqlite around that time. Sqlite didn't used to require cgo. I remember working on the issue, when we pulled in the new dependency all of a sudden it began using cgo

from fabric-ca.

@denyeart,

It was this change that made it cross-compilable, but erroneously introduced the CGO dependency: 2f6ef1c

We just need to change this part in the release pipeline to target Windows, Linux, Mac instead of a container: https://github.com/hyperledger/fabric-ca/blob/main/ci/azure-pipelines-release.yml#L22

I'll try to get to this tomorrow

from fabric-ca.

thanks for the background @lindluni

I tried an experiment off adding the built tgz files to the azure build result. (https://dev.azure.com/Hyperledger/Fabric/_build/results?buildId=39099&view=artifacts&pathAsName=false&type=publishedArtifacts)

This was by adding a publish step (#241)

I've found that if you download those, then (at least the Linux one) works and is ok. Can't quite see how those are built differently to the release build?

from fabric-ca.

ah... I think I see the difference...

the release pipeline uses

      - job: Build
        pool:
          vmImage: ubuntu-16.04
        container: golang:$(GOVER)
        strategy:
          matrix:
            Linux-amd64:
              TARGET: linux-amd64
            MacOS-amd64:
              TARGET: darwin-amd64
            Windows-amd64:
              TARGET: windows-amd64
        steps:
          - checkout: self
            path: 'go/src/github.com/hyperledger/fabric-ca'
            displayName: Checkout Fabric CA Code
          - script: make dist/$(TARGET)
            displayName: Compile Binary and Create Tarball
          - publish: release/$(TARGET)/hyperledger-fabric-ca-$(TARGET)-$(RELEASE).tar.gz
            artifact: hyperledger-fabric-ca-$(TARGET)-$(RELEASE).tar.gz
            displayName: Publish Release Artifact

So runs the builds inside a container... whereas the 'verifybuild'.

  - template: install_deps.yml
  - checkout: self
    path: 'go/src/github.com/hyperledger/fabric-ca'
    displayName: Checkout Fabric CA Code
  - script: make dist-all checks all-tests docs
    displayName: Run Unit and Integration Tests
  - publish: 'release'
    displayName: 'built binaries'
    

Sticks with Ubuntu and install the dependencies and then does a make dist-all... is that the solution here to use the method in verifyBuild instead of the one in publishBuild

UPDATE: I modified the verifyBuild to work the same as the release build but captured the binary output in the build result (see https://dev.azure.com/Hyperledger/Fabric/_build/results?buildId=39292&view=artifacts&pathAsName=false&type=publishedArtifacts)

However.... the Linux amd64 image here, worked without issue.
So I went back and tried the 1.5.1 linux binary - and that worked.

So @denyeart @lindluni the Linux variant seems to be ok!

from fabric-ca.

I would expect the Linux variant to be okay, as the C compiler is available natively on the host it was built on. The Mac and Windows cross-compiled binaries I would expect to still be broken, as there is no Mac or Windows C cross-compiler available. I'm going back to do the build on native platforms

from fabric-ca.

thankyou @lindluni !

from fabric-ca.

curl -sSL https://bit.ly/2ysbOFE | bash -s -- 2.2.5 1.5.2 solved the issue

from fabric-ca.