mainGNU Libtool - Support: sr #111171, libtool seems too happy to use...

 
 

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

Submitter:  Mitch <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
Open/Closed:  Open Operating System:  Microsoft Windows
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 11 Jan 2025 09:48:22 AM UTC, original submission:  

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.

Mitch <mitchc>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mitchc (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.14-9aa3.
    Corresponding source code