Run a full external link for CGO against musl when building in Docker

Signed-off-by: Josh Kneubuhl <jkneubuh@us.ibm.com>

.github/workflows/release.yml

@@ -12,7 +12,7 @@ env:
   GO_VER: 1.18.7
   ALPINE_VER: 3.16
   FABRIC_VER: ${{ github.ref_name }}
-  DOCKER_REGISTRY: docker.io    # or ghcr.io
+  DOCKER_REGISTRY: ghcr.io
 
 permissions:
   contents: read

Makefile

@@ -71,6 +71,10 @@ PROJECT_VERSION=$(FABRIC_VER)-snapshot-$(EXTRA_VERSION)
 TWO_DIGIT_VERSION = $(shell echo $(FABRIC_VER) | sed -e  's/^v\(.*\)/\1/' | cut -d '.' -f 1,2)
 
 PKGNAME = github.com/hyperledger/fabric
+
+# x86_64 or aarch64 in linux, amd64 or arm64 on darwin
+UNAME_ARCH=$(shell uname -m)
+# amd64 or arm64
 ARCH=$(shell go env GOARCH)
 MARCH=$(shell go env GOOS)-$(shell go env GOARCH)
 
@@ -224,7 +228,7 @@ tools: $(TOOLS_EXES)
 .PHONY: $(RELEASE_EXES)
 $(RELEASE_EXES): %: $(BUILD_DIR)/bin/%
 
-$(BUILD_DIR)/bin/%: GO_LDFLAGS = $(METADATA_VAR:%=-X $(PKGNAME)/common/metadata.%)
+$(BUILD_DIR)/bin/%: GO_LDFLAGS += $(METADATA_VAR:%=-X $(PKGNAME)/common/metadata.%)
 $(BUILD_DIR)/bin/%:
 	@echo "Building $@"
 	@mkdir -p $(@D)

images/orderer/Dockerfile

@@ -28,9 +28,12 @@ ARG GO_TAGS
 ARG FABRIC_VER
 ENV FABRIC_VER ${FABRIC_VER}
 
-# Disable cgo when building in the container.  This will create a static binary, which can be
-# copied and run in the base alpine container without the libc/musl runtime.
-ENV CGO_ENABLED 0
+# When building in docker, the binary must be linked statically with CGO against libmusl
+# in order to avoid SIGSEGV errors when running on alpine.
+# This uses the system CC compiler, which has been installed above with apk as musl-dev.
+#ENV CC         $(uname -m)-alpine-linux-musl-gcc
+ENV CGO_ENABLED 1
+ENV GO_LDFLAGS  -linkmode external -extldflags '-static'
 
 RUN make orderer GO_TAGS=${GO_TAGS}
 

images/peer/Dockerfile

@@ -27,9 +27,13 @@ ARG GO_TAGS
 ARG FABRIC_VER
 ENV FABRIC_VER ${FABRIC_VER}
 
-# Disable cgo when building in the container.  This will create a static binary, which can be
-# copied and run in the base alpine container without the libc/musl runtime.
-ENV CGO_ENABLED 0
+# When building in docker, the binary must be linked statically with CGO against libmusl
+# in order to avoid SIGSEGV errors when running on alpine.
+# This uses the system CC compiler, which has been installed above with apk as musl-dev.
+#ENV CC         $(uname -m)-alpine-linux-musl-gcc
+ENV CGO_ENABLED 1
+ENV GO_LDFLAGS  -linkmode external -extldflags '-static'
+
 
 RUN make peer GO_TAGS=${GO_TAGS}
 RUN make ccaasbuilder

images/tools/Dockerfile

@@ -22,9 +22,13 @@ ARG GO_TAGS
 ARG FABRIC_VER
 ENV FABRIC_VER ${FABRIC_VER}
 
-# Disable cgo when building in the container.  This will create a static binary, which can be
-# copied and run in the base alpine container without the libc/musl runtime.
-ENV CGO_ENABLED 0
+# When building in docker, the binary must be linked statically with CGO against libmusl
+# in order to avoid SIGSEGV errors when running on alpine.
+# This uses the system CC compiler, which has been installed above with apk as musl-dev.
+# CC=$(uname -m)-alpine-linux-musl-gcc
+#ENV CC         $(uname -m)-alpine-linux-musl-gcc
+ENV CGO_ENABLED 1
+ENV GO_LDFLAGS  -linkmode external -extldflags '-static'
 
 RUN make tools GO_TAGS=${GO_TAGS}
 

release_notes/v2.5.0-alpha3.md

