Re: [PATCH] Allow -Werror and -Werror=* through flag filtering

[Alex Ameen]

Merged. Thank you for your contribution.

https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=1ec8fa28dcb29500d485c136db28315671ec4c3b

On 12/9/22 20:33, Sam James wrote:

* build-aux/ltmain.in (func_mode_link): allow -Werror and -Werror=* through
   flat filtering at link time.

   This is needed for detecting likely-runtime problems with LTO using
   e.g. -Werror=odr or -Werror=lto-type-mismatch.

Bug: https://bugs.gentoo.org/884767
Signed-off-by: Sam James 
---
  build-aux/ltmain.in | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index a5f21a1d..3b76bd08 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5408,10 +5408,11 @@ func_mode_link ()
# -fsanitize=* Clang/GCC memory and address sanitizer
# -fuse-ld=*   Linker select flags for GCC
# -Wa,*Pass flags directly to the assembler
+  # -Werror, -Werror=*   Report (specified) warnings as errors
-64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \

-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \

-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
-  -specs=*|-fsanitize=*|-fuse-ld=*|-Wa,*)
+  -specs=*|-fsanitize=*|-fuse-ld=*|-Wa,*|-Werror|-Werror=*)
  func_quote_arg pretty "$arg"
arg=$func_quote_arg_result
  func_append compile_command " $arg"

Re: [PATCH] Allow -Werror and -Werror=* through flag filtering

[Alex Ameen]

Thanks I'll take this for a spin and keep you in the loop.

On 12/9/22 20:33, Sam James wrote:

* build-aux/ltmain.in (func_mode_link): allow -Werror and -Werror=* through
   flat filtering at link time.

   This is needed for detecting likely-runtime problems with LTO using
   e.g. -Werror=odr or -Werror=lto-type-mismatch.

Bug: https://bugs.gentoo.org/884767
Signed-off-by: Sam James 
---
  build-aux/ltmain.in | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index a5f21a1d..3b76bd08 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5408,10 +5408,11 @@ func_mode_link ()
# -fsanitize=* Clang/GCC memory and address sanitizer
# -fuse-ld=*   Linker select flags for GCC
# -Wa,*Pass flags directly to the assembler
+  # -Werror, -Werror=*   Report (specified) warnings as errors
-64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \

-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \

-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
-  -specs=*|-fsanitize=*|-fuse-ld=*|-Wa,*)
+  -specs=*|-fsanitize=*|-fuse-ld=*|-Wa,*|-Werror|-Werror=*)
  func_quote_arg pretty "$arg"
arg=$func_quote_arg_result
  func_append compile_command " $arg"

Re: [PATCH v2 00/12] Rebased version of Yocto patches

[Alex Ameen]

Apologies for being unreachable, I'll revisit these today.


On Sun, Nov 20, 2022 at 5:30 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Sat, 2022-11-19 at 18:32 +, Sam James wrote:
> >
> > > On 16 Apr 2022, at 18:58, Sam James  wrote:
> > >
> > > Done after discussion w/ Alex (thanks!). Rebased on master after
> > > 2.4.7 release.
> >
> > Ping. Could we maybe get the easy ones in and then revisit
> > the bits which received comments (unclear to me what we need
> > to do for those)?
>
> I'd second that, I'd love to get the easy ones sorted and am happy to
> try and help with the others, just not quite sure where we stand at the
> moment.
>
> Cheers,
>
> Richard
>


-- 
Alex Ameen
Tel: (832) 341-9270

