Project

General

Profile

Actions

Bug #1060

closed

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

Added by cfis (Charlie Savage) over 13 years ago. Updated about 11 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 <winsock2.h>
4: #include <windows.h>
5: #include <tcl.h>
/
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
Actions #1

Updated by cfis (Charlie Savage) over 13 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

Actions #2

Updated by cfis (Charlie Savage) over 13 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

Actions #3

Updated by luislavena (Luis Lavena) over 13 years ago

=begin
On Tue, Jan 27, 2009 at 3:13 PM, Charlie Savage 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

Actions #4

Updated by nobu (Nobuyoshi Nakada) over 13 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

Actions #5

Updated by yugui (Yuki Sonoda) over 13 years ago

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

=begin

=end

Actions #6

Updated by nobu (Nobuyoshi Nakada) over 13 years ago

  • Status changed from Open to Rejected

=begin

=end

Actions #7

Updated by cfis (Charlie Savage) over 13 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

Actions

Also available in: Atom PDF