@@ -0,0 +1,107 @@
+v2.5.0-alpha3 Release Notes - 16 Dec 2022 
+=================================
+
+
+Improvements
+------------
+
+- Prepares multi-arch Docker images for linux/arm64 and linux/amd64
+
+Fixes
+-----
+
+- Resolves SIGSEGV errors encountered with alpha1 release binaries
+- Resolves SIGSEGV errors running on alpine-based images on ARM64 
+- Resolves [Issue #3867](https://github.com/hyperledger/fabric/issues/3867)
+
+
+Dependencies
+------------
+Fabric v2.5.0-alpha2 has been tested with the following dependencies:
+* Go 1.18.7
+* CouchDB v3.1.1
+
+Fabric docker images on dockerhub utilize Alpine 3.16.
+
+
+Deprecations (existing)
+-----------------------
+
+**Ordering service system channel is deprecated**
+
+v2.3 introduced the ability to manage an ordering service without a system channel.
+Managing an ordering service without a system channel has privacy, scalability,
+and operational benefits. The use of a system channel is deprecated and may be removed in a future release.
+For information about removal of the system channel, see the [Create a channel without system channel documentation](https://hyperledger-fabric.readthedocs.io/en/release-2.3/create_channel/create_channel_participation.html).
+
+**FAB-15754: The 'Solo' consensus type is deprecated.**
+
+The 'Solo' consensus type has always been marked non-production and should be in
+use only in test environments; however, for compatibility it is still available,
+but may be removed entirely in a future release.
+
+**FAB-16408: The 'Kafka' consensus type is deprecated.**
+
+The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred
+production consensus type.  There is a documented and tested migration path from
+Kafka to Raft, and existing users should migrate to the newer Raft consensus type.
+For compatibility with existing deployments, Kafka is still supported,
+but may be removed entirely in a future release.
+Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published.
+
+**Fabric CouchDB image is deprecated**
+
+v2.2.0 added support for CouchDB 3.1.0 as the recommended and tested version of CouchDB.
+If prior versions are utilized, a Warning will appear in the peer log.
+Note that CouchDB 3.1.0 requires that an admin username and password be set,
+while this was optional in CouchDB v2.x. See the
+[Fabric CouchDB documentation](https://hyperledger-fabric.readthedocs.io/en/v2.2.0/couchdb_as_state_database.html#couchdb-configuration)
+for configuration details.
+Also note that CouchDB 3.1.0 default max_document_size is reduced to 8MB. Set a higher value if needed in your environment.
+Finally, the fabric-couchdb docker image will not be updated to v3.1.0 and will no longer be updated, maintained, or published.
+Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead.
+
+**FAB-7559: Support for specifying orderer endpoints at the global level in channel configuration is deprecated.**
+
+Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
+Configuring orderer endpoints at the organization level accommodates
+scenarios where orderers are run by different organizations. Using
+this configuration ensures that only the TLS CA certificates of that organization
+are used for orderer communications; in contrast to the global channel level endpoints which
+would cause an aggregation of all orderer TLS CA certificates across
+all orderer organizations to be used for orderer communications.
+
+**FAB-17428: Support for configtxgen flag `--outputAnchorPeersUpdate` is deprecated.**
+
+The `--outputAnchorPeersUpdate` mechanism for updating anchor peers has always had
+limitations (for instance, it only works the first time anchor peers are updated).
+Instead, anchor peer updates should be performed through channel configuration updates.
+
+**FAB-15406: The fabric-tools docker image is deprecated**
+
+The fabric-tools docker image will not be published in future Fabric releases.
+Instead of using the fabric-tools docker image, users should utilize the
+published Fabric binaries. The Fabric binaries can be used to make client calls
+to Fabric runtime components, regardless of where the Fabric components are running.
+
+**FAB-15317: Block dissemination via gossip is deprecated**
+
+Block dissemination via gossip is deprecated and may be removed in a future release.
+Fabric peers can be configured to receive blocks directly from an ordering service
+node, and not gossip blocks, by using the following configuration:
+```
+peer.gossip.orgLeader: true
+peer.gossip.useLeaderElection: false
+peer.gossip.state.enabled: false
+peer.deliveryclient.blockGossipEnabled: false
+```
+
+**FAB-15061: Legacy chaincode lifecycle is deprecated**
+
+The legacy chaincode lifecycle from v1.x is deprecated and will be removed
+in a future release. To prepare for the eventual removal, utilize the v2.x
+chaincode lifecycle instead, by enabling V2_0 application capability on all
+channels, and redeploying all chaincodes using the v2.x lifecycle. The new
+chaincode lifecycle provides a more flexible and robust governance model
+for chaincodes. For more details see the
+[documentation for enabling the new lifecycle](https://hyperledger-fabric.readthedocs.io/en/release-2.2/enable_cc_lifecycle.html).