[PATCH] makefiles: support building shared libs on Darwin
by Caleb Xu
On Darwin (macOS), the flags needed to create a shared
library are different. Moreover, the extension is .dylib
and the version portion of the soname is inserted between
the library name and the libext, e.g. lifoo.1.2.3.dylib.
Signed-off-by: Caleb Xu <calebcenter(a)live.com>
---
makefiles/Makefile.clang | 7 ++++++-
makefiles/Makefile.gcc | 6 +++++-
makefiles/Makefile.tools | 6 +++++-
makefiles/Makefile.top | 14 +++++++++++---
4 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/makefiles/Makefile.clang b/makefiles/Makefile.clang
index 50f8a82..bcd14e3 100644
--- a/makefiles/Makefile.clang
+++ b/makefiles/Makefile.clang
@@ -21,7 +21,12 @@ CXXSHR := -fPIC
LDDBG := -g
# Reevaluation is required here
-LDSHR = -shared -Wl,-soname,$(SONAME)
+ifeq ($(findstring darwin,$(HOST)),darwin)
+ LDSHR = -dynamiclib -install_name $(SONAME)
+else
+ LDSHR = -shared -Wl,-soname,$(SONAME)
+endif
+
ARFLG := cru
diff --git a/makefiles/Makefile.gcc b/makefiles/Makefile.gcc
index b5119ac..4a9dff7 100644
--- a/makefiles/Makefile.gcc
+++ b/makefiles/Makefile.gcc
@@ -20,7 +20,11 @@ CXXSHR := -fPIC
LDDBG := -g
# Reevaluation is required here
-LDSHR = -shared -Wl,-soname,$(SONAME)
+ifeq ($(findstring darwin,$(HOST)),darwin)
+ LDSHR = -dynamiclib -install_name $(SONAME)
+else
+ LDSHR = -shared -Wl,-soname,$(SONAME)
+endif
ARFLG := cru
diff --git a/makefiles/Makefile.tools b/makefiles/Makefile.tools
index 112e7f8..e5504e7 100644
--- a/makefiles/Makefile.tools
+++ b/makefiles/Makefile.tools
@@ -478,7 +478,11 @@ LDFLAGS := $(LDFLAGS) $(OPTLDFLAGS)
ifeq ($(COMPONENT_TYPE),lib-static)
LIBEXT ?= .a
else
- LIBEXT ?= .so
+ ifeq ($(findstring darwin,$(HOST)),darwin)
+ LIBEXT ?= .dylib
+ else
+ LIBEXT ?= .so
+ endif
endif
# If we're building a shared library, modify the flags appropriately
diff --git a/makefiles/Makefile.top b/makefiles/Makefile.top
index caac166..0b0fe22 100644
--- a/makefiles/Makefile.top
+++ b/makefiles/Makefile.top
@@ -189,9 +189,17 @@ endif
# Determine the output filename
ifeq ($(findstring lib,$(COMPONENT_TYPE)),lib)
ifeq ($(findstring lib-shared,$(COMPONENT_TYPE)),lib-shared)
- SHAREDLIBNAME := lib$(COMPONENT)$(LIBEXT)
- SONAME := $(SHAREDLIBNAME).$(major-version)
- OUTPUT := $(BUILDDIR)/$(SHAREDLIBNAME).$(COMPONENT_VERSION)
+ ifeq ($(findstring darwin,$(HOST)),darwin)
+ # In macOS, shared lib filenames are of the form libfoo.dylib,
+ # libfoo.1.dylib, or libfoo.1.2.3.dylib
+ SONAME := lib$(COMPONENT).$(major-version)$(LIBEXT)
+ SHAREDLIBNAME := lib$(COMPONENT)$(LIBEXT)
+ OUTPUT := $(BUILDDIR)/lib$(COMPONENT).$(COMPONENT_VERSION)$(LIBEXT)
+ else
+ SHAREDLIBNAME := lib$(COMPONENT)$(LIBEXT)
+ SONAME := $(SHAREDLIBNAME).$(major-version)
+ OUTPUT := $(BUILDDIR)/$(SHAREDLIBNAME).$(COMPONENT_VERSION)
+ endif
else
OUTPUT := $(BUILDDIR)/lib$(COMPONENT)$(LIBEXT)
endif
--
2.41.0
2 months, 2 weeks
- 2
- 1
"error: ‘t.data.character.ptr’ may be used uninitialized " when building hubbub with gcc 11
by Andy Tai
Hi, I found from GNU Guix's build check that when building with gcc 11,
building hubbub would fail when building tests with errors like
COMPILE: test/tokeniser2.c
COMPILE: test/tokeniser3.c
COMPILE: test/tree.c
COMPILE: test/tree2.c
COMPILE: test/tree-buf.c
test/tokeniser2.c: In function ‘token_handler’:
test/tokeniser2.c:444:46: error: ‘t.data.character.ptr’ may be used
uninitialized [-Werror=maybe-uninitialized]
444 | t.data.character.ptr += len;
| ^~
test/tokeniser2.c:441:38: note: ‘t’ declared here
441 | hubbub_token t;
| ^
test/tokeniser2.c:445:46: error: ‘t.data.character.len’ may be used
uninitialized [-Werror=maybe-uninitialized]
445 | t.data.character.len -= len;
| ^~
...
I briefly took a look of the test source code in question and the
hubbub_token structs seem not explicitly initialized. Is this a real
warning from gcc of possibly uninitialized variable which can cause
the build to fail if allow warnings are treated as errors by gcc
during build (a common practice)? Thanks if maintainer can take a
look.
relevant bug entry and complete bug logs:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63526
2 months, 2 weeks
- 2
- 2
- ← Newer
- 1
- Older →