Ruby-Debug-IDE problem ~~ RubyInstaller DevKit - Native build
will
I have cleanly (re-)installed both Ruby 1.9.2 and DevKit (most recent
numerical soup) and successfully had a test compile with RDiscount.
I have now had a problem with building the Ruby-debug-ide module used
with Eclipse and Netbeans. Please review the bug report on Rubyforge.
* (windows) RubyInstaller DevKit - Native build
** http://rubyforge.org/tracker/index.php?func=detail&aid=28963&group_id=9442&atid=36509
Key things to note are that the hosting Gem is really Ruby-debug-ide
* https://rubygems.org/gems/ruby-debug-ide
The LineCache gem failed all by itself as an individual Gem Install.
I'm using Windows/XP Sp1, ruby 1.9.2 and DevKit-
tdm-32-4.5.1-20101214-1400-sfx.exe
All tested up tyo the build RDiscount stage.
May be someone has a patch for the Ruby-Debug-IDE or LineCache people.
Cheers,
Will
Luis Lavena
> Good day everyone,
>
> I have cleanly (re-)installed both Ruby 1.9.2 and DevKit (most recent
> numerical soup) and successfully had a test compile with RDiscount.
>
> I have now had a problem with building the Ruby-debug-ide module used
> with Eclipse and Netbeans. Please review the bug report on Rubyforge.
>
With Ruby 1.9.2 you need linecache19 or ruby-debug19
Also, install them from command line, ruby-debug19 downloads Ruby
source code to be able to use the headers and that can take some time
(you need an active internet connection)
--
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
* William
Unfortunately that isn't the solution for that problem. Or, if it is supposed to be, then the DevKit builder doesn't work with the linecache19.
A second issue is that the ruby-debug19 tries to build linecache (no "19"). So that's likely to be a problem too.
I went forward and ran the linecache19 all by itself.
- gem install linecache19
That in itself is odd because why does the DEF work for one gem and not for others?
Hope this shows some of you guys how to resolve this one.
Cheers,
Will
On Wed, Feb 23, 2011 at 12:41 PM, will <william....@gmail.com> wrote:
> Good day everyone,
>
> I have cleanly (re-)installed both Ruby 1.9.2 and DevKit (most recent
> numerical soup) and successfully had a test compile with RDiscount.
>
> I have now had a problem with building the Ruby-debug-ide module used
> with Eclipse and Netbeans. Please review the bug report on Rubyforge.
>
With Ruby 1.9.2 you need linecache19 or ruby-debug19
Also, install them from command line, ruby-debug19 downloads Ruby
source code to be able to use the headers and that can take some time
(you need an active internet connection)
--
Temporarily enhancing PATH to include DevKit...
Building native extensions. This could take a while...
ERROR: Error installing linecache19:
ERROR: Failed to build gem native extension.
c:/bin/ruby/v1.9/bin/ruby.exe extconf.rb
checking for vm_core.h... no
checking for vm_core.h... yes
checking for version.h... yes
checking for RUBY_VERSION_MAJOR in version.h... yes
creating Makefile
make
gcc -I. -Ic:/bin/ruby/v1.9/include/ruby-1.9.1/i386-mingw32 -I/c/bin/ruby/v1.9/include/ruby-1.9.1/ruby/backward -I/c/bin/ruby/v1.9/include/ruby-1.9.1 -I. -DHAVE_VM_CORE_H -DHAVE_VERSION_H -Ic:/bin/ruby
/v1.9/include/ruby-1.9.1/ruby-1.9.2-p180 -O3 -g -Wextra -Wno-unused-parameter -Wno-parentheses -Wpointer-arith -Wwrite-strings -Wno-missing-field-initializers -Wno-long-long -o trace_nums.o -c trace_
nums.c
gcc -shared -s -o trace_nums19.so trace_nums.o -L. -Lc:/bin/ruby/v1.9/lib -L. -Wl,--enable-auto-image-base,--enable-auto-import trace_nums19-i386-mingw32.def -lmsvcrt-ruby191 -lshell32 -lws2_32
c:/bin/ruby/devkit/mingw/bin/../lib/gcc/mingw32/4.5.1/../../../../mingw32/bin/ld.exe: trace_nums19-i386-mingw32.def:1: syntax error
trace_nums19-i386-mingw32.def: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [trace_nums19.so] Error 1
Gem files will remain installed in c:/bin/ruby/v1.9/lib/ruby/gems/1.9.1/gems/linecache19-0.5.11 for inspection.
Results logged to c:/bin/ruby/v1.9/lib/ruby/gems/1.9.1/gems/linecache19-0.5.11/ext/trace_nums/gem_make.out
Luis Lavena
> Thank you for the comment Luis.
>
> Unfortunately that isn't the solution for that problem. Or, if it is
> supposed to be, then the DevKit builder doesn't work with the linecache19.
>
> A second issue is that the ruby-debug19 tries to build linecache (no "19").
> So that's likely to be a problem too.
>
> I went forward and ran the linecache19 all by itself.
>
> gem install linecache19
>
> I've pasted the transcript below. As before, I've got windows/xp sp3 and
> ruby 1.9.2 p180. The Rdiscount build worked when installing DevKit but this
> build fails again with a DEF file problem.
>
> That in itself is odd because why does the DEF work for one gem and not for
> others?
>
I think there is something odd with your installation.
def files are one liner that contains only "Init_xxxx" as export symbol.
Please tell if you have other installations of Ruby, MinGW, MSYS or
Cygwin in the PATH?
I believe you already mentioned having other MinGW installations.
Please ensure none of them are interfering, none of the items
mentioned in the Troubleshooting page is interfering and provide all
the details mentioned there when you report an issue to the list.
> Hope this shows some of you guys how to resolve this one.
>
I was able to install it without issues, and again linecache19 is a
dependency of ruby-debug19:
https://gist.github.com/841479
linecache19 installation takes a REALLY LONG TIME to install because
is going to download the ruby source code of your ruby version and
then attempt to compile against it (ruby_core_source dependency does
that)
However, is not clear what happens when the download fails or is corrupt.
* William
I want to clear some air. You appear to perceive me as a neophyte Intel based developer. A DEF file is part of the Intel x86 specification for a very pleasant OO macro (assembler) language it is not a "one liner". It should deliver the symbolic binary equivalent for a object file. On linux and unix systems that's a ".o" or "liba" and on windows, it's ".obj", ".lib" and ".dll".
If you have been around long enough to see the COM+ and other inter-process communication examples with Microsoft or even unix (not too much Linux), you may note that the DEF file is a logical equivalent for a CORBA IDL file.
LL>> I think there is something odd with your installation.
From my side. I don't mind accepting that my system may be 'different' to a net-PC. The purpose to report bugs is to share information about things that don't happen they way one (such as me) expects them to...
As a past-life successful support engineer I really advise you that to "blame the messenger" is never going to resolve whatever the issue is. My customers were always satisfied with my queries and the resolutions I worked through always respected that 'home base' didn't match the field conditions. May be my perception here is that you are not young (under 30). In which case, I regret being gentle in reply.
At one point you mention that ..
>> linecache19 installation takes a REALLY LONG TIME to install because
>> is going to download the ruby source code of your ruby version and
Apart from anything else my earlier description gave the list accurate information. Again ...
- ruby-debug19 tries to build linecache
- To be completely and utterly clear Ruby-debug19 did not attempt to build "linecache19") as implied or imagined.
- That was the latest (then) gem from RubyGems.org (see email date and subtract a few minutes).
- The bug I reported actually concerned ONLY installing linecache19.
- Which didn't work with the DevKit that does work with RDiscount.
- That is why I bothered to report BOTH bugs.
- I did not disclose details like having Mingw installed so someone may go all Freudian and 'blame the victim' here. OK. I have two lifetimes of experience in bug tracking and fixing. It is Sunday and DevKit users (the DevKit customers, and me personally) I don't appreciate or need a slap in the face when ...
- We/I put in the extra effort into supplying information that WILL help and inform the team about conditions in the REAL world outside a well set-up and honed development lab.
- I've spent over 30 years developing robust software that doesn't sneeze the first time it feels a draft.
- Good software copes. At least if fails gracefully when it can't.
- If good software needs to deploy or sustain 3rd party gems and exogenous material -- Design accommodates such contingencies.
- I admire m. Antoine de Saint-Exupéry, and if asked I'd confess to implementing that edict life-long. After Albert Einstein: "As simple as it can be and no simpler." (mistakes alll mine).
- Ipso facto: a reply blaming my system is asking me, "why" the DevKit can't cope or is victimies by dumb-blond MS-Dos command structures?
- A better example might be as suggested earlier: Use Rake for the devkit and aim for effectiveness, and not aim at proficiency. (Or another ruby based tool).
AND, I believe most people do. That's my expectation based on endless discussions about why gems on Windows are 'bad' from people who (I believe) just what functionality. Not explanations. Gee if I wanted explainations, ... I'd got to Nokia, Apple or Microsoft.
Will
;-)
Boško Ivanišević
Hi ya ...
I want to clear some air. You appear to perceive me as a neophyte Intel based developer. A DEF file is part of the Intel x86 specification for a very pleasant OO macro (assembler) language it is not a "one liner". It should deliver the symbolic binary equivalent for a object file. On linux and unix systems that's a ".o" or "liba" and on windows, it's ".obj", ".lib" and ".dll".
If you have been around long enough to see the COM+ and other inter-process communication examples with Microsoft or even unix (not too much Linux), you may note that the DEF file is a logical equivalent for a CORBA IDL file.
LL>> I think there is something odd with your installation.
From my side. I don't mind accepting that my system may be 'different' to a net-PC. The purpose to report bugs is to share information about things that don't happen they way one (such as me) expects them to...
As a past-life successful support engineer I really advise you that to "blame the messenger" is never going to resolve whatever the issue is. My customers were always satisfied with my queries and the resolutions I worked through always respected that 'home base' didn't match the field conditions. May be my perception here is that you are not young (under 30). In which case, I regret being gentle in reply.
At one point you mention that ..Gee. I have clients still dial-up modems in third world countries. How do you figure that? Is Ruby only for the rich and endowed?! (sarcasm explicit)
>> linecache19 installation takes a REALLY LONG TIME to install because
>> is going to download the ruby source code of your ruby version and
Apart from anything else my earlier description gave the list accurate information. Again ...On a more practical note .. posting transcripts to github of successful builds is like late night informercials showing me a slim guy with great abs. So what! I'm not a trim athletic type. I just want Gems and Widget things like the RubyInstall Dev Kit to work.
- ruby-debug19 tries to build linecache
- To be completely and utterly clear Ruby-debug19 did not attempt to build "linecache19") as implied or imagined.
- That was the latest (then) gem from RubyGems.org (see email date and subtract a few minutes).
- The bug I reported actually concerned ONLY installing linecache19.
- Which didn't work with the DevKit that does work with RDiscount.
- That is why I bothered to report BOTH bugs.
- I did not disclose details like having Mingw installed so someone may go all Freudian and 'blame the victim' here. OK. I have two lifetimes of experience in bug tracking and fixing. It is Sunday and DevKit users (the DevKit customers, and me personally) I don't appreciate or need a slap in the face when ...
- We/I put in the extra effort into supplying information that WILL help and inform the team about conditions in the REAL world outside a well set-up and honed development lab.
- I've spent over 30 years developing robust software that doesn't sneeze the first time it feels a draft.
- Good software copes. At least if fails gracefully when it can't.
- If good software needs to deploy or sustain 3rd party gems and exogenous material -- Design accommodates such contingencies.
- I admire m. Antoine de Saint-Exupéry, and if asked I'd confess to implementing that edict life-long. After Albert Einstein: "As simple as it can be and no simpler." (mistakes alll mine).
- Ipso facto: a reply blaming my system is asking me, "why" the DevKit can't cope or is victimies by dumb-blond MS-Dos command structures?
- A better example might be as suggested earlier: Use Rake for the devkit and aim for effectiveness, and not aim at proficiency. (Or another ruby based tool).
AND, I believe most people do. That's my expectation based on endless discussions about why gems on Windows are 'bad' from people who (I believe) just what functionality. Not explanations. Gee if I wanted explainations, ... I'd got to Nokia, Apple or Microsoft.
--
Regards,
Boško Ivanišević
Luis Lavena
> Hi ya ...
>
> I want to clear some air. You appear to perceive me as a neophyte Intel
> based developer. A DEF file is part of the Intel x86 specification for a
> very pleasant OO macro (assembler) language it is not a "one liner". It
> should deliver the symbolic binary equivalent for a object file. On linux
> and unix systems that's a ".o" or "liba" and on windows, it's ".obj", ".lib"
> and ".dll".
>
I believe you're mistakenly .DEF section with .DEFinition files.
> If you have been around long enough to see the COM+ and other inter-process
> communication examples with Microsoft or even unix (not too much Linux), you
> may note that the DEF file is a logical equivalent for a CORBA IDL file.
>
You're wrong, IDL are IDLs, even for Microsfot ActiveX or COM+ or OLE
if you want to call it.
MSDN Article about .DEF files:
http://msdn.microsoft.com/en-us/library/d91k01sh(v=vs.80).aspx
> LL>> I think there is something odd with your installation.
>
> From my side. I don't mind accepting that my system may be 'different' to a
> net-PC. The purpose to report bugs is to share information about things
> that don't happen they way one (such as me) expects them to...
>
> As a past-life successful support engineer I really advise you that to
> "blame the messenger" is never going to resolve whatever the issue is. My
> customers were always satisfied with my queries and the resolutions I worked
> through always respected that 'home base' didn't match the field
> conditions. May be my perception here is that you are not young (under
> 30). In which case, I regret being gentle in reply.
>
Sorry, but aren't you the end-user? are you a messenger? I'm blaming
you for something?
I'm pointing out that, same gem, same version, same OS generates
different results from me than you, which means that there is
something odd either on my installation or yours.
Since mine works, perhaps mine is the odd one.
> At one point you mention that ..
>
>>> linecache19 installation takes a REALLY LONG TIME to install because
>>> is going to download the ruby source code of your ruby version and
>
> Gee. I have clients still dial-up modems in third world countries. How do
> you figure that? Is Ruby only for the rich and endowed?! (sarcasm
> explicit)
>
Your sarcasm is pointless and I take this personally. Attacking my
attempts to help you you with sarcasm will not get you far with me.
> Apart from anything else my earlier description gave the list accurate
> information. Again ...
>
> ruby-debug19 tries to build linecache
>
You're are wrong.
ruby-debu19:
https://rubygems.org/gems/ruby-debug19
"Runtime dependencies":
columnize >= 0.3.1
linecache19 >= 0.5.11
ruby-debug-base19 >= 0.11.19
I'm reading wrong? Or who is reading wrong?
Even RubyGems from the command line get it right:
C:\Users\Luis>gem spec ruby-debug19 --remote dependencies
---
- !ruby/object:Gem::Dependency
name: columnize
type: :runtime
version_requirements: !ruby/object:Gem::Requirement
requirements:
- - ! '>='
- !ruby/object:Gem::Version
version: 0.3.1
version_requirement: !!null
- !ruby/object:Gem::Dependency
name: linecache19
type: :runtime
version_requirements: !ruby/object:Gem::Requirement
requirements:
- - ! '>='
- !ruby/object:Gem::Version
version: 0.5.11
version_requirement: !!null
- !ruby/object:Gem::Dependency
name: ruby-debug-base19
type: :runtime
version_requirements: !ruby/object:Gem::Requirement
requirements:
- - ! '>='
- !ruby/object:Gem::Version
version: 0.11.19
version_requirement: !!null
Or a better formatted one:
C:\Users\Luis>gem dep ruby-debug19 --remote
Gem ruby-debug19-0.11.6
columnize (>= 0.3.1, runtime)
linecache19 (>= 0.5.11, runtime)
ruby-debug-base19 (>= 0.11.19, runtime)
> To be completely and utterly clear Ruby-debug19 did not attempt to build
> "linecache19") as implied or imagined.
>
> That was the latest (then) gem from RubyGems.org (see email date and
> subtract a few minutes).
>
> The bug I reported actually concerned ONLY installing linecache19.
>
linecache19 is a dependency of ruby-debug19, as shown above.
> Which didn't work with the DevKit that does work with RDiscount.
> That is why I bothered to report BOTH bugs.
>
> I did not disclose details like having Mingw installed so someone may go all
> Freudian and 'blame the victim' here. OK. I have two lifetimes of
> experience in bug tracking and fixing. It is Sunday and DevKit users (the
> DevKit customers, and me personally) I don't appreciate or need a slap in
> the face when ...
>
I think you need to relax a bit. I'm not slapping in your face.
> [snip useless junk]
>
>
> Will
> ;-)
>
Smiley faces after the massive bunch of useless pride on your
qualities or qualifications will not change what I said before:
* Under Ruby 1.9.2 you need to install ruby-debug19, not ruby-debug
(or ruby-debug-ide) as mentioned in your first post.
* Ruby 1.9.2 generation of .def files is as simple as "puts ... >
file.def" invoked from Ruby.
If it failed to generate it, there must be something in your current
environment that is making it fail.
Saying this because I had previous experience with Ruby shelling out
to other Ruby process that failed and most of the time was related to
environment stuff misplaced, as mentioned here in this group several
times and you can search for it.
All our findings where placed in our Troubleshooting page:
https://github.com/oneclick/rubyinstaller/wiki/Troubleshooting
If the issues mentioned there doesn't capture your problem, *I* need
first to confirm that these were indeed verified. I give crap that you
have 2 lifetimes doing bug reporting/engineering/rocket science or
janitor.
I haven't only invested free time and money on this project, I put my
blood on it every time someone have problems.
I don't like your attitude, you don't know me or you haven't taken the
time to be polite with others.
If you're frustrated on a sunday, go for a walk.
I stand for my words, and all what I have done for me and others backs me up.
Also, put your real name where your words are, William, patches are
welcome if you can put better code than words.
Erwann
> I haven't only invested free time and money on this project, I put my
> blood on it every time someone have problems.
on his spare time few weeks ago, just to help me fix something. He is
one of the nicest and skilled person I've ever seen on the internet.
His determination to fix bugs and help people for free deserves a pay
rise. (just to say thank you again Luis for your time and patience
with newbies like me :)