Re: [RubyInstaller] Digest for rubyinstaller@googlegroups.com - 7 Messages in 2 Topics
Eric Promislow
What version of Ruby? The version of GCC and the options feed by Ruby
rbconfig are important.
> So in 3.4.5, gcc specifies an explicit path to cc1. In 4.5.0, it doesn't.
> If I add %DEVKIT%mingw\libexec\gcc\mingw32\4.5.0; to PATH, I can use
> gcc, but I see `gem install` is still broken.
You should not be playing with the PATH, officially only mingw/bin
needs to be added as the other paths are managed internally.
I don't think the ruby version is an issue -- the problem is completely with devkit 4.5.0
>gcc -v:
gcc version 4.5.0 (tdm-1)
Like I said, without modifying the path, I can't even compile a simple helloworld C
program. The problem is that gcc can't launch cc1.
Since seems you're using a Windows vista installation, would you mind
execute the same testing program with GCC 4.5.0 on a elevated command
prompt?
what I need to do here?
Jon <jon.f...@gmail.com> Sep 22 04:59PM -0400 ^
> Now run in 4.5.0, in a separate window with a clean environment:
> C:\Users\ericp\trash>which gcc
> C:\Devkit450\mingw\bin\gcc.EXE
In addition to Luis's feedback, for the above what else is on your PATH, in which environment are you running 'which', and do you have Cygwin installed?
PATH=c:\Devkit450\bin
c:\Devkit450\mingw\bin
c:\Ruby192\bin
C:\Python26\Scripts
C:\Python26
C:\apps\php-5.3.0-nts-vc9
C:\apps\php-5.3.0-nts
C:\apps\PHP-5.3
C:\Perl\site\bin
C:\Perl\bin
c:\apps\svn\bin
c:\bin
c:\Users\ericp\bin
C:\TclDevKit\bin
C:\Tcl\bin
c:\apps\git\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
Note that gcc is at the top of the list. I'm pretty sure the problem is that the gcc in
devkit 4.5.0 doesn't know how to launch cc1.
- Eric
Luis Lavena
<eric.pr...@gmail.com> wrote:
>
> I don't think the ruby version is an issue -- the problem is completely with
> devkit 4.5.0
>>gcc -v:
> ...
> Thread model: win32
> gcc version 4.5.0 (tdm-1)
> Like I said, without modifying the path, I can't even compile a simple
> helloworld C
> program. The problem is that gcc can't launch cc1.
As I mentioned before, this issue only happen under Vista for previous
GCC 3.4.5 r1 and r2, which was fixed in r3.
See this thread:
http://lists-archives.org/mingw-users/10261-3-4-5-mingw-vista-special-r2-still-broken-on-vista.html
>
> I run with admin privileges all the time -- could you be more specific about
> what I need to do here?
That means that the command prompt is elevated? You are running with
Admin rights? (UAC Stuff)
>
> I don't have a minimal path, but there's no cygwin in it. Again, here's my
> path:
>
> PATH=c:\Devkit450\bin
> c:\Devkit450\mingw\bin
> c:\Ruby192\bin
> C:\Python26\Scripts
> C:\Python26
> C:\apps\php-5.3.0-nts-vc9
> C:\apps\php-5.3.0-nts
> C:\apps\PHP-5.3
> C:\Perl\site\bin
> C:\Perl\bin
> c:\apps\svn\bin
> c:\bin
> c:\Users\ericp\bin
> C:\TclDevKit\bin
> C:\Tcl\bin
> c:\apps\git\bin
> C:\Windows\system32
> C:\Windows
> C:\Windows\System32\Wbem
>
> Note that gcc is at the top of the list. I'm pretty sure the problem is
> that the gcc in
> devkit 4.5.0 doesn't know how to launch cc1.
>
I don't have Vista to test this out, but again, sounds quite similar
to GCC 3.4.5 issue.
Please see the above thread I pointed out and try the things mentioned
by the authors.
Would suggest reporting it to mingw-users as I did.
--
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
Jon
> devkit 4.5.0
>
>
> > I don't have a minimal path, but there's no cygwin in it. Again, here's my
> path:
>
> that the gcc in devkit 4.5.0 doesn't know how to launch cc1.
Eric...this is maddening and it's a shame you're having to deal with the frustration.
Would you humor me and set the following PATH in a Command Prompt and see if you get the same failure? I'd like to convince myself that nothing else on PATH is messing things up.
PATH=c:\Devkit450\bin
c:\Devkit450\mingw\bin
c:\Ruby192\bin
c:\Windows\system32
c:\Windows
c:\Windows\System32\Wbem
Eventhough it's later in PATH, maybe "c:\apps\git\bin" could be a problem as there's a whole bunch of MSYS stuff in there (like sh.exe, etc) that could be hosing things. A stretch I know :( FWIW, I use the portable version of msysgit and put "c:\git\cmd" on PATH and don't have any problems. Let's see what happens on your system.
Jon
Eric Promislow
I ran filemon.exe to watch what's happening. The 3.4.5 gcc
find cc1.exe in the expected place, the 4.5.0 gcc doesn't.
I also ran `rebase -v 0x30000000 msys-1.0.dll`, with the
same results.
Luis Lavena
I know this will be annoying, but can you please provide the output as
indicated in the mingw-users thread I mentioned before?
http://lists-archives.org/mingw-users/10262-3-4-5-mingw-vista-special-r2-still-broken-on-vista.html
Thank you.
Jon
Luis Lavena <luisl...@gmail.com> wrote:
> On Mon, Sep 27, 2010 at 4:30 PM, Eric Promislow
> <eric.pr...@gmail.com> wrote:
> > I get the exact same result with that minimal path.
> >
> > I ran filemon.exe to watch what's happening. The 3.4.5 gcc
> > find cc1.exe in the expected place, the 4.5.0 gcc doesn't.
> >
> > I also ran `rebase -v 0x30000000 msys-1.0.dll`, with the
> > same results.
> >
>
> I know this will be annoying, but can you please provide the output as
> indicated in the mingw-users thread I mentioned before?
>
> http://lists-archives.org/mingw-users/10262-3-4-5-mingw-vista-special-r2-still-broken-on-vista.html
>
Ugh, this one's no fun at all.
After trying Luis' suggestion, would you add one more test to your Annoying Queue?
A quick check to see if anything else is living where msys-1.0.dll (non and rebased version) wants to live. Here's a memory map pic from my Win7 32-bit system http://www.mediafire.com/i/?cv2qq4ebzqne4t8 showing a typical working case.
1) Download VMMap from http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx and extract somewhere, say "C:\winsystools\vmmap"
2) Set up the same environment that fails...hopefully this means no other programs, shells, browsers, antivirus, etc. running.
3) Open a Command Prompt and type "\Devkit450\msys.bat" to bring up an MSYS shell.
4) run "vmmap.exe" from (1) and select the (hopefully only) "sh.exe" process
5) See if anything else lives at 60800000 (normal DevKit msys-1.0.dll location) or your rebased 30000000 location
Jon
Eric Promislow
Interesting output:
C:\Users\ericp\trash>set path=C:\Devkit450\bin;C:\Devkit450\mingw
\bin;c:\Ruby192
\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:
\Program Files\Wi
ndows Resource Kits\Tools
C:\Users\ericp\trash>set path
Path=C:\Devkit450\bin;C:\Devkit450\mingw\bin;c:\Ruby192\bin;C:\Windows
\system32;
C:\Windows;C:\Windows\System32\Wbem;C:\Program Files\Windows Resource
Kits\Tools
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.py;.pyw;.RB;.RBW
C:\Users\ericp\trash>set include
INCLUDE=C:\Program Files\Microsoft Visual Studio .NET 2003\SDK
\v1.1\include\
C:\Users\ericp\trash>set lib
LIB=C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\
C:\Users\ericp\trash>set include=
C:\Users\ericp\trash>set lib=
C:\Users\ericp\trash>gcc -v -o conftest conftest.c
Using built-in specs.
COLLECT_GCC=gcc
Target: mingw32
Configured with: ../../gcc-4.5.0/configure --prefix=/mingw --
build=mingw32 --ena
ble-languages=c,ada,c++,fortran,objc,obj-c++ --disable-nls --disable-
win32-regis
try --enable-libgomp --disable-werror --enable-threads --disable-
symvers --enabl
e-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-
dynamic-s
tring --enable-libstdcxx-debug --enable-version-specific-runtime-libs
--with-pkg
version=tdm-1 --enable-sjlj-exceptions --with-bugurl=http://tdm-
gcc.tdragon.net/
bugs
gcc version 4.5.0 (tdm-1)
march=i386'
cc1 -quiet -v -iprefix c:\devkit450\mingw\bin\../lib/gcc/
mingw32/4.5.0/ conftes
t.c -quiet -dumpbase conftest.c -mtune=i386 -march=i386 -auxbase
conftest -versi
on -o C:\Users\ericp\AppData\Local\Temp\ccv77InK.s
gcc: CreateProcess: No such file or directory
C:\Users\ericp\trash>gcc -print-search-dirs
install: c:\devkit450\mingw\bin\../lib/gcc/mingw32/4.5.0/
programs: =c:/devkit450/mingw/libexec/gcc/mingw32/4.5.0/;c:/devkit450/
mingw/libe
xec/gcc/;c:/devkit450/mingw/mingw32/bin/mingw32/4.5.0/;c:/devkit450/
mingw/mingw3
2/bin/
libraries: =c:/devkit450/mingw/lib/gcc/mingw32/4.5.0/;c:/devkit450/
mingw/lib/gcc
/;c:/devkit450/mingw/mingw32/lib/mingw32/4.5.0/;c:/devkit450/mingw/
mingw32/lib/;
c:/devkit450/mingw/lib/mingw32/4.5.0/;c:/devkit450/mingw/lib/;/mingw/
lib/mingw32
/4.5.0/;/mingw/lib/
From a different window (so I can use ls with fwd slashes):
C:\Users\ericp\svn\apps\komodo>ls c:/devkit450/mingw/libexec/gcc/
mingw32/4.5.0/
cc1.exe install-tools libgmpxx-4.dll libmpfr-1.dll lto-
wrapper.exe
cc1plus.exe libcloog-0.dll libiconv-2.dll libppl-7.dll
collect2.exe libgmp-3.dll libmpc-2.dll libppl_c-2.dll
=======================================================
So it's clear that cc1.exe is in gcc's list of "program dirs".
Permissions aren't an issue -- if I explicitly add the
dir c:/devkit450/mingw/libexec/gcc/mingw32 to PATH I can
build with no problems.
I even compared the output of gcc --print-search-dirs in the two
environments, removed all the non-windows paths, and normalized
the results to make them easier to compare, and I don't see
any differences:
3.4.5 output (which works):programs: =
C:/devkit-3.4.5/mingw/libexec/gcc/mingw32/3.4.5/
C:/devkit-3.4.5/mingw/libexec/gcc/
C:/devkit-3.4.5/mingw/mingw32/bin/mingw32/3.4.5/
C:/devkit-3.4.5/mingw/mingw32/bin/
libraries: =
C:/devkit-3.4.5/mingw/lib/gcc/mingw32/3.4.5/
C:/devkit-3.4.5/mingw/lib/gcc/
C:/devkit-3.4.5/mingw/mingw32/lib/mingw32/3.4.5/
C:/devkit-3.4.5/mingw/mingw32/lib/
C:/devkit-3.4.5/mingw/lib/mingw32/3.4.5/
C:/devkit-3.4.5/mingw/lib/
4.5.0 output (doesn't work):
programs: =
c:/devkit450/mingw/libexec/gcc/mingw32/4.5.0/
c:/devkit450/mingw/libexec/gcc/
c:/devkit450/mingw/mingw32/bin/mingw32/4.5.0/
c:/devkit450/mingw/mingw32/bin/
libraries: =
c:/devkit450/mingw/lib/gcc/mingw32/4.5.0/
c:/devkit450/mingw/lib/gcc/
c:/devkit450/mingw/mingw32/lib/mingw32/4.5.0/
c:/devkit450/mingw/mingw32/lib/
c:/devkit450/mingw/lib/mingw32/4.5.0/
c:/devkit450/mingw/lib/
I'm wondering if we're running into the DOS command-line length limit.
It could happen if there are a lot of unnormalized "foo/../"
constructs in the path.
- Eric
On Sep 27, 12:49 pm, Luis Lavena <luislav...@gmail.com> wrote:
> On Mon, Sep 27, 2010 at 4:30 PM, Eric Promislow
>
> > I get the exact same result with that minimal path.
>
> > I ran filemon.exe to watch what's happening. The 3.4.5 gcc
> > find cc1.exe in the expected place, the 4.5.0 gcc doesn't.
>
> > I also ran `rebase -v 0x30000000 msys-1.0.dll`, with the
> > same results.
>
> I know this will be annoying, but can you please provide the output as
> indicated in the mingw-users thread I mentioned before?
>
Jon
I had hoped to overlay DevKit 3.4.5 on top of my Ruby192 and investigate, but haven't found the time yet...hopefully later today.
Jon
Eric Promislow
c:\Ruby192\bin>path
PATH=C:\Devkit450\bin;
c:\Ruby192\bin;
C:\Windows\system32;
C:\Windows
c:\Ruby192\bin>ls *.bat
erb.bat irb.bat rdiscount.bat ri.bat testrb.bat
gem.bat rake.bat rdoc.bat setrbvars.bat
Jon
> PATH=C:\Devkit450\bin;
> C:\Devkit450\mingw\bin;
> c:\Ruby192\bin;
> C:\Windows\system32;
> C:\Windows
>
> [I broke the output up on multiple lines for readability]
>
> c:\Ruby192\bin>ls *.bat
> erb.bat irb.bat rdiscount.bat ri.bat testrb.bat
> gem.bat rake.bat rdoc.bat setrbvars.bat
So much for easy :(
This is a stretch, but any chance there's something lurking in C:\Windows or C:\Windows\system32? And I bet it's not environment variables causing problems with just gcc 4.5.0 -> http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
Hmmm...
FYI, I just overlaid DevKit 3.4.5 on my 1.9.2 install with the following PATH and things worked fine for both rdiscount install and basic usage:
C:\Users\Jon>echo %PATH%
C:\DevKit\bin;C:\DevKit\mingw\bin;C:\ruby192\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
So, is this a summary of all the things we've tried so far with no luck?
1) Minimal PATH of just DevKit 4.5.0 dirs, Ruby192 bindir, and basic Vista system dirs (no Cygwin, no git\bin, and no other msys\mingw artifacts)
2) Normal and elevated UAC Command Prompt usage
3) Normal and rebased (30000000) msys-1.0.dll
4) Visual check with vmmap.exe to ensure nothing else (e.g. - antivirus) is living where msys-1.0.dll wants to live
5) gcc -v and -print-search-dirs investigation
6) filemon.exe investigation in which cc1.exe isn't found
Luis Lavena
>> c:\Ruby192\bin>path
>> PATH=C:\Devkit450\bin;
>> C:\Devkit450\mingw\bin;
>> c:\Ruby192\bin;
>> C:\Windows\system32;
>> C:\Windows
>>
>> [I broke the output up on multiple lines for readability]
>>
>> c:\Ruby192\bin>ls *.bat
>> erb.bat irb.bat rdiscount.bat ri.bat testrb.bat
>> gem.bat rake.bat rdoc.bat setrbvars.bat
>
> So much for easy :(
>
> This is a stretch, but any chance there's something lurking in C:\Windows or C:\Windows\system32? And I bet it's not environment variables causing problems with just gcc 4.5.0 -> http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
>
> Hmmm...
>
> FYI, I just overlaid DevKit 3.4.5 on my 1.9.2 install with the following PATH and things worked fine for both rdiscount install and basic usage:
>
Hey Guys,
I think this is turning into a a never ending story. The clear issue
here is Windows Vista and we can't reproduce without it.
Now having Eric information as similarly requested to me by TDM, we
can ask mingw-users about it.
Just for the record, Eric would you mind fill in the form I sent a few
days ago (in case you haven't)
https://spreadsheets.google.com/viewform?formkey=dG1DajlXc0luLTNKdUhYOWRlZ2FleVE6MQ
Jon
>
> 1) Minimal PATH of just DevKit 4.5.0 dirs, Ruby192 bindir, and basic Vista system dirs (no Cygwin, no git\bin, and no other msys\mingw artifacts)
>
> 2) Normal and elevated UAC Command Prompt usage
>
> 3) Normal and rebased (30000000) msys-1.0.dll
>
> 4) Visual check with vmmap.exe to ensure nothing else (e.g. - antivirus) is living where msys-1.0.dll wants to live
>
> 5) gcc -v and -print-search-dirs investigation
>
> 6) filemon.exe investigation in which cc1.exe isn't found
forgot one...
7) Confirmed that no C:\DevKit450\etc\fstab was (unnecessarily) created
Jon
I don't know if you've seen this [1] thread, but could you try building a TDM 4.5.1 based DevKit and see if it solves what looks to be a Vista interaction issue?
1) Clone our repo http://github.com/oneclick/rubyinstaller
2) Put http://gist.github.com/562679 into a <RUBYINSTALLER_REPO_ROOT>\override\build_config.rb file
3) Run "rake devkit sfx=1 override=1" from within <RUBYINSTALLER_REPO_ROOT> and try the generated DevKit (incorrectly named) in <RUBYINSTALLER_REPO_ROOT>\pkg.
Note that this will create a TDM 4.5.1 built rdiscount.so to run against a TDM 4.5.0 ruby192 install, but I don't think (hope) that will be a source of problems.
If you need me to build you a copy, contact me offlist.
Jon
[1] http://groups.google.com/group/rubyinstaller/browse_thread/thread/c198ff7f27149fd8
Eric Promislow
home.
- Eric
On Oct 1, 8:08 am, Jon <jon.for...@gmail.com> wrote:
> Eric,
>
> I don't know if you've seen this [1] thread, but could you try building a TDM 4.5.1 based DevKit and see if it solves what looks to be a Vista interaction issue?
>
> 1) Clone our repohttp://github.com/oneclick/rubyinstaller
>
> Note that this will create a TDM 4.5.1 built rdiscount.so to run against a TDM 4.5.0 ruby192 install, but I don't think (hope) that will be a source of problems.
>
> If you need me to build you a copy, contact me offlist.
>
> Jon
>
Jon
I've since pushed a new "dk32-451" branch [1] to the repo which you can use to build the 4.5.1 DevKit rather than the previous override instructions.
Jon
[1] http://github.com/oneclick/rubyinstaller/tree/dk32-451
> --
> You received this message because you are subscribed to the Google Groups "RubyInstaller" group.
> To post to this group, send email to rubyin...@googlegroups.com.
> To unsubscribe from this group, send email to rubyinstalle...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rubyinstaller?hl=en.
>
Jon
vo.x
case? I see you are setting path like C:\Devkit450 but all the
utilities returns c:\devkit450 etc. I know Windows are not case
sensitive, but it might happen that some tool coming from linux is
doing some case sensitive comparison.
Vit