Project

General

Profile

Bug #1060

mkmf refuses to find 3rd party extensions - ruby 1.9.1 trunk

Added by cfis (Charlie Savage) over 11 years ago. Updated over 9 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Target version:
ruby -v:
-
Backport:
[ruby-core:21598]

Description

=begin
When building with msys/mingw, mkmf incorrectly says header files don't exist when in fact they do. This happens when building the extensions for curses (PDCurses), tk, zlib etc.

Let's use tk as an example. I downloaded, built and successfully installed tcl and tk using MinGw, on Vista, gcc 3.4.5. Then, I built ruby. As mentioned, the tk extension isn't built. Looking at ext/tk/mkmf.log:

find_header: checking for tcl.h in ... -------------------- no

"gcc -E -I../../.ext/include/i386-mingw32 -I../.././include -I../.././ext/tk -I/usr/local/include -I/usr/local/include -O2 -g -Wall -Wno-parentheses conftest.c -o conftest.i"
checked program was:
/* begin /
1: #include "ruby.h"
2:
3: #include
4: #include
5: #include
/
end */

Except, this isn't true! Paste the code into conftest.c, place it in ext/tk/conftest. Then:

$ gcc -E -I../../.ext/include/i386-mingw32 -I../.././include -I../.././ext/tk -
I/usr/local/include -I/usr/local/include -O2 -g -Wall -Wno-parentheses conf
test.c -o conftest.i

gcc runs fine - looking at the dirctory:

$ ll conf*
-rw-r--r-- 1 cfis Administrators 80 Jan 27 00:07 conftest.c
-rw-r--r-- 1 cfis Administrators 944777 Jan 27 00:08 conftest.i

conftest.i is built.

Yet mkmf says the header does not exist, and does not build the extension.
=end


Files

mkmf_cfis.patch (344 Bytes) mkmf_cfis.patch cfis (Charlie Savage), 01/27/2009 05:39 PM
#1

Updated by cfis (Charlie Savage) over 11 years ago

=begin
Ok, I figured out what is going on here.

I am building Ruby using msys plus mingw. I find that easier than just straight mingw (or vc++) because msys can easily build pdcurses, zlib, tlc, tk, etc.

The problem is that mkmf calls Kernel::Sytem, which runs commands in a subshell, which I'm going to guess is windows command.exe. That of course breaks the build because paths such as /usr/local/include no longer work.

This can be fixed by spawning bash instead. So something like this:

--- mkmf.rb 2009-01-27 01:29:14 -0700
+++ mkmf.new.rb 2009-01-27 01:28:40 -0700
@@ -295,6 +295,11 @@
nil while command.gsub!(varpat) {vars[$1||$2]}
end

  • if /mingw/ =~ CONFIG['build_os'] and
  • /sh/ =~ CONFIG['SHELL']
  • command = "sh -c '#{command}'"
  • end + Logging::open do puts command.quote system(command)

Its hardly perfect of course - I can see ways of breaking it (like not having sh in your patch).

Maybe a better approach is to patch mkmf so you can supply a shell as a command line parameter.

It does seem reasonable when building ruby with msys+mingw, that extensions should also be built using the same shell. Without this change, you can't effectively build ruby with mingw+msys since you get no 3rd party extensions. I would guess the same issue would affect cygwin when using -mno-cygwin, but I haven't checked (and have no plans too).

Thanks - Charlie

=end

#2

Updated by cfis (Charlie Savage) over 11 years ago

=begin
Ok, skip this. Obviously I can just use the full windows path via CPPFLAGS and LDFLAGS. So go ahead and close.
=end

#3

Updated by luislavena (Luis Lavena) over 11 years ago

=begin
On Tue, Jan 27, 2009 at 3:13 PM, Charlie Savage redmine@ruby-lang.org wrote:

Issue #1060 has been updated by Charlie Savage.

Ok, skip this. Obviously I can just use the full windows path via CPPFLAGS and LDFLAGS. So go ahead and close.

Hey Charlie.

In my case even I'm using msys for bash and msys-make, I always
indicate full Windows PATHs instead of MSYS ones, so includes and
libraries search locations are expressed with drive letters and full
paths.

This is how One-Click Installer recipes are been building Ruby right now.

HTH,
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

=end

#4

Updated by nobu (Nobuyoshi Nakada) over 11 years ago

=begin
Hi,

At Tue, 27 Jan 2009 17:36:44 +0900,
Charlie Savage wrote in [ruby-core:21603]:

The problem is that mkmf calls Kernel::Sytem, which runs
commands in a subshell, which I'm going to guess is windows
command.exe. That of course breaks the build because paths
such as /usr/local/include no longer work.

try `RUBYSHELL=/bin/bash make'.

--
Nobu Nakada

=end

#5

Updated by yugui (Yuki Sonoda) over 11 years ago

  • Target version changed from 1.9.1 to 1.9.2
  • ruby -v set to -

=begin

=end

#6

Updated by nobu (Nobuyoshi Nakada) over 11 years ago

  • Status changed from Open to Rejected

=begin

=end

#7

Updated by cfis (Charlie Savage) over 11 years ago

=begin

At Tue, 27 Jan 2009 17:36:44 +0900,
Charlie Savage wrote in [ruby-core:21603]:

The problem is that mkmf calls Kernel::Sytem, which runs
commands in a subshell, which I'm going to guess is windows
command.exe. That of course breaks the build because paths
such as /usr/local/include no longer work.

try `RUBYSHELL=/bin/bash make'.

Ah. Fantastic, thanks.

Charlie

Attachment: smime.p7s
=end

Also available in: Atom PDF