[sr #110525] Typos caught by codespell

[Alex Ameen]

Update of sr #110525 (project libtool):

 Assigned to:None => growpotkin 


___

Reply to this item at:

  

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

[sr #110550] File expected to be at /usr/bin/file, isn't on ChromeOS

[Alex Ameen]

Update of sr #110550 (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: New libtool maintainer

[Richard Purdie]

On Sun, 2021-11-21 at 13:14 -0600, Alex Ameen wrote:
> I just took a look at those. Good catches on the typos, I probably would 
> not have noticed them just reading the script myself. Same thing with 
> the M4 `[]' quoting issue ( classic pitfall ). I'll get these merged ASAP.
> 
> For the non-Linux patches I can merge them, but I don't have personally 
> have OSX, powerpc, or Solaris boxes, and while I do have a Windows 
> partition I don't currently have it set up to run these kinds of tests. 
> Nonetheless I can merge these - if you have access to any of those 
> platforms let me know if you would be open to running `make check' and 
> posting the logs so I can sanity check the new behavior.
> 
> Thank you so much for bringing these to my attention. There's a long 
> list of old patches and mailing list archives and as a practical matter 
> it's hard to know which of them are still relevant - so I appreciate 
> your help.

I did recently post the better bits of the OpenEmbedded/Yocto Project patchset
for libtool:

https://lists.gnu.org/archive/html/libtool-patches/2021-10/msg00012.html

Those are at up to date and in regular use in OE/YP which is widely used for
cross compiling for Linux/mingw and others. We tend to find sysroot and cross
compile issues in particular and we also find reproducibility and parallel make
race issues.

If you have any questions or concerns on any of those I'm happy to try and help.

Cheers,

Richard

Re: New libtool maintainer

[Alex Ameen]

That would be a huge help. Thanks for the tip, I'm filling out the 
account request stuff now. :)


On 11/21/21 2:04 PM, Russ Allbery wrote:

Alex Ameen  writes:


For the non-Linux patches I can merge them, but I don't have personally
have OSX, powerpc, or Solaris boxes, and while I do have a Windows
partition I don't currently have it set up to run these kinds of
tests. Nonetheless I can merge these - if you have access to any of
those platforms let me know if you would be open to running `make check'
and posting the logs so I can sanity check the new behavior.

For testing INN builds on non-Linux, non-x86 platforms, we use the GCC
Compile farm project:

 https://gcc.gnu.org/wiki/CompileFarm

I am certain they would be happy to give you access as Libtool maintainer.

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

[Bob Friesenhahn]

On Sun, 21 Nov 2021, Alex Ameen wrote:


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.


I am glad that our new maintainer is philosophically on the same page 
and also has excellent skills.


I think that (similar to the influence of GNU/FSF philosophies on 
software development) libtool should help guide application developers 
to to use the most portable approaches while achieving their own 
objectives.  From this standpoint, libtool (and Autotools in general) 
are not just 'tools' (like 'ld') but help guide users (developers) so 
that if they follow guidelines, and what the tools intend to promote, 
their applications are most likely to be portable and still work well.


If the development/porting problem is looked at using Venn diagrams, 
then there would be a proportion of features/solutions in common 
amongst modern targets and those should be the features/solutions 
which are promoted by Autotools.  In some cases the description of 
what is wanted can be at a high enough level that the desired 
low-level behavior can be accomplished entirely differently on 
different targets (because of how they work).


In Autotools, the above has worked well, although there have been many 
complaints over the years about libtool behavior regarding explicit 
dependencies (via ".la" files) whereas leveraging implicit 
dependencies are usually prefered by distribution maintainers.


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: New libtool maintainer

[Russ Allbery]

Alex Ameen  writes:

> For the non-Linux patches I can merge them, but I don't have personally
> have OSX, powerpc, or Solaris boxes, and while I do have a Windows
> partition I don't currently have it set up to run these kinds of
> tests. Nonetheless I can merge these - if you have access to any of
> those platforms let me know if you would be open to running `make check'
> and posting the logs so I can sanity check the new behavior.

For testing INN builds on non-Linux, non-x86 platforms, we use the GCC
Compile farm project:

https://gcc.gnu.org/wiki/CompileFarm

I am certain they would be happy to give you access as Libtool maintainer.

-- 
Russ Allbery (ea...@eyrie.org) 

Re: New libtool maintainer

[Alex Ameen]

I just took a look at those. Good catches on the typos, I probably would 
not have noticed them just reading the script myself. Same thing with 
the M4 `[]' quoting issue ( classic pitfall ). I'll get these merged ASAP.


For the non-Linux patches I can merge them, but I don't have personally 
have OSX, powerpc, or Solaris boxes, and while I do have a Windows 
partition I don't currently have it set up to run these kinds of tests. 
Nonetheless I can merge these - if you have access to any of those 
platforms let me know if you would be open to running `make check' and 
posting the logs so I can sanity check the new behavior.


Thank you so much for bringing these to my attention. There's a long 
list of old patches and mailing list archives and as a practical matter 
it's hard to know which of them are still relevant - so I appreciate 
your help.



On 11/20/21 2:56 AM, Ozkan Sezer wrote:

On 10/27/21, Alex Ameen  wrote:

Howdy!

This is Alex Ameen reporting in from Austin, Texas. I'm a long time GNU
and `autotools' user who specializes in ELF linking and loading. I'm
writing you today to introduce myself and announce that I was recently
approved as the new maintainer of `libtool'!

I'm excited to bring some updates to the tool and want to thank everyone
for their patience while I work my through the pending patch/bug lists
and get familiar with some of the maintenance infrastructure.

In the near future I look forward to extending `libtool' support for
modern ELF shared objects, and improved integration with the rest of
`autotools'. I'll share a more detailed roadmap after I've worked my
through the pending tasks in the mailing lists.

I want to express my appreciation for all of the `autotools' and
`libtool' maintainers/contributors before me. I understand that
`libtool' is an important piece of infrastructure for a number of
important pieces of software, and I aim to treat modifications and
extensions appropriately with that responsibility in mind ( don't worry
I'm not going to break legacy behavior with reckless abandon haha ).

Feel free to reach out if you have pending patches/issues you want to
"bump", ideas for improvements, general advice for a new GNU maintainer
- and above all if you'd like to lend a hand toward getting `libtool' up
and running again.

Thank you for your time,

-Alex Ameen

It would be nice if the patches for the following long-standing
bugs were applied:


https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21137 (also reported
 duplicately as 22895, 31900 and 36762)
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22373
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38305
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46559
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44605 (also see 44684)

And maybe this?
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41837

--
O.S.

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

[Bob Friesenhahn]

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
--
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