[PATCH] libtool: remove bitrig support.
libtool: remove bitrig support. Bitrig has been defunct for 7 years. * build-aux/ltmain.in (func_mode_link): Remove bitrig support. * m4/libtool.m4 (_LT_CMD_OLD_ARCHIVE, LT_CMD_MAX_LEN) (_LT_SYS_DYNAMIC_LINKER, _LT_CHECK_MAGIC_METHOD) (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG): Ditto. * m4/ltdl.m4 (LT_SYS_DLOPEN_DEPLIBS): Ditto. * NEWS: Updated. --- NEWS| 3 +++ build-aux/ltmain.in | 4 ++-- m4/libtool.m4 | 14 +++--- m4/ltdl.m4 | 3 --- 4 files changed, 12 insertions(+), 12 deletions(-) diff --git a/NEWS b/NEWS index 93ade4df..79f135a2 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,9 @@ NEWS - list of user-visible changes between releases of GNU Libtool * Noteworthy changes in release ?.? (-??-??) [?] +** Changes in supported systems or compilers: + + - Removed support for bitrig. * Noteworthy changes in release 2.4.7 (2022-03-16) [stable] diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in index d5157a8d..d996f798 100644 --- a/build-aux/ltmain.in +++ b/build-aux/ltmain.in @@ -5134,7 +5134,7 @@ func_mode_link () # These systems don't actually have a C library (as such) test X-lc = "X$arg" && continue ;; - *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-bitrig* | *-*-midnightbsd*) + *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-midnightbsd*) # Do not include libc due to us having libc/libc_r. test X-lc = "X$arg" && continue ;; @@ -5154,7 +5154,7 @@ func_mode_link () esac elif test X-lc_r = "X$arg"; then case $host in -*-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-bitrig* | *-*-midnightbsd*) +*-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-midnightbsd*) # Do not include libc_r directly, use -pthread flag. continue ;; diff --git a/m4/libtool.m4 b/m4/libtool.m4 index 695ccac4..9b1a4d81 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -1556,7 +1556,7 @@ old_postuninstall_cmds= if test -n "$RANLIB"; then case $host_os in - bitrig* | openbsd*) + openbsd*) old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$tool_oldlib" ;; *) @@ -1724,7 +1724,7 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [dnl lt_cv_sys_max_cmd_len=8192; ;; - bitrig* | darwin* | dragonfly* | freebsd* | midnightbsd* | netbsd* | openbsd*) + darwin* | dragonfly* | freebsd* | midnightbsd* | netbsd* | openbsd*) # This has been around since 386BSD, at least. Likely further. if test -x /sbin/sysctl; then lt_cv_sys_max_cmd_len=`/sbin/sysctl -n kern.argmax` @@ -2943,7 +2943,7 @@ newsos6) dynamic_linker='ldqnx.so' ;; -openbsd* | bitrig*) +openbsd*) version_type=sunos sys_lib_dlsearch_path_spec=/usr/lib need_lib_prefix=no @@ -3583,7 +3583,7 @@ newos6*) lt_cv_deplibs_check_method=pass_all ;; -openbsd* | bitrig*) +openbsd*) if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`"; then lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so\.[[0-9]]+\.[[0-9]]+|\.so|_pic\.a)$' else @@ -5020,7 +5020,7 @@ dnl Note also adjust exclude_expsyms for C++ above. # we just hope/assume this is gcc and not c89 (= MSVC++ or ICC) with_gnu_ld=yes ;; - openbsd* | bitrig*) + openbsd*) with_gnu_ld=no ;; esac @@ -5842,7 +5842,7 @@ _LT_EOF *nto* | *qnx*) ;; -openbsd* | bitrig*) +openbsd*) if test -f /usr/libexec/ld.so; then _LT_TAGVAR(hardcode_direct, $1)=yes _LT_TAGVAR(hardcode_shlibpath_var, $1)=no @@ -7136,7 +7136,7 @@ if test yes != "$_lt_caught_CXX_error"; then _LT_TAGVAR(ld_shlibs, $1)=yes ;; - openbsd* | bitrig*) + openbsd*) if test -f /usr/libexec/ld.so; then _LT_TAGVAR(hardcode_direct, $1)=yes _LT_TAGVAR(hardcode_shlibpath_var, $1)=no diff --git a/m4/ltdl.m4 b/m4/ltdl.m4 index f631a00c..0c43799c 100644 --- a/m4/ltdl.m4 +++ b/m4/ltdl.m4 @@ -466,9 +466,6 @@ AC_CACHE_CHECK([whether deplibs are loaded by dlopen], ;; esac ;; - bitrig*) -lt_cv_sys_dlopen_deplibs=yes -;; darwin*) # Assuming the user has installed a libdl from somewhere, this is true # If you are looking for one http://www.opendarwin.org/projects/dlcompat -- 2.43.0
Re: [PATCH 05/12] ltmain.in: Don't encode RATHS which match default linker paths
On 25 Oct 2021 15:33, Richard Purdie wrote: > We don't want to add RPATHS which match default linker search paths, they're > a waste of space. This patch filters libtools list of paths to encoode and > removes the ones we don't need. how are you defining "linker" ? are you talking about the runtime linker (i.e. ld.so) or the build time linker (i.e. `ld`) ? the commit message also doesn't really explain in concrete details the scenario you're running into. -mike signature.asc Description: PGP signature
Re: [PATCH 02/12] libtool.m4: Rename the --with-sysroot option to avoid conflict with gcc/binutils
On 25 Oct 2021 15:33, Richard Purdie wrote: > This patch renames the --with-sysroot option to --with-libtool-sysroot > to avoid namespace conflict with binutils, gcc and other toolchain > components since these componets also add that option to configure > and this becomes confusing and conflicting otherwise. we're talking like 3 projects ? libtool is used & included in way more projects than that. it seems like --with-sysroot as a standard name to propagate out into the wider ecosystem makes more sense. i agree there's confusion between "use this path as a sysroot to compile and link against" and "have the compile tools target this sysroot". the same problem exists with host selection which is why we have the build, host, and target options. sounds like we want names that can align with these somehow. --with-libtool-sysroot doesn't make sense as it isn't an internal libtool setting, it's changing how executables are linked, and users (who run the configure scripts) don't know or care about this "libtool" thing. -mike signature.asc Description: PGP signature
Re: [PATCH 06/12] libtool.m4: Handle "/" as a sysroot correctly
On 25 Oct 2021 15:33, Richard Purdie wrote: > Update libtool.m4 to resolve a problem with lt_sysroot not being properly > updated if the option '--with[-libtool]-sysroot' is not provided when > running the 'configure' script for a package so that "/" as a sysroot > is handled correctly by libtool. this is a long sentence, and there's no concrete examples, so i'm having a bit of trouble extrapolating the bug. can you tweak this a bit to make it more clear ? -mike signature.asc Description: PGP signature
Re: [PATCH 11/12] ltmain.in: Handle prefix-map compiler options correctly
On 25 Oct 2021 15:33, Richard Purdie wrote: > + # -f*-prefix-map* needed for lto linking what flags are you trying to actually match here ? excessive globs make it more likely to match flags we don't want. -mike signature.asc Description: PGP signature
Re: [PATCH 00/12] Yocto Project libtool patch queue
there's a bunch of changes in here, but no additional test coverage also the project still requires ChangeLog entries in the commit message, so can you please add those so we don't have to write them for you ? if you look at commit history, the format should hopefully be obvious. -mike signature.asc Description: PGP signature
Re: [PATCH 07/12] libtool: Fix support for NIOS2 processor
On 25 Oct 2021 15:33, Richard Purdie wrote: > The name of the system contains the string "nios2". This string > is caught by the some of the greedy checks for OS/2 in libtool, > in particular the *os2* branches of switch statements match for > the nios2 string, which results in incorrect behavior of libtool. > > This patch adds an explicit check for *nios2* before the *os2* > checks to prevent the OS/2 check incorrectly trapping the nios2 > as well. i don't think this is the right approach. this is adding another substring search across the entire space (cpu/vendor/os). we should fix the search so it uses the right value only to match against. > --- a/build-aux/ltmain.in > +++ b/build-aux/ltmain.in > > case $host in > + # For NIOS2, we want to make sure that it's not caught by the > + # more general OS/2 check below. Otherwise, NIOS2 is the same > + # as the default option. > + *nios2*) > +opt_duplicate_compiler_generated_deps=$opt_preserve_dup_deps > +;; ># Solaris2 added to fix > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16452 ># see also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59788 >*cygwin* | *mingw* | *pw32* | *cegcc* | *solaris2* | *os2*) these should only match $host_os, and remove the leading glob at the same time. same for the other changes in this patch. -mike signature.asc Description: PGP signature
Re: [PATCH 1/2] libtool: replace : with $PATH_SEPARATOR
On 15 Jan 2024 21:15, KO Myung-Hun wrote: > Mike Frysinger wrote: > > On 15 Oct 2023 02:04, KO Myung-Hun wrote: > >> Some OSes such as OS/2, uses ';' as a path separator. So using > >> $PATH_SEPARATOR instead of hard-coded ':' is more proper. > >> > >> * build-aux-ltmain.in: replace : with $PATH_SEPARATOR. * > >> m4/libtool.m4: Likewise. > > > > this doesn't work for me > > > > 544675d6b538 2024-01-14 18:06:03 -0500 gnulib: update submodule to > > current versions > > > > $ ./bootstrap $ ./configure ... checking for mt... no checking if : > > is a manifest tool... no ./configure: 1: Syntax error: Unterminated > > quoted string $ -mike > > How about this? it passes configure, but fails `make check` & `make syntax-check`. -mike signature.asc Description: PGP signature
Re: [PATCH 1/2] libtool: replace : with $PATH_SEPARATOR
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
> On 15 Oct 2023 02:04, KO Myung-Hun wrote:
>> Some OSes such as OS/2, uses ';' as a path separator. So using
>> $PATH_SEPARATOR instead of hard-coded ':' is more proper.
>>
>> * build-aux-ltmain.in: replace : with $PATH_SEPARATOR. *
>> m4/libtool.m4: Likewise.
>
> this doesn't work for me
>
> 544675d6b538 2024-01-14 18:06:03 -0500 gnulib: update submodule to
> current versions
>
> $ ./bootstrap $ ./configure ... checking for mt... no checking if :
> is a manifest tool... no ./configure: 1: Syntax error: Unterminated
> quoted string $ -mike
How about this?
- --
KO Myung-Hun
Korean OS/2 User Community : https://www.os2.kr/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (OS/2)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFlpSHTE9YstvghgroRAhS0AJoDOLC7CqgIxDOIjauhO3TW0TGvbACghk6m
pHAtNYl5XnpC4Pptph8j3sE=
=kxUR
-END PGP SIGNATURE-
From 23812414244882e7a7dbe790de648318643e66e6 Mon Sep 17 00:00:00 2001
From: KO Myung-Hun
Date: Thu, 3 Nov 2022 23:32:37 +0900
Subject: [PATCH v2] libtool: replace : with $PATH_SEPARATOR
Some OSes such as OS/2, uses ';' as a path separator. So using
$PATH_SEPARATOR instead of hard-coded ':' is more proper.
* build-aux-ltmain.in: replace : with $PATH_SEPARATOR.
* m4/libtool.m4: Likewise.
---
build-aux/ltmain.in | 76 ++---
m4/libtool.m4 | 16 +-
2 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index d5157a8d..4ad97c40 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -733,8 +733,8 @@ func_resolve_sysroot ()
# store the result into func_replace_sysroot_result.
func_replace_sysroot ()
{
- case $lt_sysroot:$1 in
- ?*:"$lt_sysroot"*)
+ case "$lt_sysroot$PATH_SEPARATOR$1" in
+ ?*"$PATH_SEPARATOR$lt_sysroot"*)
func_stripname "$lt_sysroot" '' "$1"
func_replace_sysroot_result='='$func_stripname_result
;;
@@ -2007,7 +2007,7 @@ func_mode_execute ()
if eval "test -z \"\$$shlibpath_var\""; then
eval "$shlibpath_var=\"\$dir\""
else
- eval "$shlibpath_var=\"\$dir:\$$shlibpath_var\""
+ eval "$shlibpath_var=\"\$dir\$PATH_SEPARATOR\$$shlibpath_var\""
fi
done
@@ -3579,7 +3579,7 @@ func_exec_program ()
if test -n "$dllsearchpath"; then
$ECHO "\
# Add the dll search path components to the executable PATH
-PATH=$dllsearchpath:\$PATH
+PATH=\"$dllsearchpath$PATH_SEPARATOR\$PATH\"
"
fi
@@ -3591,7 +3591,7 @@ func_exec_program ()
# Some systems cannot cope with colon-terminated $shlibpath_var
# The second colon is a workaround for a bug in BeOS R4 sed
-$shlibpath_var=\`\$ECHO \"\$$shlibpath_var\" | $SED 's/::*\$//'\`
+$shlibpath_var=\`\$ECHO \"\$$shlibpath_var\" | $SED 's/$PATH_SEPARATOR$PATH_SEPARATOR*\$//'\`
export $shlibpath_var
"
@@ -3802,7 +3802,7 @@ EOF
fi
if test -n "$dllsearchpath"; then
- func_to_host_path "$dllsearchpath:"
+ func_to_host_path "$dllsearchpath$PATH_SEPARATOR"
cat <
Re: Armflang patch
Hi, yes, it is more complete. Thanks, Anthony On Sun, 2024-01-14 at 02:03 -0500, Mike Frysinger wrote: > i think this earlier patch is more complete: > https://savannah.gnu.org/patch/?9442 > -mike
