1
0
Fork 0
mirror of https://github.com/ruby/ruby.git synced 2022-11-09 12:17:21 -05:00
ruby--ruby/enc/Makefile.in

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

89 lines
2 KiB
Makefile
Raw Normal View History

V = 0
V0 = $(V:0=)
Q1 = $(V:1=)
Q = $(Q1:0=@)
ECHO1 = $(V:1=@@NULLCMD@)
ECHO = $(ECHO1:0=@echo)
encsrcdir = @srcdir@
topdir = .
prefix = @prefix@
exec_prefix = @exec_prefix@
libdir = @libdir@
top_srcdir = $(encsrcdir:/enc=)
srcdir = $(top_srcdir)
2020-04-04 14:57:05 -04:00
tooldir = $(top_srcdir)/tool
arch = @arch@
EXTOUT = @EXTOUT@
hdrdir = $(srcdir)/include
arch_hdrdir = $(EXTOUT)/include/$(arch)
ENCSODIR = $(EXTOUT)/$(arch)/enc
TRANSSODIR = $(ENCSODIR)/trans
DLEXT = @DLEXT@
OBJEXT = @OBJEXT@
LIBEXT = @LIBEXT@
Link ext bundles with bundle loader option for newer ld64 ld64 shipped with Xcode 14 emits a warning when using `-undefined dynamic_lookup`. ``` ld: warning: -undefined dynamic_lookup may not work with chained fixups ``` Actually, `-undefined dynamic_lookup` doesn't work when: 1. Link a *shared library* with the option 2. Link it with a program that uses the chained-fixup introduced from macOS 12 and iOS 15 because `-undefined dynamic_lookup` uses lazy-bindings and they won't be bound while dyld fixes-up by traversing chained-fixup info. However, we build exts as *bundles* and they are loaded only through `dlopen`, so it's safe to use `-undefined dynamic_lookup` in theory. So the warning produced by ld64 is false-positive, and it results failure of option checking in configuration. Therefore, it would be an option to ignore the warning during our configuration. On the other hand, `-undefined dynamic_lookup` is already deprecated on all darwin platforms except for macOS, so it's good time to get rid of the option. ld64 also provides `-bundle_loader <executable>` option, which allows to resolve symbols defined in the executable symtab while linking. It behaves almost the same with `-undefined dynamic_lookup`, but it makes the following changes: 1. Require that unresolved symbols among input objects must be defined in the executable. 2. Lazy symbol binding will lookup only the symtab of the bundle loader executable. (`-undefined dynamic_lookup` lookups all symtab as flat namespace) This patch adds `-bundle_loader $(RUBY)` when non-EXTSTATIC configuration by assuming ruby executable can be linked before building exts. See "New Features" subsection under "Linking" section for chained fixup https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-notes
2022-07-28 04:19:28 -04:00
EXEEXT = @EXEEXT@
TIMESTAMPDIR = $(EXTOUT)/.timestamp
ENC_TRANS_D = $(TIMESTAMPDIR)/.enc-trans.time
ENC_TRANS_SO_D = $(TIMESTAMPDIR)/.enc-trans.so.time
BUILTIN_ENCS = enc/ascii.c enc/us_ascii.c\
enc/unicode.c enc/utf_8.c
BUILTIN_TRANSES = enc/trans/newline.trans
RUBY_SO_NAME = @RUBY_SO_NAME@
LIBRUBY = @LIBRUBY@
LIBRUBYARG_SHARED = @LIBRUBYARG_SHARED@
LIBRUBYARG_STATIC = $(LIBRUBYARG_SHARED)
Link ext bundles with bundle loader option for newer ld64 ld64 shipped with Xcode 14 emits a warning when using `-undefined dynamic_lookup`. ``` ld: warning: -undefined dynamic_lookup may not work with chained fixups ``` Actually, `-undefined dynamic_lookup` doesn't work when: 1. Link a *shared library* with the option 2. Link it with a program that uses the chained-fixup introduced from macOS 12 and iOS 15 because `-undefined dynamic_lookup` uses lazy-bindings and they won't be bound while dyld fixes-up by traversing chained-fixup info. However, we build exts as *bundles* and they are loaded only through `dlopen`, so it's safe to use `-undefined dynamic_lookup` in theory. So the warning produced by ld64 is false-positive, and it results failure of option checking in configuration. Therefore, it would be an option to ignore the warning during our configuration. On the other hand, `-undefined dynamic_lookup` is already deprecated on all darwin platforms except for macOS, so it's good time to get rid of the option. ld64 also provides `-bundle_loader <executable>` option, which allows to resolve symbols defined in the executable symtab while linking. It behaves almost the same with `-undefined dynamic_lookup`, but it makes the following changes: 1. Require that unresolved symbols among input objects must be defined in the executable. 2. Lazy symbol binding will lookup only the symtab of the bundle loader executable. (`-undefined dynamic_lookup` lookups all symtab as flat namespace) This patch adds `-bundle_loader $(RUBY)` when non-EXTSTATIC configuration by assuming ruby executable can be linked before building exts. See "New Features" subsection under "Linking" section for chained fixup https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-notes
2022-07-28 04:19:28 -04:00
BUILTRUBY = $(topdir)/ruby$(EXEEXT)
empty =
AR = @AR@
CC = @CC@
ARFLAGS = @ARFLAGS@$(empty)
RANLIB = @RANLIB@
OUTFLAG = @OUTFLAG@$(empty)
COUTFLAG = @COUTFLAG@$(empty)
CFLAGS = $(CCDLFLAGS) @CFLAGS@ @ARCH_FLAG@
cflags = @cflags@
optflags = @optflags@
debugflags = @debugflags@
warnflags = @warnflags@
CCDLFLAGS = @CCDLFLAGS@
INCFLAGS = -I. -I$(arch_hdrdir) -I$(hdrdir) -I$(top_srcdir)
DEFS = @DEFS@
CPPFLAGS = @CPPFLAGS@ -DONIG_ENC_REGISTER=rb_enc_register
LDFLAGS = @LDFLAGS@
LDSHARED = @LDSHARED@
ldflags = $(LDFLAGS)
dldflags = @DLDFLAGS@
extdldflags = @EXTDLDFLAGS@
archflag = @ARCH_FLAG@
DLDFLAGS = $(ldflags) $(dldflags) $(extdldflags) $(archflag)
RUBY = $(MINIRUBY)
TARGET_NAME_ = $(@F) # BSD make seems unable to deal with @F with substitution
TARGET_NAME = $(TARGET_NAME_:.@DLEXT@=)
TARGET_ENTRY = @EXPORT_PREFIX@Init_$(TARGET_NAME)
WORKDIRS = @WORKDIRS@
NULLCMD = @NULLCMD@
RM = @RM@
RMDIR = @RMDIR@
RMDIRS = @RMDIRS@
MAKEDIRS = @MAKEDIRS@
.SUFFIXES: .trans
all:
make-workdir:
$(Q)$(MAKEDIRS) $(WORKDIRS)
clean:
distclean: clean
$(Q)$(RM) enc.mk
realclean: distclean clean-srcs