Bug #7036: Compiling extensions with Ruby in a path with spaces

• Status: Closed
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: 2.0.0
• ruby -v: ruby 2.0.0dev (2012-09-16 trunk 36983) [i386-mingw32]

[luislavena (Luis Lavena)]

=begin
Hello,

This has been reported several times to RubyInstaller: inability to install gems when Ruby has been installed in a path with spaces (e.g. (({C:\Program Files})))

Since this is presented to the user as (({gem install})) error, a deeper investigation revealed:

Generated Makefile contains a reference to (({RUBY})) that is not quoted, resulting in errors like this:

V:\User Name\ruby-2.0.0dev-i386-mingw32\lib\ruby\gems\2.0.0\gems\json-1.7.5\ext\json\ext\generator>make
generating generator-i386-mingw32.def
/bin/sh: V:/User: No such file or directory
make: *** [generator-i386-mingw32.def] Error 127

This can be easily solved by doing:

ruby = #{$ruby.quote}

The second issue is more complicated, as is caused by (({$LIBPATH})) and (({libdir})):

linking shared-object json/ext/generator.so
gcc.exe: error: Name/ruby-2.0.0dev-i386-mingw32/lib: No such file or directory
make: *** [generator.so] Error 1

While (({LIBPATH})) is being built using (({libpathflag})) method, this method fails to detect path with spaces since it uses (({LIBPATHFLAG})) from rbconfig

Since mkmf finds the above mentioned key in (({RbConfig::CONFIG})), it never attempts to use -L"%s" alternative:

LIBPATHFLAG = config_string('LIBPATHFLAG') || ' -L"%s"'

Now, (({libpathflag})) do not detect a path with spaces because the array of options given are (({[".", "$(libdir)"]})).

In the case of Windows, LIBPATHFLAG shouldn't be hardcoded, or at least should always quote strings, considering Ruby can be relocated.

Nobu, Usa, Hiroshi, what are your thoughts about this?

I'm looking for some feedback before I start some modifications.

Thank you in advance for your time.
=end

[luislavena (Luis Lavena)]

• Assignee changed from nobu (Nobuyoshi Nakada) to usa (Usaku NAKAMURA)

[usa (Usaku NAKAMURA)]

• Status changed from Open to Assigned
• Assignee changed from usa (Usaku NAKAMURA) to nobu (Nobuyoshi Nakada)

Building something with the path containing spaces is not recommended, IMO.
(see the end of win32/README.win32)

Of course, we should treat it if it's possible in low cost.
I'll consider it.

[luislavena (Luis Lavena)]

• File disable-libpathflag-mingw.diff disable-libpathflag-mingw.diff added

usa (Usaku NAKAMURA) wrote:

Building something with the path containing spaces is not recommended, IMO.
(see the end of win32/README.win32)

And I completely agree.

However, while README, RubyInstaller and Wiki instructions RubyInstaller project clearly state this issue, users still install things into Program Files and rant when it fails to compile gems.

This results in a not so great first experience that technically could be solved by simply quoting paths that contain spaces in them.

Attached patch to configure.in solves extension linking issue by always using -L"%s", even on non-spaced path still works properly.

But my suggestion about quote $ruby in mkmf.rb do not work because extmk sets it as using MINIRUBY and that gets improperly quoted, breaking extension compilation during make exts.

Nobu, it will be great if we can have your opinion and help on this.

Thank you Usa for your feedback.

[nobu (Nobuyoshi Nakada)]

Does your patch work to compile an extension library after installing in a directory with spaces?

[luislavena (Luis Lavena)]

nobu (Nobuyoshi Nakada) wrote:

Does your patch work to compile an extension library after installing in a directory with spaces?

Yes, the patch attached solves the linking issue.

By quoting $ruby after installing in mkmf also solves the generation of .def file.

But it fails during build since $ruby is miniruby (and a lot of options)

I haven't had enough time to look into this :(

[nobu (Nobuyoshi Nakada)]

Now trying: https://github.com/ruby/ruby/pull/185

[luislavena (Luis Lavena)]

=begin
nobu (Nobuyoshi Nakada) wrote:

Now trying: https://github.com/ruby/ruby/pull/185

Thank you Nobu, but the patch to mkmf do not solve quote of $ruby:

V:\User Name\json-1.7.5\ext\json\ext\generator>make
generating generator-i386-mingw32.def
/bin/sh: V:/User: No such file or directory
make: *** [generator-i386-mingw32.def] Error 127

Also, with patch applied, I was uable to build Ruby stblib extensions. Makefile for those were generated during configure, but the resulting extensions (.so) or object files (.o) were not copied or generated into .ext and ext folders.

Only encodings .so files were generated.

Perhaps my naive patch to configure.in combined with a patch that detects (({$extmk})) in mkmf could be enough?

Thank you.
=end

[luislavena (Luis Lavena)]

• File disable-libpathflag-mingw.v2.diff disable-libpathflag-mingw.v2.diff added

Nobu,

Looking at some of the changes you did couldn't understand entirely, but understood that $extmk gets set only when building from extmk.rb, which gave me the idea of the new patch I'm attaching.

This new patch set LIBPATHFLAG as empty allowing -L"%s" from mkmf to work.

It also quotes $ruby unless running in $extmk mode.

This new patch works for both compilation of Ruby stdlib extensions and after installation, to compile extensions from gems on path with spaces.

I know is very (very) naive approach, so will appreciate your feedback.

Thank you.

[nobu (Nobuyoshi Nakada)]

• Status changed from Assigned to Closed
• % Done changed from 0 to 100

This issue was solved with changeset r37017.
Luis, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

---

mkmf.rb: unspace

• lib/mkmf.rb (String#unspace): unescape with backslashes. normal
  makes need to escape spaces with backslashes. nmake is not the
  case. [Bug #7036]