[sr #111171] libtool seems too happy to use ranlib, can cause subtle library corruption

[Mitch]

URL:
  <https://savannah.gnu.org/support/?111171>

                 Summary: libtool seems too happy to use ranlib, can cause
subtle library corruption
                   Group: GNU Libtool
               Submitter: mitchc
               Submitted: Sat 11 Jan 2025 09:48:22 AM UTC
                Category: None
                Priority: 5 - Normal
                Severity: 4 - Important
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email:
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: Microsoft Windows


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Sat 11 Jan 2025 09:48:22 AM UTC By: Mitch <mitchc>
Running windows using GNUlib wrappers for compilers and compiling using MSVC
for everything.

Compiling in a fairly bare msys2 environment but the mere presence of ranlib
seems to cause some havoc. 

As I understand ranlib is not needed for most modern toolchains? Given I see
such notes dating a decade back how often is ranlib required?

I ask as the _LT_CMD_OLD_ARCHIVE macro from libtool.m4 seems like it doesn't
matter the OS, or compiler, if ranlib is present use it:
https://github.com/mitchcapper/libtool/blob/b341c9f8d0e09b5bed0573964af4bc239b8cfd96/m4/libtool.m4#L1577-L1595

Now its called old_archive so maybe it isn't supposed to end up enabled in
normal workflows and I am doing something silly to cause it to happen.  I can
see it required in the libtool.m4 file but I don't see any calls to it.  I can
also say that on an ubuntu 24 box with binutils 2.42 running a standard
autoconf and configure it detects ranlib's presence and does call it.   

At the end of the day though is there a way to better guard against it being
called when not needed? Detecting the linker / ar version, or OS or compiler?
What about just creating the lib and testing to see if it needs it?

I am sure on most situations a call to ranlib is harmless but when dealing
with MSVC lib archives it can cause some annoying corruption.  Part of that is
obviously a binutils issue and I will file a ticket there, but part of that is
libtool sadly doing on windows what it says it won't do (using ranlib).  The
corruption that occurs is with the index, but the remaining parts of the
library seem fine.  It also is compounded by itself.  If the lib was only used
by outside tools it probably wouldn't run into a problem but when libtool
tries to use it the corruption ranlib caused confuses libtool.  As libtool
does a lot of magic behind the scenes the error isn't super apparent either.

In this case, when compiling gnutls, the result was an undefined symbol error.
 This didn't happen early on though, the object file was generated the library
file was generated, that library then included in another library and only
then when compiling it into an executable did the error show up.  To make it
more fun to trace the actual symbol export is still in the library so dumping
the exports it looks like it should be there only the index is screwed.

Should ranlib be present? Probably not.  My local systems it wasn't, github
likes to throw every possible bin tool into your path though for github
actions and that included mingw which included binutils and ranlib.

It is clear libtool's Windows and MSVC usage is not huge given the somewhat
crippling bugs that can exist with it:
 https://savannah.gnu.org/support/?110901
 https://savannah.gnu.org/support/?111157

but libtool's goal is to make shared libraries across platforms and compilers
easy and consistent.   If the largest compiler on the largest desktop os can
have libtool output corrupted if ranlib is anywhere in the path I figure it
might be worth addressing. 

This sort of bug many users would probably just give up on given the
non-apparent nature of what is going wrong.  This is also a long tail fix I
assume, given the fact this would get baked into the configure script itself
and is non obvious (if I understand the macros correctly).  Then again clearly
no one is on fire as there are not major bug reports on this  (assuming they
were able to trace it down).


I will say out of the many libs/tools I am compiling (
https://github.com/mitchcapper/WIN64LinuxBuild ), 6 had the libtool calls that
would call ranlib: wget2, wolfcrypt, libpsl, libhsts, gnutls, gawk.  This is
the only one that ended with a compiler failure as that is the sort of fun
corruption one can have happen:)

I had no problem fixing this bug for myself (setting RANLIB=/bin/true does the
magic) but the goal here is to make libtool workable for more users.







    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/support/?111171>

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

signature.asc
Description: PGP signature