Project

General

Profile

Actions

Feature #3943

closed

enabling builds with llvm-gcc

Added by jonforums (Jon Forums) over 13 years ago. Updated almost 13 years ago.

Status:
Closed
[ruby-core:32776]

Description

=begin
Recently I've made progress on building trunk using an MSYS + llvm-gcc v2.8 toolchain (Win7 32-bit Ultimate) but have run into a couple of issues I believe could be resolved via autotools mods. Unfortunately, I lack the expertise needed to submit a patch for your review and, sadly, lack the time/desire to invest in autotools as CMake and waf meet my needs.

The current build failures appear to be caused by the generated GNUMakefile. Specifically, the current failures [1] (bottom file) are caused by "dllwrap" and "windres" invocations in GNUMakefile [1] (e.g. - lines 5, 41, 80) not using the correct driver program when "configure" is given env vars of CC=llvm-gcc, CXX=llvm-g++, and CPP=llvm-cpp. The fix is simply to give dllwrap a --driver-name option and windres a --preprocessor option and optionally a -DRC_INVOKED. There may be other required fixes after these two have been solved.

FYIW, I've tested these types of fixes by patching makefile's for Vim [2] and the RubyInstaller build recipe [3] for the OpenSSL dependency.

As I've recently updated the RubyInstaller build recipes to support building on Windows with multiple gcc-based toolchains [4] my goal is to resolve the few remaining build config issues so that MRI Ruby can be built with llvm-gcc (and others) on both Windows and *nix systems.

What specifically am I requesting?

I'm requesting the maintainer of ruby-core's build system work with me to resolve any configure.in, config.guess, config.sub, and any other issues that currently prevent llvm-gcc based builds. I can offer quick testing and feedback of any changes on a Win7 32-bit system as the RubyInstaller recipe mods [4] allow me to quickly build an MRI Ruby trunk from source (with dependencies) as simply as:

rake ruby19 local="C:\ruby-git-repo" dkver=llvm-32-2.8

Please feel free to contact me offline or reply if more info is needed.

Thank you,
Jon

[1] http://gist.github.com/624215
[2] http://code.google.com/p/vim/source/browse/src/Make_ming.mak#306
[3] http://github.com/oneclick/rubyinstaller/blob/dk32-451/recipes/dependencies/openssl.rake#L60-L68
[4] http://github.com/oneclick/rubyinstaller/compare/master...dk32-451
=end


Files


Related issues 1 (0 open1 closed)

Related to Ruby master - Bug #17602: MinGW builds failing - binutils-2.36 ?ClosedActions
Actions #1

Updated by naruse (Yui NARUSE) over 13 years ago

  • Category set to build
  • Status changed from Open to Assigned
  • Assignee set to nobu (Nobuyoshi Nakada)

=begin

=end

Actions #2

Updated by nobu (Nobuyoshi Nakada) over 13 years ago

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

=begin
This issue was solved with changeset r29516.
Jon, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

=end

Actions #3

Updated by jonforums (Jon Forums) over 13 years ago

=begin
Nakada-san,

Thank you, r29516 allows building trunk on Win7 32-bit using the RubyInstaller recipes and llvm-gcc v2.8. As a quick build regression test, I successfully built with r29517 on my Arch Linux system (gcc 4.5.1) and MSYS/MinGW/TDM 4.5.1 on my Win7 32-bit system. I will try your patch on ruby_1_9_2 and report back if there are any errors.

FYI, I noticed the following issues and will track them down and report back if needed.

Jon

ISSUE 1

...
windres --preprocessor="llvm-cpp -xc" -DRC_INVOKED --include-dir . --include-dir . --include-dir ../../../ruby-trunk/win32 ruby.rc ruby.res.o
llvm-gcc -O3 -g -Wextra -Wno-unused-parameter -Wno-parentheses -Wpointer-arith -Wwrite-strings -Wno-missing-field-initializers -Wshorten-64-to-32 -Wno-long-long -L. -Wl,--stack,0x00200000,--enable-auto-import main.o ruby.res.o -lmsvcrt-ruby191 -lshell32 -lws2_32 -limagehlp -o ruby.exe
C:\Users\Jon\Documents\RubyDev\rubyinstaller-trunk\sandbox\devkit\mingw\bin/ld.exe: Warning: type of symbol `_main' changed from 32 to 512 in main.o

ISSUE 2

...
windres --preprocessor="llvm-cpp -xc" -DRC_INVOKED --include-dir . --include-dir . --include-dir ../../../ruby-trunk/win32 rubyw.rc rubyw.res.o
llvm-gcc -mwindows -e _mainCRTStartup -O3 -g -Wextra -Wno-unused-parameter -Wno-parentheses -Wpointer-arith -Wwrite-strings -Wno-missing-field-initializers -Wshorten-64-to-32 -Wno-long-long -L. -Wl,--stack,0x00200000,--enable-auto-import
main.o rubyw.res.o -lmsvcrt-ruby191 -lshell32 -lws2_32 -limagehlp -o rubyw.exe
llvm-gcc.exe: unrecognized option '-e'
=end

Actions #4

Updated by jonforums (Jon Forums) over 13 years ago

=begin
Unsurprisingly, the attached backport patch for ruby_1_9_2 also works for me and also results in the previously mentioned warning issues.

Jon
=end

Actions #5

Updated by kosaki (Motohiro KOSAKI) over 13 years ago

  • Status changed from Closed to Assigned
  • Assignee changed from nobu (Nobuyoshi Nakada) to yugui (Yuki Sonoda)
  • Target version set to 1.9.2

=begin
ok, reopened and assigned to yugui-san.

=end

Actions #6

Updated by jonforums (Jon Forums) over 13 years ago

=begin
Just to be clear, I don't think these 2 warning issues are serious and other than the unrecognized option '-e' issue and whether the patch should be backported (ruby-core decisions), I think it's my responsibility to track down the other warning regarding '_main' symbol type changing and report back to ruby-core.

I also want to test on ruby_1_8_7 and do further testing, but I feel these are separate issues.

Thank you,
Jon

=end

Actions #7

Updated by yugui (Yuki Sonoda) over 13 years ago

  • Status changed from Assigned to Closed

=begin
This issue was solved with changeset r29566.
Jon, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

=end

Actions #8

Updated by nobu (Nobuyoshi Nakada) about 3 years ago

  • Related to Bug #17602: MinGW builds failing - binutils-2.36 ? added
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0