[patch #10282] port libtool to grep 3.8 and to POSIX

[Alex Ameen]

Follow-up Comment #2, patch #10282 (project libtool):

Thanks for the report and patch. 

Did you test to see if the new pattern still works with `grep` < 3.8 by any
chance?

Just to check my understanding here: the intention of `[[-]]L` is to escape
`"[-]L"` in M4, taking advantage of the old `grep "[-]-not-an-option";` trick
to force grep to recognize argument 1 as a pattern rather than a flag? This
one makes sense to me. 

The one I didn't totally understand was removing the `@<:@` handler; mostly
because I don't remember the context off hand. 




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [PATCH] Further update/simplify OpenBSD support

[Alex Ameen]

   ok

< 151: convenience libltdl ok

---


148: installable libltdl expected failure 
(configure-iface.at:145)



149: --with-ltdl-include/lib expected failure 
(configure-iface.at:179)



150: --with-included-ltdl    expected failure 
(configure-iface.at:283)



151: convenience libltdl expected failure 
(configure-iface.at:322)


249c249

< 161: darwin ld warnings changing configure results   ok

---


161: darwin ld warnings changing configure results   expected failure 
(darwin.at:226)


273c273

< 8 failed (4 expected failures).

---


67 failed (58 expected failures).


282c282

<    Subject: [GNU Libtool 2.4.7.3-61320-dirty] testsuite: 67 96 143 169 failed

---


    Subject: [GNU Libtool 2.4.7.4-b9a3-dirty] testsuite: 67 96 122 123 124 125 
129 143 169 failed


289c289

< make[3]: Leaving directory '/private/tmp/libtool-base'

---


make[3]: Leaving directory '/private/tmp/libtool'


291c291

< make[2]: Leaving directory '/private/tmp/libtool-base'

---


make[2]: Leaving directory '/private/tmp/libtool'


293c293

< make[1]: Leaving directory '/private/tmp/libtool-base'

---


make[1]: Leaving directory '/private/tmp/libtool'




On 8/21/22 17:52, Alex Ameen wrote:

Yeah I didn't get time to work on it until today.

I've applied the patch and ran the test suite through my usual VMs; 
I'm setting up a fresh VM now with OpenBSD's utilities for a "more 
useful" test run but everything looks good so far.


On 8/20/22 14:51, Brad Smith wrote:

On 8/15/2022 10:47 AM, Alex Ameen wrote:
Thanks for your submission. I'll run it through the test suite this 
week and keep you posted.


Any update on this?  GEN  public-submodule-commit
make  check-recursive
make[1]: Entering directory '/private/tmp/libtool-base'
Making check in .
make[2]: Entering directory '/private/tmp/libtool-base'
make  check-local
make[3]: Entering directory '/private/tmp/libtool-base'
## --- ##
## GNU Libtool 2.4.7.3-61320-dirty test suite. ##
## --- ##

Functions shared with configure and libtool.

  1: func_munge_path_list works  ok

Libtoolize operation.

  2: libtoolize macro installation   ok
  3: libtoolize macro directory mismatch error   ok
  4: multiple AC_CONFIG_MACRO_DIRS invocationok
  5: multiple AC_CONFIG_MACRO_DIRS directories   ok
  6: libtoolize ACLOCAL_AMFLAGS extraction   ok
  7: libtoolize macro serial update  ok
  8: libtoolize config files serial update   ok
  9: diagnose missing LT_CONFIG_LTDL_DIR ok
 10: copy ltdl.m4 with shared macro directoryok
 11: correctly parse LTDL_INIT from configure.ac ok
 12: diagnose missing LTDL_INIT invocation   ok
 13: upgrading verbatim style aclocal.m4 ok
 14: verbatim aclocal.m4 w/o AC_CONFIG_MACRO_DIRSok
 15: nonrecursive ltdl with AC_CONFIG_MACRO_DIRS ok
 16: subproject ltdl with unconventional layout  ok
 17: Subproject ltdl without GNU M4  ok
 18: LIBTOOLIZE_OPTIONS  ok
 19: cleanup old installationok

Basic libtool operation.

 20: check help output   ok
 21: diagnose no mode specified  ok
 22: quote shell meta-characters in filenamesok
 23: transform source suffices   ok
 24: check link mode operation   ok
 25: check objectlist file operation ok
 26: test LT_SUPPORTED_TAG interface ok

Linking and loading.

 27: link against a preloaded static library ok
 28: build and dynamically load a module ok
 29: preload static and dynamic module   ok
 30: deplibs_check_methodok
 31: disable fast installok
 32: force PIC objects   ok
 33: force non-PIC objects   ok
 34: hardcoding library path ok
 35: binary relinking at install timeok
 36: uninstalled libraries have priority ok
 37: linking with long file namesok
 38: override pic_flag at configure time ok
 39: test --with-pic skipped (with-pic.at:40)

Convenience libraries.

 40: build and link against a static library ok
 41: build and link against a dynamic libraryok
 42: build both static and dynamic   ok
 43: allow_undefined_flagok
 44: C convenience archives  ok
 45: C++ convenience a

Re: [PATCH] Further update/simplify OpenBSD support

[Alex Ameen]

Yeah I didn't get time to work on it until today.

I've applied the patch and ran the test suite through my usual VMs; I'm 
setting up a fresh VM now with OpenBSD's utilities for a "more useful" 
test run but everything looks good so far.


On 8/20/22 14:51, Brad Smith wrote:

On 8/15/2022 10:47 AM, Alex Ameen wrote:
Thanks for your submission. I'll run it through the test suite this 
week and keep you posted.


Any update on this?

Re: [PATCH] Further update/simplify OpenBSD support

[Alex Ameen]

Thanks for your submission. I'll run it through the test suite this week
and keep you posted.

On Sat, Aug 13, 2022, 5:06 PM Brad Smith  wrote:

> Further update/simplify OpenBSD support
>
> * m4/libtool.m4: Remove long obsolete support for a.out and support
> for archs not supporting shared libaries
> ---
>  m4/libtool.m4 | 61 ---
>  1 file changed, 19 insertions(+), 42 deletions(-)
>
> diff --git a/m4/libtool.m4 b/m4/libtool.m4
> index 79a2451e..fa424ec6 100644
> --- a/m4/libtool.m4
> +++ b/m4/libtool.m4
> @@ -1557,7 +1557,7 @@ old_postuninstall_cmds=
>
>  if test -n "$RANLIB"; then
>case $host_os in
> -  bitrig* | openbsd*)
> +  bitrig*)
>  old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$tool_oldlib"
>  ;;
>*)
> @@ -2948,11 +2948,7 @@ openbsd* | bitrig*)
>version_type=sunos
>sys_lib_dlsearch_path_spec=/usr/lib
>need_lib_prefix=no
> -  if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`"; then
> -need_version=no
> -  else
> -need_version=yes
> -  fi
> +  need_version=no
>library_names_spec='$libname$release$shared_ext$versuffix
> $libname$shared_ext$versuffix'
>finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
>shlibpath_var=LD_LIBRARY_PATH
> @@ -3585,11 +3581,7 @@ newos6*)
>;;
>
>  openbsd* | bitrig*)
> -  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
> -lt_cv_deplibs_check_method='match_pattern
> /lib[[^/]]+(\.so\.[[0-9]]+\.[[0-9]]+|_pic\.a)$'
> -  fi
> +  lt_cv_deplibs_check_method='match_pattern
> /lib[[^/]]+(\.so\.[[0-9]]+\.[[0-9]]+|\.so|_pic\.a)$'
>;;
>
>  osf3* | osf4* | osf5*)
> @@ -5838,22 +5830,13 @@ _LT_EOF
>;;
>
>  openbsd* | bitrig*)
> -  if test -f /usr/libexec/ld.so; then
> -   _LT_TAGVAR(hardcode_direct, $1)=yes
> -   _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
> -   _LT_TAGVAR(hardcode_direct_absolute, $1)=yes
> -   if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`"; then
> - _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib
> $libobjs $deplibs $compiler_flags'
> - _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag -o
> $lib $libobjs $deplibs $compiler_flags
> $wl-retain-symbols-file,$export_symbols'
> - _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath,$libdir'
> - _LT_TAGVAR(export_dynamic_flag_spec, $1)='$wl-E'
> -   else
> - _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib
> $libobjs $deplibs $compiler_flags'
> - _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath,$libdir'
> -   fi
> -  else
> -   _LT_TAGVAR(ld_shlibs, $1)=no
> -  fi
> +  _LT_TAGVAR(hardcode_direct, $1)=yes
> +  _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
> +  _LT_TAGVAR(hardcode_direct_absolute, $1)=yes
> +  _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib
> $libobjs $deplibs $compiler_flags'
> +  _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag -o $lib
> $libobjs $deplibs $compiler_flags $wl-retain-symbols-file,$export_symbols'
> +  _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath,$libdir'
> +  _LT_TAGVAR(export_dynamic_flag_spec, $1)='$wl--export-dynamic'
>;;
>
>  os2*)
> @@ -7132,21 +7115,15 @@ if test yes != "$_lt_caught_CXX_error"; then
> ;;
>
>openbsd* | bitrig*)
> -   if test -f /usr/libexec/ld.so; then
> - _LT_TAGVAR(hardcode_direct, $1)=yes
> - _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
> - _LT_TAGVAR(hardcode_direct_absolute, $1)=yes
> - _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag
> $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $lib'
> - _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath,$libdir'
> - if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`"; then
> -   _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag
> $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags
> $wl-retain-symbols-file,$export_symbols -o $lib'
> -   _LT_TAGVAR(export_dynamic_flag_spec, $1)='$wl-E'
> -   _LT_TAGVAR(whole_archive_flag_spec,
> $1)=$wlarc'--whole-archive$convenience '$wlarc'--no-whole-archive'
> - fi
> - output_verbose_link_cmd=func_echo_all
> -   else
> - _LT_TAGVAR(ld_shlibs, $1)=no
> -   fi
> +   _LT_TAGVAR(hardcode_direct, $1)=yes
> +   _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
> +   _LT_TAGVAR(hardcode_direct_absolute, $1)=yes
> +   _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag
> $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $lib'
> +   _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath,$libdir'
> +   _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag
> $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags
> $wl-retain-

Re: [PATCH v2 01/12] ltmain.sh: Fix sysroot paths being encoded into RPATHs

[Alex Ameen]

This was all green down the line on the test suite on multiple systems ( 
don't get too excited yet ) until I found bugs in the testsuite...


I see how this flew under the radar previously though - currently there 
are no tests which attempt to check RPATH or RUNPATH entries. I'll 
definitely be working on that... I'm going to be working out some M4 
macros to abstract some functions like `lt_read_pheader([BIN], 
[ENTRY])', `lt_read_rpath([BIN])', and `lt_read_runpath([BIN])', so that 
those can be abstracted for handling non-ELF binaries.


I'll make a test case to the effect of `readelf -d -W BIN|grep -v 
"$sysroot/";', if you have any additional input on new test cases let me 
know.


