[sr #110978] libtool.m4: Not respecting $LD when checking for --whole-archive

[Mike Frysinger]

Update of sr#110978 (group libtool):

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

___

Follow-up Comment #1:

merged now, thanks
https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=f81f36e4e9f9e4e5a8b827dd831393d5867b244f


___

Reply to this item at:

  

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

Re: Introducing a new maintainer of libtool

[Mike Frysinger]

On 13 Jan 2024 14:49, Ileana Dumitrescu wrote:
> My short term plans are to review the numerous mailing list patches and 
> get them merged in. This will be an easy and productive first step for 
> me and libtool. I will also look at the various distro patches and see 
> if any of them are fit to be upstreamed as I have noticed some of the 
> distros have been accruing a lot of patches as well.

i think we should aim to kick out something new sooner rather than later.
so aim to include smaller/less risky changes as it's been ~2 years since
the last release.  i don't mean this in terms of rushing you, but more
"better to cut off sooner" than "try to merge everything that should be
merged, but end up taking much longer in the process".  we can always
make another release if we really want something out there.  especially
as "this patch is so simple" can be very deceptive with libtool.
-mike


signature.asc
Description: PGP signature

Re: Introducing a new maintainer of libtool

[Simon Josefsson via Discussion list for the GNU libtool shared library maintenance tool]

Welcome Ileana!

Mike Frysinger  writes:

> On 13 Jan 2024 14:49, Ileana Dumitrescu wrote:
>> My short term plans are to review the numerous mailing list patches and 
>> get them merged in. This will be an easy and productive first step for 
>> me and libtool. I will also look at the various distro patches and see 
>> if any of them are fit to be upstreamed as I have noticed some of the 
>> distros have been accruing a lot of patches as well.
>
> i think we should aim to kick out something new sooner rather than later.

+1

If what's on git master passes self checks, I would package it and
prepare an alpha release and announce that to pretesters mailing list.
Assuming there is nothing in git master that really upsets you and needs
to be backed out.  Don't look at more patches until a first pretest
release is out, IMHO, as I'm sure one can go mad pondering implications
of a libtool patch forever...

/Simon


signature.asc
Description: PGP signature

Re: Introducing a new maintainer of libtool

[Vincent Lefevre]

On 2024-01-16 15:44:08 -0500, Mike Frysinger wrote:
> On 13 Jan 2024 14:49, Ileana Dumitrescu wrote:
> > My short term plans are to review the numerous mailing list patches and 
> > get them merged in. This will be an easy and productive first step for 
> > me and libtool. I will also look at the various distro patches and see 
> > if any of them are fit to be upstreamed as I have noticed some of the 
> > distros have been accruing a lot of patches as well.
> 
> i think we should aim to kick out something new sooner rather than later.
> so aim to include smaller/less risky changes as it's been ~2 years since
> the last release.  i don't mean this in terms of rushing you, but more
> "better to cut off sooner" than "try to merge everything that should be
> merged, but end up taking much longer in the process".  we can always
> make another release if we really want something out there.  especially
> as "this patch is so simple" can be very deceptive with libtool.
> -mike

+1

In particular, if some patch has issues, it may be easier to test
its effects if one has had a recent stable release.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[sr #110962] pass_all for z/OS

[Mike Frysinger]

Update of sr#110962 (group libtool):

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

___

Follow-up Comment #1:

you posted the patch to the list -- you don't need to file a bug report too


___

Reply to this item at:

  

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

[sr #110870] Typos in libtool.texi and libtool.m4

[Mike Frysinger]

Update of sr#110870 (group libtool):

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

___

Follow-up Comment #1:

should be fixed in latest git now, thanks


___

Reply to this item at:

  

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

[sr #110525] Typos caught by codespell

[Mike Frysinger]

Update of sr#110525 (group libtool):

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

___

Follow-up Comment #1:

should be fixed in latest git now, thanks


___

Reply to this item at:

  

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

[sr #110796] libtool-2.4.7/build-aux/git-version-gen uses kind of a hack

[Mike Frysinger]

Update of sr#110796 (group libtool):

  Status:None => Wont Do
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

build-aux/git-version-gen is maintained in the gnulib project, so you prob
want to report issues to them instead

https://www.gnu.org/software/gnulib


___

Reply to this item at:

  

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

[sr #108987] libtool doesn't like simple RM defined (without options)

[Mike Frysinger]

Follow-up Comment #4, sr#108987 (group libtool):

bootstrap & build-aux/funclib.sh are not maintained in libtool.  you'll want
to send those fixes upstream.
https://github.com/gnulib-modules/bootstrap


___

Reply to this item at:

  

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

[sr #102833] doc

[Mike Frysinger]

Update of sr#102833 (group libtool):

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

___

Follow-up Comment #1:

i don't think there's anything left to do here


___

Reply to this item at:

  

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

[sr #102915] Compilation errors with gcc -mno-cygwin

[Mike Frysinger]

Update of sr#102915 (group libtool):

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

___

Follow-up Comment #2:

i don't know what "plsdbug" is, but source compilation errors in random
projects are rarely a libtool bug.  you should contact whoever maintains
"lt-plsdbug.c".


___

Reply to this item at:

  

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

[sr #107584] Fails to detect the global symbol pipe

[Mike Frysinger]

Follow-up Comment #1, sr#107584 (group libtool):

please attach a patch showing what you mean


___

Reply to this item at:

  

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

[sr #107959] Libtool generates invalid .def files

[Mike Frysinger]

Update of sr#107959 (group libtool):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[sr #108558] libtool nm test does not really work for W32 versions of nm

[Mike Frysinger]

Update of sr#108558 (group libtool):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[sr #108559] libtool binary wrappers fall prey to aggressive optimizations

[Mike Frysinger]

Update of sr#108559 (group libtool):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[sr #110947] flang: error: unknown argument: '-soname'

[Mike Frysinger]

Update of sr#110947 (group libtool):

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

___

Follow-up Comment #4:

this is handled via https://savannah.gnu.org/patch/?9442


___

Reply to this item at:

  

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

[sr #111002] regression in libtool 2.4.7: build error in ncurses

[Mike Frysinger]

Update of sr#111002 (group libtool):

  Status:None => Need Info  

___

Follow-up Comment #1:

are you using patched libtool in your system ?  ncurses-6.4 builds fine for me
with libtool-2.4.7.

please attach your /usr/bin/libtool file.


___

Reply to this item at:

  

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

[sr #110261] _LT_CMD_OLD_ARCHIVE should not inline AC_PROG_RANLIB

[Mike Frysinger]

Follow-up Comment #1, sr#110261 (group libtool):

LT_INIT already does AC_PREREQ(2.62), so relying on AC_PROG_RANLIB sounds
fine

want to send a patch to the mailing list ?


___

Reply to this item at:

  

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

[sr #107584] Fails to detect the global symbol pipe

[Mike Frysinger]

Update of sr#107584 (group libtool):

  Status:None => Need Info  


___

Reply to this item at:

  

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