Bug #7660

VC Builds Broken

Added by Charlie Savage over 1 year ago. Updated about 1 year ago.

[ruby-core:51262]
Status:Rejected
Priority:High
Assignee:Usaku NAKAMURA
Category:build
Target version:2.0.0
ruby -v:1.9.3 p362 and ruby trunk Backport:

Description

Ruby 1.9.3 p362 and Ruby 2.0.0 can no longer be build with VC 2010, while Ruby 1.9.3 p286 and earlier are fine. The problem is with win32/file, which is compiled twice while ruby/file is not compiled at all. Looks like something changed in the makefiles betweeen p286 and p362.

Here are the relevant parts of the log:

c:\MinGW\local\src\ruby\win32>nmake

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.

    CC = cl -nologo
    LD = cl -nologo
    LDSHARED = cl -nologo -LD
    CFLAGS = -MD -Zi -W2 -wd4996 -we4028 -we4142 -O2sy-  -Zm600
    XCFLAGS = -DRUBY_EXPORT -I. -I.ext/include/i386-mswin32_100 -I./../include -I./.. -I./../missing
    CPPFLAGS =
    DLDFLAGS = -incremental:no -debug -opt:ref -opt:icf -dll
    SOLIBS =

Creating config.h
.ext\include\i386-mswin32_100\ruby\config.h unchanged.
Creating verconf.h
verconf.h unchanged.
Creating config.status
compiling ./../main.c
main.c

compiling file.c
file.c
compiling ./../gc.c
gc.c

compiling ./../win32/file.c
file.c

oldnames.lib user32.lib advapi32.lib shell32.lib ws232.lib imagehlp.lib shlwapi.lib
linking miniruby.exe
file.obj : error LNK2005: _rb
fileexpandpathinternal already defined in file.obj
file.obj : error LNK2005: _rb
fileloadok already defined in file.obj
file.obj : error LNK2005: rbw32initfile already defined in file.obj
dir.obj : error LNK2019: unresolved external symbol rbstrencodeospath referenced in function dirinitialize
io.obj : error LNK2001: unresolved external symbol rbstrencodeospath
ruby.obj : error LNK2001: unresolved external symbol rbstrencodeospath
iseq.obj : error LNK2001: unresolved external symbol rbgetpath
dir.obj : error LNK2019: unresolved external symbol _rb
getpath referenced in function _dirinitialize
load.obj : error LNK2001: unresolved external symbol rbgetpath
io.obj : error LNK2001: unresolved external symbol _rb
getpath
process.obj : error LNK2001: unresolved external symbol _rb
getpath
dir.obj : error LNK2019: unresolved external symbol _rb
encpathend referenced in function checkdirname
dir.obj : error LNK2019: unresolved external symbol rbencpathskipprefix referenced in function _checkdirname
dir.obj : error LNK2019: unresolved external symbol rbgetpathnochecksafe referenced in function _filesfnmatch
dir.obj : error LNK2019: unresolved external symbol _rb
homedir referenced in function _dirshome
dir.obj : error LNK2019: unresolved external symbol _rb
fileconst referenced in function _InitDir
dir.obj : error LNK2001: unresolved external symbol rbcFile
io.obj : error LNK2001: unresolved external symbol rbcFile
dir.obj : error LNK2019: unresolved external symbol rbfiledirectoryp referenced in function InitDir
dlnfind.obj : error LNK2019: unresolved external symbol _eaccess referenced in function _dlnfind1
eval.obj : error LNK2019: unresolved external symbol _rb
filedirname referenced in function _fcurrentdirname
load.obj : error LNK2001: unresolved external symbol _rb
filedirname
load.obj : error LNK2019: unresolved external symbol _rb
fileexpandpathfast referenced in function
_rb
constructexpandedloadpath
load.obj : error LNK2019: unresolved external symbol _rb
getpathcheckconvert referenced in function _rbconstructexpandedloadpath
load.obj : error LNK2019: unresolved external symbol _rb
isabsolutepath referenced in function rbconstructexpandedloadpath
load.obj : error LNK2019: unresolved external symbol _rb
getpathchecktostring referenced in function rbconstructexpandedloadpath
load.obj : error LNK2019: unresolved external symbol _rb
realpathinternal referenced in function _rbloadinternal
ruby.obj : error LNK2001: unresolved external symbol _rb
realpathinternal
iseq.obj : error LNK2001: unresolved external symbol _rb
realpathinternal
load.obj : error LNK2019: unresolved external symbol _rb
findfileextsafe referenced in function _searchrequired
load.obj : error LNK2019: unresolved external symbol rbfindfilesafe referenced in function searchrequired
load.obj : error LNK2019: unresolved external symbol rbfindfile referenced in function _rbload
load.obj : error LNK2019: unresolved external symbol rbfileabsolutepath referenced in function rbfrequirerelative
hash.obj : error LNK2019: unresolved external symbol rbpathcheck referenced in function _pathtaintedp
io.obj : error LNK2019: unresolved external symbol _Init
File referenced in function InitIO
ruby.obj : error LNK2019: unresolved external symbol rbfileexpandpath referenced in function expandinclude_path
miniruby.exe : fatal error LNK1120: 23 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\cl.EXE"' : return code '0x2'
Stop.

History

#1 Updated by Charlie Savage over 1 year ago

Looks like the issue is these two rules:

{$(srcdir)}.c{}.obj:
$(ECHO) compiling $(<:\=/)
$(Q) $(CC) $(CFLAGS) $(XCFLAGS) $(CPPFLAGS) $(COUTFLAG)$@ -c -Tc$(<:\=/)
.c.obj:
$(ECHO) compiling $(<:\=/)
$(Q) $(CC) $(CFLAGS) $(XCFLAGS) $(CPPFLAGS) $(COUTFLAG)$@ -c -Tc$(<:\=/)

Instead of file.c being compiled by the first rules, its being compiled by the second one (note that the working directory for running nmake is ruby/win32). Flipping them solves the problem, but then looks like the wrong version of miniprelude is compiled (the ruby one, not ruby/win32 one).

#2 Updated by Charlie Savage over 1 year ago

Simply removing this rule:

.c.obj:
$(ECHO) compiling $(<:\=/) $(Q) $(CC) $(CFLAGS) $(XCFLAGS) $(CPPFLAGS) $(COUTFLAG)$@ -c -Tc$(<:\=/)

Solves the problem.

#3 Updated by Luis Lavena over 1 year ago

  • Category set to build
  • Status changed from Open to Assigned
  • Assignee set to Usaku NAKAMURA

#4 Updated by Charlie Savage about 1 year ago

Any updates on this?

#5 Updated by Usaku NAKAMURA about 1 year ago

  • Status changed from Assigned to Rejected

=begin
at the bottom win32/README.w32 of trunk:
You can build ruby in any directory including the source directory,
except (({win32})) directory in the source directory.
Maybe I should backport this comment to 1.9.3 :P
=end

#6 Updated by Charlie Savage about 1 year ago

I see, missed that note. Since this is a recent change in 1.9.3 I think it should be backported.

However, my proposed allows building from the win32 directory. It also works when building from the top level directory. Do you think it breaks some cases? If not, then why not apply it?

Thanks - Charlie

Also available in: Atom PDF