On Wed, 22 Jul 2015, Steve Lhomme wrote:
--
replaced sed by dirname
---
configure | 2 +-
tools/mslink.sh | 5 +++++
2 files changed, 6 insertions(+), 1 deletion(-)
create mode 100644 tools/mslink.sh
diff --git a/configure b/configure
index 16bf852..a1901af 100755
--- a/configure
+++ b/configure
@@ -2633,7 +2633,7 @@ case "$toolchain" in
else
cc_default="c99wrap cl"
fi
- ld_default="link"
+ ld_default="$source_path/tools/mslink.sh"
nm_default="dumpbin -symbols"
ar_default="lib"
target_os_default="win32"
diff --git a/tools/mslink.sh b/tools/mslink.sh
new file mode 100644
index 0000000..ebf98f1
--- /dev/null
+++ b/tools/mslink.sh
@@ -0,0 +1,5 @@
+#!/bin/sh
+
+LINK_EXE_PATH=$(dirname "`which cl.exe`")/link.exe
+"$LINK_EXE_PATH" $@
+exit $?
--
2.4.5
Can this be changed to just do "which cl" and append "link" instead of
"link.exe" here? Then it should probably work with my msvc/wine setup as
well.
A separate way of making this even more failsafe would be:
LINK_EXE_PATH=$(dirname "`which cl`")/link
if [ -x ${LINK_EXE_PATH}.exe ]; then
"${LINK_EXE_PATH}.exe" $@
elif [ -x $LINK_EXE_PATH ]; then
$LINK_EXE_PATH $@
else
link $@
fi
That is; if you don't happen to have link.exe in the same dir as cl.exe,
we should just call "link" instead of failing hard.
All in all, this is probably the least bad workaround so far, and I
wouldn't object to this.
Calling extra intermediate shell scripts does slow the build down when on
msys; if this would be for compiling individual object files, it would be
significant (I tried reimplementing c99wrap in shell instead of as a C
binary, and it became prohibitively slow, although that was a much more
complicated script than this), but since there's only a handful of link
commands in a normal build, this probably wouldn't matter much. (It would
actually matter more for the configure process.)
Out of curiosity, can you/someone else with msys time how long a call to
configure takes before and after this patch?
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
