mainGNU Libtool - Support: sr #111157, MSVC / cl.exe .exp extension...

 
 

sr #111157: MSVC / cl.exe .exp extension collision

Submitter:  Mitch <mitchc>
Submitted:  Mon 02 Dec 2024 08:47:48 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Operating System:  Microsoft Windows
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 29 May 2025 05:04:23 PM UTC, comment #1: 

Thank you for your bug report and proposed patch! I have applied the patch in the development branch [1], and it should migrate to master after some time for testing its behaviour.

If there are any changes you would like made to the commit header, I can update it when it moves to master later.

[1]https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=f49da6ca2a77234719f34597ea583f29c0cf10d4

Ileana Dumitrescu <ildumi>
Group administrator
Mon 02 Dec 2024 08:47:48 PM UTC, original submission:  

I love libtool and it is great it is getting some additional Windows support.  Was happy to see the /Fe fix.  Unfortunately a biproduct of the newer MSVC support has caused a new issue in terms of the .exp files using with multi-step linking.

Libtool uses .exp files as input into cl.exe, and this works.  These are essentially just command line commands in a file and using the "@" arg.  An example is: https://github.com/mitchcapper/libtool/blob/baa1fe41f9a2697e2d5847c8e1c97996560d56d1/m4/libtool.m4#L5742 .  The problem though is .exp is also used by microsoft for their own export format:
https://learn.microsoft.com/en-us/cpp/build/reference/dot-exp-files-as-linker-input?view=msvc-140

So the first time through a make build it would succeed, when the .exp file is used.  The command though will override the input file itself as microsoft takes the output arg "-Fe$tool_output_objdir$soname"  and appends .exp for its export file and this is the same name libtool uses.   This causes the make to fail the second time with cl.exe complaining the file format is invalid (as it is now a binary file not the additional command line args).

I use libtool with several GNU projects I build: https://github.com/mitchcapper/WIN64LinuxBuild

and my libtool hacks: https://github.com/mitchcapper/WIN64LinuxBuild/blob/0c7a19c857c8feac3e258669512f0abdb99d59f9/helpers_gnu.sh#L141-L142 just mass replace .exp with .expsym I have a commit of this specific fix at: https://github.com/mitchcapper/libtool/compare/master...exp_extension_change

but I am not sure if this would be preferred for a patch.  As far as I am aware .exp is only used internally by libtool so this should be decently safe/not break anything.  Still you might prefer a windows only fix given MSVC is the only place this happens.  Let me know and I can update the commit and get it submitted. 

I read the process doc ( https://www.gnu.org/software/libtool/contribute.html#patches ) and understand I should be making a changelog entry and submitting it to the mailing list after posting it in this bug report.  I figured I would find out what direction was desired before creating the patch.

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 ildumi (Posted a comment)
  • -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.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-05-29 ildumi StatusNone Done
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code