Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Library install with "make install" fails on Win/Cygwin when build path contains space #643

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 1 comment
Labels
waiting Waiting on user response

Comments

@SDLBugzilla
Copy link
Collaborator

SDLBugzilla commented Feb 10, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.0
Reported for operating system, platform: Windows 7, x86_64

Comments on the original bug report:

On 2012-08-19 09:23:18 +0000, Andreas Schiffler wrote:

Created attachment 931
Log from "make -d install"

Running "make install" (or "make install-lib") from
/cygdrive/c/Users/Andreas Schiffler/Desktop/Sources/SDL/build
fails with:

libtool: install: ranlib /usr/local/lib/libSDL2.a
/bin/sh: /cygdrive/c/Users/Andreas: No such file or directory
Makefile:141: recipe for target `install-lib' failed
make: *** [install-lib] Error 127

Log from "make -d install" attached.

On 2012-08-19 09:49:08 +0000, Andreas Schiffler wrote:

Created attachment 932
Fixed libtool

One can repro the issue with

/bin/sh ./libtool --debug --mode=install /usr/bin/install -c build/libSDL2.la /usr/local/lib/libSDL2.la

The problem is caused by incorrect quoting in libtool. The variable $progpath is not correctly wrapped in double quotes in several places.

Fixed libtool attached.

On 2012-08-19 10:04:19 +0000, Andreas Schiffler wrote:

$ diff libtool libtool-fixed

2797c2797
<       exec_cmd='$SHELL $progpath $preserve_args --finish$current_libdirs'
---
>       exec_cmd='$SHELL "$progpath" $preserve_args --finish$current_libdirs'
8321c8321
<       if test "X$ECHO" = "X$SHELL $progpath --fallback-echo"; then
---
>       if test "X$ECHO" = "X$SHELL \"$progpath\" --fallback-echo"; then
8323,8324c8323,8324
<       [\\/]* | [A-Za-z]:[\\/]*) qecho="$SHELL $progpath --fallback-echo";;
<       *) qecho="$SHELL `pwd`/$progpath --fallback-echo";;
---
>       [\\/]* | [A-Za-z]:[\\/]*) qecho="$SHELL \"$progpath\" --fallback-echo";;
>       *) qecho="$SHELL `pwd`/\"$progpath\" --fallback-echo";;
8559c8559
<       relink_command="(cd `pwd`; $SHELL $progpath $preserve_args --mode=relink $libtool_args @inst_prefix_dir@)"
---
>       relink_command="(cd `pwd`; $SHELL \"$progpath\" $preserve_args --mode=relink $libtool_args @inst_prefix_dir@)"

On 2014-06-20 12:23:44 +0000, Klemen Sever wrote:

Created attachment 1694
Log of "make install" on MacOSX with path containing space

I have the same issue when trying to compile SDL2 on a MacOSX v10.9.3.

On 2014-07-09 08:23:00 +0000, Sam Lantinga wrote:

Andreas, there are a bunch of places in build-scripts/ltmain.sh where $progpath is unquoted. Would the correct fix be to quote all of them?

On 2014-07-09 13:34:23 +0000, Andreas Schiffler wrote:

Yes, it is possible that there are other codepaths besides "make install" that also need this fix. The proposed changes below should cover the most common case though (./configure && make && make install).

@SDLBugzilla SDLBugzilla added bug waiting Waiting on user response labels Feb 10, 2021
@icculus icculus added this to the 2.0.18 milestone Aug 9, 2021
@slouken slouken self-assigned this Nov 8, 2021
@slouken
Copy link
Collaborator

slouken commented Nov 9, 2021

There are actually a bunch of problems with the autotools configuration when there are spaces in the path for the source code as well as the build directory.

Fixing them is out of scope for 2.0.18, and if you're in this situation I would recommend using CMake, which handles this case correctly.

@slouken slouken removed this from the 2.0.18 milestone Nov 9, 2021
@slouken slouken removed their assignment Nov 9, 2021
@slouken slouken removed the bug label May 11, 2022
@slouken slouken closed this as completed May 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
waiting Waiting on user response
Projects
None yet
Development

No branches or pull requests

3 participants