This is cleanup for libtool. The option test_compile is not used in
libtool, and the documentation states that it would probably be dropped
in the future.
* build-aux/ltmain.in: Remove case statement for test_compile.
* doc/libtool.texi: Remove test_compile from documentation.
* m4/libtool.m4: Remove test_compile definition from macro file.
The -R and -L flags are currently checked if they have a space behind
them. -l should be added to the list of cases checked.
* m4/libtool.m4: Check for a space after the -l flag.
These should have been included in the commits that updated these
files, but too late now to rewrite git history.
* m4/libtool.m4: Update serial number.
* m4/ltdl.m4, m4/ltoptions.m4: Likewise.
If $CC has --sysroot=/, it is a valid configuration however libtool will
then set lt_sysroot to "/".
This means references like $lt_sysroot$libdir become //usr/lib instead
of the more normally expected /usr/lib. This may or may not break something
but certainly is confusing to the user and gives confusing output. Making
"/" simply unset lt_sysroot is much cleaner.
Whilst here, trim any trailing '/' from sysroot paths to drop the duplication
and result in cleaner/consistent output.
* m4/libtool.m4: Cleanup sysroot trailing '/' handling.
mingw uses msvcrt as it's standard library and does not use libm.
So in LT_LIB_M it can be added to the list of systems which do not
require libm.
* libtool.m4: Add mingw to the list of systems not requiring libm
The "From" should be "from" in the variable name.
Fixes libtool bug https://bugs.gnu.org/38305
* m4/libtool.m4: Change F to f in old_archive_from_new_cmds.
Trying to build clamav on Solaris 11.3 with the Oracle C compiler,
I got the following error:
libtool: error: not configured to extract global symbols from dlpreopened files
I would have expected a build to use dlopen rather than the preopen
fallback so looked for related configure tests that were perhaps
returning the wrong answer.
The global_symbol_pipe being empty seemed a likely culprit.
the last three lines of nm -p on the conftest.o in this test are:
0000000032 T main
0000000016 T nm_test_func
0000000001 C nm_test_var
On Solaris 10, I'd get a D instead of a C. Adding C to the list of
characters in the symcode variable and building again resulted in a
successful build. I've attached a patch to add this C.
Url: https://savannah.gnu.org/patch/?9086
* m4/libtool.m4 (symcode): Add C for solaris.
The -t flag was used as a performance hack for ranlib. The flag was
supported by the GNU toolchain, but is a no-op with the LLVM toolchain.
* m4/libtool.m4: Remove use of -t flag with ranlib.
Using `$CC -print-prog-name=ld` will always use the `ld` linker. We
should instead be using the $LD variable so that we use the proper
linker.
There is already another part of the code that does this same check,
so I just copy/pasted the if line.
* m4/libtool.m4: Change `$CC -print-prog-name=ld` to $LD.
Url: https://savannah.gnu.org/support/?110978
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
This avoids a deprecation warning with current versions of MSVC, by
replacing the -o flag with -Fe. -Fe is documented as supported at
least as far back as Visual C 6.0 which was released in 1998.
* m4/libtool.m4: Use -Fe instead of -o to specify DLL output filename
for MSVC.
Signed-off-by: Olly Betts <olly@survex.com>
If the compiler places a space between "-L" and the path, the path will
be skipped and only an empty "-L" will appear in the final
compiler_lib_search_path. This will cause the first library in postdeps
following compiler_lib_search_path to be accidentally skipped.
* libtool.m4: Fixed string comparison by adding missing 'x's.
This patch fixes two problems:
1) A libtool library created with the -release option and no -version-info
option was, when built with --enable-shared, installed without the
symlink libNAME.so -> libNAME-RELEASE.so. This led to subsequent failures
during "make install" of shared libraries that depend on it.
2) Executables were created without a RUNPATH property. These executables
then did not find their shared libraries when run.
* m4/libtool.m4: On Android, fix library_names_spec and
hardcode_libdir_flag_spec.
For reproducibility, stop encoding the hostname into the libtool script,
this isn't really adding much to debugging and most distros are carrying
such a patch now as reproducibility is important.
* m4/libtool.m4: Delete call to hostname & uname.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds support for flang compilers. Some specific flags
are needed so these compilers must be handled in a specific way.
By default, the compiler is called 'flang', but ARM releases their
own flang-based compiler called 'armflang'.
Because of the current lack of flang support in libtool, the
generated 'libtool' must be manually modified after 'configure' is
invoked. Such a process is for example described on ARM web site
(it involves the Open MPI library).
Url: https://savannah.gnu.org/patch/?9442
* m4/libtool.m4: Handle *flang.
This adds support for passing -m elf32_x86_64 vs -m elf_x86_64 to the
linker on hurd-amd64.
Url: https://savannah.gnu.org/patch/?10398
* m4/libtool.m4: dd x86_64-gnu* case to pass -m elf32_x86_64 vs
-m elf_x86_64 to linker.
The gnuconfig project recognizes windows* as a host OS to denote native
Windows environments. The commit message makes it sound like LLVM and
Crablang communities will use the 'windows' value, whereas GNU will
continue to use 'mingw'. But I think it's only a matter of time until
people start to pass the option --host=x86_64-pc-windows to configure
scripts. We should be prepared for that.
Url: https://savannah.gnu.org/patch/?10387
* build-aux/ltmain.in: Treat windows* as equivalent to mingw*.
* m4/libtool.m4: Likewise.
* m4/ltdl.m4: Likewise.
* m4/ltoptions.m4: Likewise.
* tests/bindir.at: Likewise.
* tests/deplibs-mingw.at: Likewise.
* tests/lt_dladvise.at: Likewise.
* tests/testsuite.at: Likewise.
GNU grep 3.8 warns about some regular expressions that POSIX says have
undefined effect, e.g., '\-'. Unfortunately Libtool uses regular
expressions of this form. Some unittests now fail, e.g. link-order.at:
--- /dev/null
+++ .../libtool/tests/testsuite.dir/at-groups/66/stderr
@@ -0,0 +1,4 @@
+/bin/grep: warning: stray \ before /
+/bin/grep: warning: stray \ before /
+/bin/grep: warning: stray \ before /
+/bin/grep: warning: stray \ before /
Url: https://savannah.gnu.org/patch/index.php?10282
* m4/libtool.m4 (_LT_LANG_CXX_CONFIG): Do not use \- in a BRE or ERE,
as this produces undefined results that GNU grep 3.8 warns about.
Use [-] instead.
* tests/link-order.at (Link order test): Similarly, do not use
\/ in an ERE; use / instead.
Fixes libtool bug https://bugs.gnu.org/67588.
Automate the process to avoid it falling stale again in the future,
and then refresh here to get in sync.
* cfg.mk: Add rule to update libtool.m4 release version.
* m4/libtool.m4: Update release year.
This fixes a warning when cross-building:
checking for arm-v7a-linux-gnueabihf-file... no
checking for file... file
configure: WARNING: using cross tools not prefixed with host triplet
file isn't platform specific and not usually installed with a host
triplet. So use AC_CHECK_PROG which differs from AC_CHECK_TOOL by not
expecting such a host triplet prefix.
* m4/libtool.m4 (_LT_DECL_FILECMD): Change AC_CHECK_TOOL to AC_CHECK_PROG.
* configure.ac: Update autoconf requirement for bootstrapping to 2.64.
* README.md: Update note concerning autoconf version requirement.
* bootstrap: Propogate change to GPL license from GPL 3 to GPL 2.
* m4/libtool.m4: bump serial version ( covers entire release ).
* m4/ltargz.m4: bump serial version ( covers entire release ).
Add AC_PROG_SED requirement to LT_FUNC_ARGZ.
* m4/ltdl.m4: bump serial version ( covers entire release ).
* build-aux/ltmain.in: replace raw invocations of sed with $SED
* m4/libtool.m4: replace raw invocations of sed with $SED
* m4/ltargz.m4: replace raw invocations of sed with $SED
* m4/ltdl.m4: replace raw invocations of sed with $SED
Co-authored-by: Alex Ameen <alex.ameen.tx@gmail.com>
Copyright-paperwork-exempt: Yes
* build-aux/ltmain.in: clone link-mode handling for MidnightBSD from FreeBSD
* m4/libtool.m4: clone various TAGVARs for MidnightBSD from FreeBSD
* m4/ltdl.m4: clone dlopen handling for MidnightBSD from FreeBSD
Copyright-paperwork-exempt: Yes
* build-aux/ltmain.sh: use '/usr/bin/env sh' in shebang
* libtoolize.in: use '/usr/bin/env sh' in shebang
* m4/libtool.m4: 'FILECMD' to replace use of '/usr/bin/file'
* gnulib: Update to the latest git version.
* gl-mod/bootstrap: Likewise.
* bootstrap: Regenerate.
* gl/top/README-release.diff: Update the patch for the latest
changes in gnulib's README-release.
A logical continuation of Automake commit
c40e27e1c2a60f58e72e65d73d808f782d55494a to provide
Windows ICC support similar as already done for MSVC.
Resolves bug 26484.
* m4/libtool.m4: Treat icl.exe equivalently to cl.exe.
Copyright-paperwork-exempt: Yes
References:
http://savannah.gnu.org/patch/?8675
Message-Id: <20150523-002056.sv85487.59958@savannah.gnu.org>
* m4/libtool.m4 (_LT_CMD_STRIPLIB): Remove the redundant tests for
empty $old_striplib and $striplib. Move the test for empty $STRIP
variable up. Allow elftoolchain strip (with the same arguments we
used to have with GNU strip) on FreeBSD.
TLS symbols in AIX display a new, different symbol type in nm output.
Libtool explicitly creates a list of exported symbols for AIX shared
libraries using nm and does not recognize the new TLS symbols, so
those symbols are not exported in AIX shared libraries.
This is a regression for TLS support on AIX where TLS symbols or GCC
"emultls" symbols were listed as global data and exported.
This patch updates libtool.m4 export_symbols_cmds for AIX in two
locations so that global symbols labeled with "L" for TLS are included
in the export list.
* m4/libtool.m4 (export_symbols_cmds) [AIX]: Add global TLS "L" symbols.
Message-Id: <CAGWvnym+hhoQJfkr=cncPZMnnMQ=RVUH2Bpw6+tP2hgEmESAsA@mail.gmail.com>
In some GNU/Linux distributions people started to compile 'ar'
binary with --enable-deterministic-archives (binutils project).
That, however, in combination with our previous long time working
default AR_FLAGS=cru causes warnings on such installations:
ar: `u' modifier ignored since `D' is the default (see `U')
The 'u' option (at least with GNU binutils) did small optimization
during repeated builds because it instructed 'ar' to not
open/close unchanged *.o files and to rather read their contents
from old archive file. However, its removal should not cause a
big performance hit for usual workflows.
Distributions started using --enable-deterministic-archives
knowing that it would disable the 'u', just to rather have a bit
more deterministic builds.
Also, to justify this change a bit more, keeping 'u' in ARFLAGS
could only result in many per-project changes to override
Libtool's ARFLAGS default, just to silent such warnings.
Fixes bug#19967. Reported by Eric Blake.
* m4/libtool.m4 (_LT_PROG_AR): Default AR_FLAGS to 'cr'.
(_LT_REQUIRED_DARWIN_CHECKS): Use $AR_FLAGS instead 'cru' string.
* doc/libtool.texi: Do 's/ar cru/ar cr/' in whole documentation.
* NEWS: Document.
Libtool has used $AR_FLAGS since 2000-05-29 commit
8300de4c54e6f04f0d, Automake ARFLAGS since 2003-04-06 commit
a71b3490639831ca. Even though ARFLAGS is younger, it sounds like
better name according GNU Coding Standards.
Related to bug#20082.
* m4/libtool.m4 (_LT_PROG_AR): Copy ARFLAGS value into AR_FLAGS
variable if AR_FLAGS is not set. Add new _LT_DECL'ed variable
'lt_ar_flags' to keep the configure-time value of AR_FLAGS. The
new 'lt_ar_flags' is to be used as the default value for AR_FLAGS
at libtool-runtime.
* NEWS: Document.
Libtool generator code needs to remember the configure time
LT_SYS_LIBRARY_PATH content to allow config.status properly
instantiate default LT_SYS_LIBRARY_PATH libtool run-time value;
Thats because config.status has no idea what the contents of
config.site file is (by default).
* m4/libtool.m4 (_LT_CONFIG): Use the _LT_DECLared
$configure_time_lt_sys_library_path variable as the default for
LT_SYS_DLSEARCH_PATH at run-time.
(_LT_SYS_DYNAMIC_LINKER): Don't change ac_cv_* variable if it is
not necessary. New $configure_time_lt_sys_library_path variable.
* NEWS: Update.
Signed-off-by: Gary V. Vaughan <gary@gnu.org>
