URL: <https://savannah.gnu.org/support/?111157>
Summary: MSVC / cl.exe .exp extension collision
Group: GNU Libtool
Submitter: mitchc
Submitted: Mon 02 Dec 2024 08:47:48 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Operating System: Microsoft Windows
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Mon 02 Dec 2024 08:47:48 PM UTC By: Mitch <mitchc>
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.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/support/?111157>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