You also helped me catch some bad regex in the existing sysroot tests 
that would cause them to never be run on a system which used '/' as 
their GCC sysroot ( all of dpkg's  cross compilers seem to... ).


So a big thank you for helping to catch all of these places that the 
tool can be improved.


Naturally now that test cases aren't skipped they're red, so once I 
sanity check that they fail on the mainline branch I can move forward. 
I'm ~99% sure this patch will have no effect on those results.



On 4/16/22 12:58, Sam James wrote:

From: Richard Purdie 

There is a bug where RPATHs could end up containing sysroot values when
cross compiling which is obviously incorrect. Strip out sysroot components
from libdir when building RPATH values to avoid this.

Signed-off-by: Richard Purdie 
---
  build-aux/ltmain.in | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index a5f21a1d..d3a03a53 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -7676,9 +7676,11 @@ EOF
  test relink = "$opt_mode" || rpath=$compile_rpath$rpath
  for libdir in $rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
-   func_replace_sysroot "$libdir"
-   libdir=$func_replace_sysroot_result
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir
else
@@ -8408,6 +8410,10 @@ EOF
hardcode_libdirs=
for libdir in $compile_rpath $finalize_rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir
@@ -8459,6 +8465,10 @@ EOF
hardcode_libdirs=
for libdir in $finalize_rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir

Re: [PATCH v2 00/12] Rebased version of Yocto patches

[Alex Ameen]

My bad I just saw the follow up emails. You're all good.

On Sat, Apr 16, 2022, 1:29 PM Alex Ameen  wrote:

> Can you separate the flag changes from the others?
> Since that's not backwards compatible it needs to be shelved for a future
> major release. There's similar flag changes I've been organizing into a
> pile.
>
> On Sat, Apr 16, 2022, 12:58 PM Sam James  wrote:
>
>> Done after discussion w/ Alex (thanks!). Rebased on master after
>> 2.4.7 release.
>>
>> Khem Raj (3):
>>   libtool.m4: Rename the --with-sysroot option to avoid conflict with
>> gcc/binutils
>>   libtool: Check for static libs for internal compiler libraries
>>   ltmain.in: Add missing sysroot to library path
>>
>> Marek Vasut (1):
>>   libtool: Fix support for NIOS2 processor
>>
>> Mingli Yu (2):
>>   Makefile.am: make sure autoheader run before autoconf
>>   Makefile.am: make sure autoheader run before automake
>>
>> Richard Purdie (6):
>>   ltmain.sh: Fix sysroot paths being encoded into RPATHs
>>   ltmain.in: Handle trailing slashes on install commands correctly
>>   libtool.m4: For reproducibility stop encoding hostname in libtool
>> script
>>   ltmain.in: Don't encode RATHS which match default linker paths
>>   libtool.m4: Handle "/" as a sysroot correctly
>>   ltmain.in: Handle prefix-map compiler options correctly
>>
>>  Makefile.am |  4 +--
>>  build-aux/ltmain.in | 81 +++--
>>  m4/libtool.m4   | 25 --
>>  tests/sysroot.at|  6 ++--
>>  4 files changed, 89 insertions(+), 27 deletions(-)
>>
>> --
>> 2.35.1
>>
>>

Re: [PATCH v2 00/12] Rebased version of Yocto patches

[Alex Ameen]

Can you separate the flag changes from the others?
Since that's not backwards compatible it needs to be shelved for a future
major release. There's similar flag changes I've been organizing into a
pile.

On Sat, Apr 16, 2022, 12:58 PM Sam James  wrote:

> Done after discussion w/ Alex (thanks!). Rebased on master after
> 2.4.7 release.
>
> Khem Raj (3):
>   libtool.m4: Rename the --with-sysroot option to avoid conflict with
> gcc/binutils
>   libtool: Check for static libs for internal compiler libraries
>   ltmain.in: Add missing sysroot to library path
>
> Marek Vasut (1):
>   libtool: Fix support for NIOS2 processor
>
> Mingli Yu (2):
>   Makefile.am: make sure autoheader run before autoconf
>   Makefile.am: make sure autoheader run before automake
>
> Richard Purdie (6):
>   ltmain.sh: Fix sysroot paths being encoded into RPATHs
>   ltmain.in: Handle trailing slashes on install commands correctly
>   libtool.m4: For reproducibility stop encoding hostname in libtool
> script
>   ltmain.in: Don't encode RATHS which match default linker paths
>   libtool.m4: Handle "/" as a sysroot correctly
>   ltmain.in: Handle prefix-map compiler options correctly
>
>  Makefile.am |  4 +--
>  build-aux/ltmain.in | 81 +++--
>  m4/libtool.m4   | 25 --
>  tests/sysroot.at|  6 ++--
>  4 files changed, 89 insertions(+), 27 deletions(-)
>
> --
> 2.35.1
>
>

[patch #9305] Use $SED more

[Alex Ameen]

Update of patch #9305 (project libtool):

  Status:None => Done   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[patch #10007] Add support for MidnightBSD

[Alex Ameen]

Update of patch #10007 (project libtool):

  Status:  Ready For Test => Done   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[patch #9996] Patch libtool for macOS 11.0 (aka darwin20)

[Alex Ameen]

Update of patch #9996 (project libtool):

  Status:None => Done   
 Assigned to:None => growpotkin 
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[patch #10113] remove hard coded paths to /usr/bin/file

[Alex Ameen]

Update of patch #10113 (project libtool):

  Status:None => Done   
 Assigned to:None => growpotkin 
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: [patch #9687] bugfix: make -export-dynamic imply --whole-archive

[Alex Ameen]

Howdy Bob,

I totally agree with you. `libtool' definitely should not be creating 
solutions that only work with a particular linker in mind, and at a high 
level I think it should ultimately work to provide a sense of 
consistency across a variety of linkers.


In this case my concern is about ease of use for developers who might be 
confused about `libtool', `ld', and other link-editors having options 
with identical names which behave in very different ways. Here we have 
the flags `--whole-archive', `--no-whole-archive', and 
`--export-dynamic' which exist across almost all popular link-editors, 
GNU `ld' ( `ld.bfd' and `ld.gold' ), LLVM's `lld', Solaris' `ld', etc 
which have a consistent behavior. With that in mind I think having the 
flag `-export-dynamic' in `libtool' behave differently from "the norm" 
in discreet ways would likely cause confusion. To my knowledge HP UX and 
AIX are the only two systems which lack these flags ( I believe this is 
actually the type of thing that `libtool' should aim to port to those 
platforms ).


And yeah I agree that convenience libraries are wonky, and that linking 
static archives into dynamic libraries and executables is a tricky task. 
The good news on this front is that this is actually the area of linking 
and loading that I have the most experience in, and I'm familiar with 
many ( but not all ) of the pitfalls that pop up on Linux especially, 
but also with AIX and Windows. The reason I recommended the use of a 
convenience library in this case is because `libtool' already knows to 
use `--whole-archive' and `--no-whole-archive' for these libraries, so 
it is a convenient way to accomplish those goals in existing releases.


I took a look at the option parsing for `libtool --mode=link' in depth 
yesterday and I know why it has trouble handling `--whole-archive' and 
`--no-whole-archive' flags, fixing the issue isn't trivial just because 
of how the parser is written but I plan to get these flags to behave "as 
expected" for folks who are used to this feature in common link-editors.


Overall I think we're on the same page. I understand that `libtool' is 
ultimately intended to provide cross-platform consistency as a 
portability wrapper around each platform's various compilers, linkers, 
and loaders. It is certainly not my intention to promote a specific tool 
or platform over another.


-Alex


On 11/21/21 8:32 AM, Bob Friesenhahn wrote:

On Sat, 20 Nov 2021, Alex Ameen wrote:

Thanks for the follow up, this gave me a much clearer idea of the 
underlying issue that you're trying to solve. I really do appreciate 
you taking the time to help improve `libtool'.


You're absolutely right that `libtool' completely bungles the use of 
`--whole-archive' and `--no-whole-archive' which I see as a high 
priority issue. In several build systems I've built in the past I 
have needed to apply manual patches to `libtool' to work around this, 
and I plan on merging changes to fix this soon ( I'm taking my time 
to create test cases ).


I don't pretend to understand the associated issues, but please take 
care that libtool does not promote solutions which only work with GNU 
ld (or linkers designed to perfectly emulate GNU ld) on a limited set 
of targets.


Libtool is a portability solution to encourage development of software 
which is able to compile and run on many targets, even if the authors 
of the software have never experienced those targets.


Linking static libraries into shared libraries is a complex topic and 
is a reason why libtool offers the clumsy/inefficient "convenience 
library" mechanism since it assures that the objects were compiled 
properly to be used in the library they are linked into.


Bob

Re: [patch #9687] bugfix: make -export-dynamic imply --whole-archive

[Alex Ameen]

Thanks for the follow up, this gave me a much clearer idea of the 
underlying issue that you're trying to solve. I really do appreciate you 
taking the time to help improve `libtool'.


You're absolutely right that `libtool' completely bungles the use of 
`--whole-archive' and `--no-whole-archive' which I see as a high 
priority issue. In several build systems I've built in the past I have 
needed to apply manual patches to `libtool' to work around this, and I 
plan on merging changes to fix this soon ( I'm taking my time to create 
test cases ).


To answer your question about why `--whole-archive' and 
`--no-whole-archive' are useful flags in general : some code-bases 
create libraries with multiple builds of objects for differing 
configurations, which rely the "cherry picking" behavior of the linker 
in combination with dummy symbols to automatically select the 
appropriate form on an object for a given link. This is sometimes 
combined with `--as-needed' and `--no-as-needed' for more fine grained 
control. These use cases are niche, but they can be incredibly useful - 
and if I remember correctly I believe that `libpthread.so', GNU 
`libc.so.6', `libgcc', and several other "core" libraries use this 
behavior in combination with linker-scripts to "choose the right 
objects" ( the nitty gritty of how this is accomplished is an 
interesting rabbit hole to explore ). This reliance on "cherry picking" 
hopefully sheds light on why `--whole-archive' is not the default 
behavior, and why those flags exist. Now, having said that I agree that 
99.9% of the time when I link a `libfoo.a' into a binary ( especially a 
shared object ), I usually want the entire archive to link - so 
`--whole-archive' is a flag I use frequently and it's a major pain that 
`libtool' doesn't handle it correctly at the moment.


We could got back and forth on whether `-export-dynamic' should imply 
`--whole-archive' or not, but where I think we absolutely have agreement 
is that `libtool' needs to start handling `--whole-archive' and 
`--no-whole-archive' properly. Do you think if those flags were fixed, 
would invoking `libtool --mode=link -export-dynamic OBJECTS 
--whole-archive libfoo.a --no-whole-archive libbar.a ...;' be a suitable 
solution to your issue? Having thought about it more I think my gut 
concern was basically backwards-compatibility with existing 
`-export-dynamic' usage.


On your last comment about all of the linking junk being super complex : 
I totally agree with you, and despite exploring niche `ld' junk for 
years now I am always learning. I think at bottom this is why I'm 
cautious about having `-export-dynamic' imply `--whole-archive' 
automatically; I don't personally know every possible use case for these 
flags and I would hate to unknowingly break someone's code-base by 
silently changing the behavior of `-export-dynamic'.



On 11/20/21 10:28 AM, David Lamparter wrote:

Follow-up Comment #2, patch #9687 (project libtool):

Well, it's now 3 years later, and my memory of details on this is pretty much
gone, but let's try.  No warranty on anything here, I'm trying to
reconstruct.

[comment #1 comment #1:]

Could you maybe elaborate on your use case? Perhaps there's something that

I'm missing.

Any executable linked with `-export-dynamic` that links static libraries may
end up missing globally visible symbols if they are not used by the executable
itself.  If the program then tries to load a module that needs these symbols,
it fails.


In my opinion : the existing behavior both by `ld' and `libtool' is

appropriate. Implying `--whole-archive' for dependency libraries in with
`-export-dynamic' will prevent users from intentionally localizing symbols.

`--whole-archive` has no impact on symbol visibility; I don't follow at all
what you're trying to say here.  A binary linked with `-export-dynamic` is
essentially a shared library, and the `ld` docs state:

"This is normally used to turn an archive file into a shared library, forcing
every object to be included in the resulting shared library."

I agree `ld` is doing the appropriate thing here, but `libtool` isn't.  A
binary with `-export-dynamic` needs to export ALL of its global symbols from
ALL of its files for dynamically loaded modules to use.  It is essentially a
shared library at the same time and needs to be treated as such.

NB: `--whole-archive` does NOT make all symbols globally visible! This is
about *objects*, i.e. files.  If you have a file getting linked in that has
some global symbols, but none of them are used in the binary itself - `ld`
will drop the entire file.  That's the wrong thing to do for both creating a
shared library as well as for creating an executable with `-export-dynamic`.


I see these flags as having distinct use cases. I'll note that, the need for

using `--whole-archive' with `ld' isn't necessarily intuitive to users, so I
see the appeal of using it in many situations - but adding additional variance
between `libtool' and `l

[patch #9687] bugfix: make -export-dynamic imply --whole-archive

[Alex Ameen]

Update of patch #9687 (project libtool):

  Status:None => Need Info  
 Assigned to:None => growpotkin 

___

Follow-up Comment #1:

Could you maybe elaborate on your use case? Perhaps there's something that I'm
missing.

In my opinion : the existing behavior both by `ld' and `libtool' is
appropriate. Implying `--whole-archive' for dependency libraries in with
`-export-dynamic' will prevent users from intentionally localizing symbols.

I see these flags as having distinct use cases. I'll note that, the need for
using `--whole-archive' with `ld' isn't necessarily intuitive to users, so I
see the appeal of using it in many situations - but adding additional variance
between `libtool' and `ld' does not seem justified to me.

If the intention is to export symbols which are defined in statically linked
`libtool' libraries a "convenience library" ( `noinst_' ) might be what you're
actually looking for?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[patch #8977] libtool: add -Xassembler compilation flag support

[Alex Ameen]

Update of patch #8977 (project libtool):

  Status:None => Done   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[patch #10007] Add support for MidnightBSD

[Alex Ameen]

Follow-up Comment #1, patch #10007 (project libtool):

Looks straightforward to me.

I'm going to test it on my box just to catch typos or anything unexpected; but
since I don't have a MidnightBSD box could you run the test suite and upload
the logs?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[patch #10007] Add support for MidnightBSD

[Alex Ameen]

Update of patch #10007 (project libtool):

  Status:None => Ready For Test 
 Assigned to:None => growpotkin 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[patch #9305] Use $SED more

[Alex Ameen]

Update of patch #9305 (project libtool):

 Assigned to:None => growpotkin 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[patch #8977] libtool: add -Xassembler compilation flag support

[Alex Ameen]

Update of patch #8977 (project libtool):

 Assigned to:None => growpotkin 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: Organization of ltmain.in into sub-files

[Alex Ameen]

Gotcha I can contact GNU and handle any merges that are needed based on
submitted patches. The bulk of the "effort" was developing a good pattern
and forcing the build and support scripts to treat `ltmain.in' as a built
target, so honestly merging isn't a major hassle.

Thank you for pointing me in the right direction.

On Mon, Oct 18, 2021, 10:38 AM Bob Friesenhahn 
wrote:

> On Mon, 18 Oct 2021, Alex Ameen wrote:
>
> > This sounds great to me, I'd love to lend a hand.
> >
> > I had filled out the form a few weeks ago when I sent in patch for
> > `/usr/bin/file' references, so that might still be sitting in the queue
> for
> > review. If not, let me know and I can file a new request.
>
> The problem is that there are no libtool maintainers to service your
> requests. :-(
>
> This means that you would need to contact the GNU organization to
> express your interest in becomming a libtool maintainer.
>
> There are many pending bug reports with patches to be integrated. Your
> own work may collide with these patches so they can not be easily
> applied.
>
> Bob
> --
> Bob Friesenhahn
> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
> Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
>

Re: Organization of ltmain.in into sub-files

[Alex Ameen]

This sounds great to me, I'd love to lend a hand.

I had filled out the form a few weeks ago when I sent in patch for 
`/usr/bin/file' references, so that might still be sitting in the queue 
for review. If not, let me know and I can file a new request.


Thank you,

-Alex


On 10/18/21 8:15 AM, Bob Friesenhahn wrote:

On Sun, 17 Oct 2021, Alex Ameen wrote:


I thought I had seen in some TODO notes that other maintainers had been
working on reorganizing `ltmain.in', so I wanted to poke my head in 
and see

if there was an existing branch doing this sort of works, or if this was
something that anyone thinks would be useful as a project branch? 
Right now


Your work sounds like an excellent idea.  The major problem for the 
libtool project right now is that (as far as I am aware) there have 
not been active maintainers for years.  It seems like you have the 
skills required for this task.  Becoming an official libtool 
maintainer would help move the project forward and make it easier to 
integrate your own ideas.


Bob

Organization of ltmain.in into sub-files

[Alex Ameen]

Howdy,

I spent a few hours today seeing how reasonable it would be to split the
~9,000 `ltmain.in' script into a collection of smaller `m4sugar' files to
make it a bit easier to read/maintain. This began as a way for me to get my
feet wet with modifying `ltmain.in', but I was pleasantly surprised by how
well it's been working out so far.

Notably I am strictly using `m4sugar', not `m4sh' which is more of a
challenge ( trying to port diversions and wrapper scripts is a large effort
); but I've followed the same general patterns that might make alignment
easier in the future.

I've essentially moved one function at a time into various categories of
sub-files, some associated with each mode, IO for printing messages,
file/path handling. Each function is placed in a "PREPARE" block with an
associated `m4_defun_init' which references it. This means these functions
are still available exactly as they were before as regular shell functions,
but the M4 wrappers now exist as alternates that could be aligned quite
easily with the rest of `autom4te' usage.

I've found that not only are things a bit easier to navigate now, but that
the use of `m4_require' blocks has made ordering the script's contents much
easier.

I integrated the generation of `ltmain.in' from `ltmain.in.m4' into the
appropriate bootstrap and build files such that `ltmain.in' is packaged as
it was before - so `ltmain.in.sh' is effectively only relevant for
maintainers or people making extensions.

Test suite matches an unmodified branch as well which is good.


I thought I had seen in some TODO notes that other maintainers had been
working on reorganizing `ltmain.in', so I wanted to poke my head in and see
if there was an existing branch doing this sort of works, or if this was
something that anyone thinks would be useful as a project branch? Right now
I just have it living in a fork
<https://github.com/autotools-mirror/libtool/compare/master...aakropotkin:simple?expand=1>
of the GitHub mirror. I imagined uploading patches would be pretty
difficult to read since there's so many files created and snippets moved,
but if anyone prefers to check things out that way let me know.

Thanks for reading!

-- 
Alex Ameen

[patch #10113] remove hard coded paths to /usr/bin/file

[Alex Ameen]

URL:
  

 Summary: remove hard coded paths to /usr/bin/file
 Project: GNU Libtool
Submitted by: growpotkin
Submitted on: Sat 02 Oct 2021 12:19:57 AM UTC
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hard coded paths which invoke file(cmd) fail on certain Linux distributions,
in my case NixOS. I saw a commit from 1999 by Thomas Tanner  (
https://git.savannah.gnu.org/cgit/libtool.git/tree/libtool.m4?id=ef128a41ba1a3126f01b18054e7d4c5ca528f61c
) which used to call `AC_CHECK_TOOL(FILE` to handle this, I lost track of
exactly when it was removed, but I assume it was dropped because other macros
use `FILE` when performing compilation/linking checks.

This essentially restores Thomas Tanner  commit, but instead
of using the name `FILE` I instead use `FILECMD`. I tried to follow patterns
in use by other tools, but feel free to recommend any changes.

This passes everything in `make check` on my NixOS machine, except for
`destdir.at`, `old-ltdl-iface.at`, `cmdline_wrap.at` which appear to be
unrelated to my patch ( they fail on an unmodified build in my environment as
well ). See attached testsuite.log.

This patch is against the "public" master branch, I will rewrite it against
the private one for a merge.



___

File Attachments:


---
Date: Sat 02 Oct 2021 12:19:57 AM UTC  Name: filecmd.patch  Size: 3KiB   By:
growpotkin


---
Date: Sat 02 Oct 2021 12:19:57 AM UTC  Name: testsuite.log  Size: 163KiB   By:
growpotkin



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/