videolan
/
vlc
mirror of https://gitea.goldendeliverer.com/videolan/vlc.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
103300 Commits
7 Branches
132 Tags
718 MiB
Tree: 98441c0394
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '98441c0394'
${ noResults }
vlc/extras/tools/libtool-2.4.7-embed-bitcode...

42 lines
2.6 KiB
Raw Normal View History

extras/tools: bump libtool to 2.4.7 The -fsanitize support has been added upstream in the commit a5c6466528c060cc4660ad0319c00740db0e42ba which is shipped into 2.4.7.
4 years ago
From 019e9ec253a972fd5b0e3675140256b0982ec6f4 Mon Sep 17 00:00:00 2001
extras/tools: libtool: fix support for bitcode When building with bitcode enabled (*FLAGS+=-fembed-bitcode), the following happens: - with LDFLAGS += -fembed-bitcode, the vanilla libtool version will remove the -fembed-bitcode flag, being an unknown flag, so bitcode won't actually be enabled, and final link steps might complain that the dylibs (libvlccore.dylib for instance) doesn't actually have bitcode embedded. - once fixed (either by this patch or by using -Wl,-fembed-bitcode), the plugins will be compiled with -module, which default to using MH_BUNDLE on iOS/tvOS/MacOSX instead of MH_DYLIB. Indeed, dylibs can be dlopened only since MacOSX 10.3/10.4, and can be dlclosed only since MacOSX 10.5, so MH_BUNDLE was the primary target for libtool module support. However, MH_BUNDLE is not compatible with the bitcode support from Clang. Since we support MacOSX 10.11 as minimum, we can default to using MH_DYLIB for plugins to have the bitcode support. This new libtool patch add the explicit support for -fembed-bitcode in libtool --mode=link flags, and change the flags used when using -module in libtool to switch to dylibs.
5 years ago
From: Alexandre Janniaux <ajanni@videolabs.io>
Date: Mon, 31 May 2021 10:28:54 +0200
Subject: [PATCH] ltmain: add support for -fembed-bitcode
---
extras/tools: bump libtool to 2.4.7 The -fsanitize support has been added upstream in the commit a5c6466528c060cc4660ad0319c00740db0e42ba which is shipped into 2.4.7.
4 years ago
build-aux/ltmain.in | 1 +
extras/tools: libtool: fix support for bitcode When building with bitcode enabled (*FLAGS+=-fembed-bitcode), the following happens: - with LDFLAGS += -fembed-bitcode, the vanilla libtool version will remove the -fembed-bitcode flag, being an unknown flag, so bitcode won't actually be enabled, and final link steps might complain that the dylibs (libvlccore.dylib for instance) doesn't actually have bitcode embedded. - once fixed (either by this patch or by using -Wl,-fembed-bitcode), the plugins will be compiled with -module, which default to using MH_BUNDLE on iOS/tvOS/MacOSX instead of MH_DYLIB. Indeed, dylibs can be dlopened only since MacOSX 10.3/10.4, and can be dlclosed only since MacOSX 10.5, so MH_BUNDLE was the primary target for libtool module support. However, MH_BUNDLE is not compatible with the bitcode support from Clang. Since we support MacOSX 10.11 as minimum, we can default to using MH_DYLIB for plugins to have the bitcode support. This new libtool patch add the explicit support for -fembed-bitcode in libtool --mode=link flags, and change the flags used when using -module in libtool to switch to dylibs.
5 years ago
m4/libtool.m4 | 4 ++--
extras/tools: bump libtool to 2.4.7 The -fsanitize support has been added upstream in the commit a5c6466528c060cc4660ad0319c00740db0e42ba which is shipped into 2.4.7.
4 years ago
2 files changed, 3 insertions(+), 2 deletions(-)
extras/tools: libtool: fix support for bitcode When building with bitcode enabled (*FLAGS+=-fembed-bitcode), the following happens: - with LDFLAGS += -fembed-bitcode, the vanilla libtool version will remove the -fembed-bitcode flag, being an unknown flag, so bitcode won't actually be enabled, and final link steps might complain that the dylibs (libvlccore.dylib for instance) doesn't actually have bitcode embedded. - once fixed (either by this patch or by using -Wl,-fembed-bitcode), the plugins will be compiled with -module, which default to using MH_BUNDLE on iOS/tvOS/MacOSX instead of MH_DYLIB. Indeed, dylibs can be dlopened only since MacOSX 10.3/10.4, and can be dlclosed only since MacOSX 10.5, so MH_BUNDLE was the primary target for libtool module support. However, MH_BUNDLE is not compatible with the bitcode support from Clang. Since we support MacOSX 10.11 as minimum, we can default to using MH_DYLIB for plugins to have the bitcode support. This new libtool patch add the explicit support for -fembed-bitcode in libtool --mode=link flags, and change the flags used when using -module in libtool to switch to dylibs.
5 years ago
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
extras/tools: bump libtool to 2.4.7 The -fsanitize support has been added upstream in the commit a5c6466528c060cc4660ad0319c00740db0e42ba which is shipped into 2.4.7.
4 years ago
index 8ef537c1..d8131598 100644
extras/tools: libtool: fix support for bitcode When building with bitcode enabled (*FLAGS+=-fembed-bitcode), the following happens: - with LDFLAGS += -fembed-bitcode, the vanilla libtool version will remove the -fembed-bitcode flag, being an unknown flag, so bitcode won't actually be enabled, and final link steps might complain that the dylibs (libvlccore.dylib for instance) doesn't actually have bitcode embedded. - once fixed (either by this patch or by using -Wl,-fembed-bitcode), the plugins will be compiled with -module, which default to using MH_BUNDLE on iOS/tvOS/MacOSX instead of MH_DYLIB. Indeed, dylibs can be dlopened only since MacOSX 10.3/10.4, and can be dlclosed only since MacOSX 10.5, so MH_BUNDLE was the primary target for libtool module support. However, MH_BUNDLE is not compatible with the bitcode support from Clang. Since we support MacOSX 10.11 as minimum, we can default to using MH_DYLIB for plugins to have the bitcode support. This new libtool patch add the explicit support for -fembed-bitcode in libtool --mode=link flags, and change the flags used when using -module in libtool to switch to dylibs.
5 years ago
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
extras/tools: bump libtool to 2.4.7 The -fsanitize support has been added upstream in the commit a5c6466528c060cc4660ad0319c00740db0e42ba which is shipped into 2.4.7.
4 years ago
@@ -5197,6 +5197,7 @@ func_mode_link ()
extras/tools: libtool: fix support for bitcode When building with bitcode enabled (*FLAGS+=-fembed-bitcode), the following happens: - with LDFLAGS += -fembed-bitcode, the vanilla libtool version will remove the -fembed-bitcode flag, being an unknown flag, so bitcode won't actually be enabled, and final link steps might complain that the dylibs (libvlccore.dylib for instance) doesn't actually have bitcode embedded. - once fixed (either by this patch or by using -Wl,-fembed-bitcode), the plugins will be compiled with -module, which default to using MH_BUNDLE on iOS/tvOS/MacOSX instead of MH_DYLIB. Indeed, dylibs can be dlopened only since MacOSX 10.3/10.4, and can be dlclosed only since MacOSX 10.5, so MH_BUNDLE was the primary target for libtool module support. However, MH_BUNDLE is not compatible with the bitcode support from Clang. Since we support MacOSX 10.11 as minimum, we can default to using MH_DYLIB for plugins to have the bitcode support. This new libtool patch add the explicit support for -fembed-bitcode in libtool --mode=link flags, and change the flags used when using -module in libtool to switch to dylibs.
5 years ago
continue
;;
extras/tools: bump libtool to 2.4.7 The -fsanitize support has been added upstream in the commit a5c6466528c060cc4660ad0319c00740db0e42ba which is shipped into 2.4.7.
4 years ago
-mt|-mthreads|-kthread|-Kthread|-pthreads|--thread-safe \
+ |-fembed-bitcode|-fembed-bitcode-marker \
extras/tools: libtool: fix support for bitcode When building with bitcode enabled (*FLAGS+=-fembed-bitcode), the following happens: - with LDFLAGS += -fembed-bitcode, the vanilla libtool version will remove the -fembed-bitcode flag, being an unknown flag, so bitcode won't actually be enabled, and final link steps might complain that the dylibs (libvlccore.dylib for instance) doesn't actually have bitcode embedded. - once fixed (either by this patch or by using -Wl,-fembed-bitcode), the plugins will be compiled with -module, which default to using MH_BUNDLE on iOS/tvOS/MacOSX instead of MH_DYLIB. Indeed, dylibs can be dlopened only since MacOSX 10.3/10.4, and can be dlclosed only since MacOSX 10.5, so MH_BUNDLE was the primary target for libtool module support. However, MH_BUNDLE is not compatible with the bitcode support from Clang. Since we support MacOSX 10.11 as minimum, we can default to using MH_DYLIB for plugins to have the bitcode support. This new libtool patch add the explicit support for -fembed-bitcode in libtool --mode=link flags, and change the flags used when using -module in libtool to switch to dylibs.
5 years ago
|-threads|-fopenmp|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
extras/tools: bump libtool to 2.4.7 The -fsanitize support has been added upstream in the commit a5c6466528c060cc4660ad0319c00740db0e42ba which is shipped into 2.4.7.
4 years ago
func_append compiler_flags " $arg"
func_append compile_command " $arg"
extras/tools: libtool: fix support for bitcode When building with bitcode enabled (*FLAGS+=-fembed-bitcode), the following happens: - with LDFLAGS += -fembed-bitcode, the vanilla libtool version will remove the -fembed-bitcode flag, being an unknown flag, so bitcode won't actually be enabled, and final link steps might complain that the dylibs (libvlccore.dylib for instance) doesn't actually have bitcode embedded. - once fixed (either by this patch or by using -Wl,-fembed-bitcode), the plugins will be compiled with -module, which default to using MH_BUNDLE on iOS/tvOS/MacOSX instead of MH_DYLIB. Indeed, dylibs can be dlopened only since MacOSX 10.3/10.4, and can be dlclosed only since MacOSX 10.5, so MH_BUNDLE was the primary target for libtool module support. However, MH_BUNDLE is not compatible with the bitcode support from Clang. Since we support MacOSX 10.11 as minimum, we can default to using MH_DYLIB for plugins to have the bitcode support. This new libtool patch add the explicit support for -fembed-bitcode in libtool --mode=link flags, and change the flags used when using -module in libtool to switch to dylibs.
5 years ago
diff --git a/m4/libtool.m4 b/m4/libtool.m4
extras/tools: bump libtool to 2.4.7 The -fsanitize support has been added upstream in the commit a5c6466528c060cc4660ad0319c00740db0e42ba which is shipped into 2.4.7.
4 years ago
index 69cd577d..da0eec54 100644
extras/tools: libtool: fix support for bitcode When building with bitcode enabled (*FLAGS+=-fembed-bitcode), the following happens: - with LDFLAGS += -fembed-bitcode, the vanilla libtool version will remove the -fembed-bitcode flag, being an unknown flag, so bitcode won't actually be enabled, and final link steps might complain that the dylibs (libvlccore.dylib for instance) doesn't actually have bitcode embedded. - once fixed (either by this patch or by using -Wl,-fembed-bitcode), the plugins will be compiled with -module, which default to using MH_BUNDLE on iOS/tvOS/MacOSX instead of MH_DYLIB. Indeed, dylibs can be dlopened only since MacOSX 10.3/10.4, and can be dlclosed only since MacOSX 10.5, so MH_BUNDLE was the primary target for libtool module support. However, MH_BUNDLE is not compatible with the bitcode support from Clang. Since we support MacOSX 10.11 as minimum, we can default to using MH_DYLIB for plugins to have the bitcode support. This new libtool patch add the explicit support for -fembed-bitcode in libtool --mode=link flags, and change the flags used when using -module in libtool to switch to dylibs.
5 years ago
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
extras/tools: bump libtool to 2.4.7 The -fsanitize support has been added upstream in the commit a5c6466528c060cc4660ad0319c00740db0e42ba which is shipped into 2.4.7.
4 years ago
@@ -1122,9 +1122,9 @@ m4_defun([_LT_DARWIN_LINKER_FEATURES],
extras/tools: libtool: fix support for bitcode When building with bitcode enabled (*FLAGS+=-fembed-bitcode), the following happens: - with LDFLAGS += -fembed-bitcode, the vanilla libtool version will remove the -fembed-bitcode flag, being an unknown flag, so bitcode won't actually be enabled, and final link steps might complain that the dylibs (libvlccore.dylib for instance) doesn't actually have bitcode embedded. - once fixed (either by this patch or by using -Wl,-fembed-bitcode), the plugins will be compiled with -module, which default to using MH_BUNDLE on iOS/tvOS/MacOSX instead of MH_DYLIB. Indeed, dylibs can be dlopened only since MacOSX 10.3/10.4, and can be dlclosed only since MacOSX 10.5, so MH_BUNDLE was the primary target for libtool module support. However, MH_BUNDLE is not compatible with the bitcode support from Clang. Since we support MacOSX 10.11 as minimum, we can default to using MH_DYLIB for plugins to have the bitcode support. This new libtool patch add the explicit support for -fembed-bitcode in libtool --mode=link flags, and change the flags used when using -module in libtool to switch to dylibs.
5 years ago
if test yes = "$_lt_dar_can_shared"; then
output_verbose_link_cmd=func_echo_all
_LT_TAGVAR(archive_cmds, $1)="\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring $_lt_dar_single_mod$_lt_dsymutil"
- _LT_TAGVAR(module_cmds, $1)="\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags$_lt_dsymutil"
+ _LT_TAGVAR(module_cmds, $1)="\$CC \$allow_undefined_flag -o \$lib -dynamiclib \$libobjs \$deplibs \$compiler_flags$_lt_dsymutil"
extras/tools: bump libtool to 2.4.7 The -fsanitize support has been added upstream in the commit a5c6466528c060cc4660ad0319c00740db0e42ba which is shipped into 2.4.7.
4 years ago
_LT_TAGVAR(archive_expsym_cmds, $1)="$SED 's|^|_|' < \$export_symbols > \$output_objdir/\$libname-symbols.expsym~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring $_lt_dar_single_mod$_lt_dar_export_syms$_lt_dsymutil"
- _LT_TAGVAR(module_expsym_cmds, $1)="$SED -e 's|^|_|' < \$export_symbols > \$output_objdir/\$libname-symbols.expsym~\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags$_lt_dar_export_syms$_lt_dsymutil"
+ _LT_TAGVAR(module_expsym_cmds, $1)="$SED -e 's|^|_|' < \$export_symbols > \$output_objdir/\$libname-symbols.expsym~\$CC \$allow_undefined_flag -o \$lib -dynamiclib \$libobjs \$deplibs \$compiler_flags$_lt_dar_export_syms$_lt_dsymutil"
extras/tools: libtool: fix support for bitcode When building with bitcode enabled (*FLAGS+=-fembed-bitcode), the following happens: - with LDFLAGS += -fembed-bitcode, the vanilla libtool version will remove the -fembed-bitcode flag, being an unknown flag, so bitcode won't actually be enabled, and final link steps might complain that the dylibs (libvlccore.dylib for instance) doesn't actually have bitcode embedded. - once fixed (either by this patch or by using -Wl,-fembed-bitcode), the plugins will be compiled with -module, which default to using MH_BUNDLE on iOS/tvOS/MacOSX instead of MH_DYLIB. Indeed, dylibs can be dlopened only since MacOSX 10.3/10.4, and can be dlclosed only since MacOSX 10.5, so MH_BUNDLE was the primary target for libtool module support. However, MH_BUNDLE is not compatible with the bitcode support from Clang. Since we support MacOSX 10.11 as minimum, we can default to using MH_DYLIB for plugins to have the bitcode support. This new libtool patch add the explicit support for -fembed-bitcode in libtool --mode=link flags, and change the flags used when using -module in libtool to switch to dylibs.
5 years ago
m4_if([$1], [CXX],
[ if test yes != "$lt_cv_apple_cc_single_mod"; then
_LT_TAGVAR(archive_cmds, $1)="\$CC -r -keep_private_externs -nostdlib -o \$lib-master.o \$libobjs~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$lib-master.o \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring$_lt_dsymutil"
extras/tools: bump libtool to 2.4.7 The -fsanitize support has been added upstream in the commit a5c6466528c060cc4660ad0319c00740db0e42ba which is shipped into 2.4.7.
4 years ago
--
2.36.0