dbd-pg gem on windows with Ruby 1.9.1
Zeno R.R. Davatz
I just tried to install dbd-pg on Windows with Ruby 1.9.1 and that
resulted in the following error:
Building native extensions. This could take a while...
ERROR: Error installing dbd-pg:
ERROR: Failed to build gem native extension.
C:/Ruby191/bin/ruby.exe extconf.rb
checking for pg_config... yes
Using config values from C:\Program Files\PostgreSQL\8.4\bin/
pg_config.exe
checking for libpq-fe.h... yes
checking for libpq/libpq-fs.h... yes
checking for PQconnectdb() in -lpq... yes
checking for PQconnectionUsedPassword()... yes
checking for PQisthreadsafe()... yes
checking for PQprepare()... yes
checking for PQexecParams()... yes
checking for PQescapeString()... yes
checking for PQescapeStringConn()... yes
checking for PQgetCancel()... yes
checking for lo_create()... yes
checking for pg_encoding_to_char()... yes
checking for PQsetClientEncoding()... yes
checking for struct pgNotify.extra in libpq-fe.h... yes
checking for unistd.h... yes
creating extconf.h
creating Makefile
make
gcc -I. -IC:/Ruby191/include/ruby-1.9.1/i386-mingw32 -I/C/Ruby191/
include/ruby-1.9.1/ruby/backward -I/C/Ruby191/include/ruby-1.9.1 -I. -
DRUBY_EXTCONF_H=\"extcon
f.h\" -IC:/PROGRA~1/POSTGR~1/8.4/include -O2 -g -Wall -Wno-
parentheses -o compat.o -c compat.c
gcc -I. -IC:/Ruby191/include/ruby-1.9.1/i386-mingw32 -I/C/Ruby191/
include/ruby-1.9.1/ruby/backward -I/C/Ruby191/include/ruby-1.9.1 -I. -
DRUBY_EXTCONF_H=\"extcon
f.h\" -IC:/PROGRA~1/POSTGR~1/8.4/include -O2 -g -Wall -Wno-
parentheses -o pg.o -c pg.c
In file included from c:/Ruby191/include/ruby-1.9.1/ruby/defines.h:
192:0,
from c:/Ruby191/include/ruby-1.9.1/ruby/ruby.h:70,
from c:/Ruby191/include/ruby-1.9.1/ruby.h:32,
from pg.h:16,
from pg.c:15:
c:/Ruby191/include/ruby-1.9.1/ruby/win32.h:353:18: error: conflicting
types for 'ftruncate'
c:\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/unistd.h:
43:18: note: previous definition of 'ftruncate' was here
make: *** [pg.o] Error 1
Gem files will remain installed in C:/Ruby191/lib/ruby/gems/1.9.1/gems/
pg-0.10.1 for inspection.
Results logged to C:/Ruby191/lib/ruby/gems/1.9.1/gems/pg-0.10.1/ext/
gem_make.out
Any hints are more then welcome. Postgresql is in my Path and works
fine with Ruby 1.8.6.
Best
Zeno
Luis Lavena
> Hi
>
> I just tried to install dbd-pg on Windows with Ruby 1.9.1 and that
> resulted in the following error:
>
> Building native extensions. This could take a while...
> ERROR: Error installing dbd-pg:
> ERROR: Failed to build gem native extension.
>
Please use Ruby 1.9.2 when reporting issues, Ruby 1.9.1 is not granted
to be compatible with latest DevKit (was build with GCC 3.4.5) and
conflicts might show.
1.9.2 *needs* DevKit 4.5.1
Also, Ruby 1.9.1 introduced some defines that clash with MinGW (marked
them as missing but actually never checked for them)
--
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
Zeno R.R. Davatz
On 21 Jan., 15:20, Luis Lavena <luislav...@gmail.com> wrote:
> > I just tried to install dbd-pg on Windows with Ruby 1.9.1 and that
> > resulted in the following error:
>
> > Building native extensions. This could take a while...
> > ERROR: Error installing dbd-pg:
> > ERROR: Failed to build gem native extension.
>
> Please use Ruby 1.9.2 when reporting issues, Ruby 1.9.1 is not granted
> to be compatible with latest DevKit (was build with GCC 3.4.5) and
> conflicts might show.
>
> 1.9.2 *needs* DevKit 4.5.1
>
> Also, Ruby 1.9.1 introduced some defines that clash with MinGW (marked
> them as missing but actually never checked for them)
http://redmine.ruby-lang.org/wiki/ruby-19/%23Hash_Iteration
I compiled Ruby 1.9.1 against gcc 4.5.0. Is that a problem for dbd-pg?
I guess not.
Also Ruby 1.9.1 is marked as stable on the Ruby-Windows-Installer
website.
I happy to check some more Ruby 1.9.1 issues on Windows.
Best
Zeno
Chuck Remes
On Jan 21, 2011, at 8:31 AM, Zeno R.R. Davatz wrote:
> Dear Luis
>
> On 21 Jan., 15:20, Luis Lavena <luislav...@gmail.com> wrote:
>> On Fri, Jan 21, 2011 at 11:18 AM, Zeno R.R. Davatz <zdav...@gmail.com> wrote:
>
>>> I just tried to install dbd-pg on Windows with Ruby 1.9.1 and that
>>> resulted in the following error:
>>
>>> Building native extensions. This could take a while...
>>> ERROR: Error installing dbd-pg:
>>> ERROR: Failed to build gem native extension.
>>
>> Please use Ruby 1.9.2 when reporting issues, Ruby 1.9.1 is not granted
>> to be compatible with latest DevKit (was build with GCC 3.4.5) and
>> conflicts might show.
>>
>> 1.9.2 *needs* DevKit 4.5.1
>>
>> Also, Ruby 1.9.1 introduced some defines that clash with MinGW (marked
>> them as missing but actually never checked for them)
>
> But I need Ruby 1.9.1 because of the working Hash-Iterations ;) -
> http://redmine.ruby-lang.org/wiki/ruby-19/%23Hash_Iteration
Zeno, you should patch the gem(s) that use this broken behavior. To use the example given above, a very simple change makes it compatible.
- h.each_key do |k|
+ h.keys.each do |k|
That avoids the runtime exception. Fix those gems so you can use 1.9.2.
cr
Luis Lavena
>
> But I need Ruby 1.9.1 because of the working Hash-Iterations ;) -
> http://redmine.ruby-lang.org/wiki/ruby-19/%23Hash_Iteration
>
Please report these issues of the gems you're using to the authors.
Send patches, help them make the code work with newer version of Ruby.
> I compiled Ruby 1.9.1 against gcc 4.5.0. Is that a problem for dbd-pg?
> I guess not.
>
No, it wouldn't. As I said Ruby defines blindly what it knows is
missing. I send patches for those things, but for 1.9.2
> Also Ruby 1.9.1 is marked as stable on the Ruby-Windows-Installer
> website.
>
No, is not marked as stable. It is available in the list of downloads
but is not actively updated by Ruby-Core and highly unlikely will get
a new version out.
Focus has been and will remain on 1.9.2 and trunk.
1.8.6 is there for legacy purposes, see the list for my previous
statement on all the above.
> I happy to check some more Ruby 1.9.1 issues on Windows.
>
Thanks, but no thanks. Ruby 1.9.2 and against trunk will be highly
appreciated instead.
I can't split my effort in track every single piece of errors of every
single version of Ruby out there. Mentioned this before. Neither I
have the effort to provide proper patches and get them pushed
upstream.
Zeno R.R. Davatz
On 21 Jan., 15:35, Chuck Remes <cremes.devl...@mac.com> wrote:
> Zeno, you should patch the gem(s) that use this broken behavior. To use the example given above, a very simple change makes it compatible.
>
> - h.each_key do |k|
> + h.keys.each do |k|
>
> That avoids the runtime exception. Fix those gems so you can use 1.9.2.
But I need 1.9.1 not 1.9.2 on my Windows because of Hash-Iterations
for "Grandmothers".
Best
Zeno
Zeno R.R. Davatz
http://rubyforge.org/tracker/index.php?func=detail&aid=28873&group_id=234&atid=967
Best
Zeno
Luis Lavena
> I reported this here as well:
>
> http://rubyforge.org/tracker/index.php?func=detail&aid=28873&group_id=234&atid=967
>
You know, the compilation problem has nothing to do with what you
entered as "fix"
Instead of massive copy and paste between list, can you at least try
to solve the problems instead of reporting?
Is way better if you provide patches instead of report the errors all
over the place.
That is the way to gain trust, everywhere.
Zeno R.R. Davatz
Yep. We fixed it in a different way. Yours is shorter though.
http://dev.ywesee.com/wiki.php/Masa/20110121-setup-ramaze#Hash
Best
Zeno
Zeno R.R. Davatz
On 21 Jan., 15:58, Luis Lavena <luislav...@gmail.com> wrote:
>
> > I reported this here as well:
>
> You know, the compilation problem has nothing to do with what you
> entered as "fix"
>
> Instead of massive copy and paste between list, can you at least try
> to solve the problems instead of reporting?
>
> Is way better if you provide patches instead of report the errors all
> over the place.
>
> That is the way to gain trust, everywhere.
Ruby-1.9.1 is still marked as stable though on Windows. So that is
confusing too. I need Ruby 1.9.1 to test
on Windows. Seems it is not stable.
Before I provide patches, I will notify the Maintainer and log the
bug. The maintainer is mostly faster to provide a patch then I am.
Best
Zeno
Chuck Remes
On Jan 21, 2011, at 9:14 AM, Zeno R.R. Davatz wrote:
>
> Yep. Sorry about the confusion.
>
> Ruby-1.9.1 is still marked as stable though on Windows. So that is
> confusing too. I need Ruby 1.9.1 to test
> on Windows. Seems it is not stable.
>
> Before I provide patches, I will notify the Maintainer and log the
> bug. The maintainer is mostly faster to provide a patch then I am.
Zeno,
why do you need 1.9.1 to test on Windows? If the intention is to port your application from 1.8.x, then you *need* to test it against 1.9.2. Testing against 1.9.1 won't be of much help because there are behavior differences between 1.9.1 and 1.9.2.
Test with 1.9.2 and create patches for those gems which misbehave. *That* is the way to move forward.
cr
Zeno R.R. Davatz
On 21 Jan., 16:48, Chuck Remes <cremes.devl...@mac.com> wrote:
> On Jan 21, 2011, at 9:14 AM, Zeno R.R. Davatz wrote:
> why do you need 1.9.1 to test on Windows? If the intention is to port your application from 1.8.x, then you *need* to test it against 1.9.2. Testing against 1.9.1 won't be of much help because there are behavior differences between 1.9.1 and 1.9.2.
Thank you for your help. And if the App works on Ruby 1.8.6 and Ruby
1.9.1 but then breaks on Ruby 1.9.2 I think this is strange and
inconsistent for Ruby.
> Test with 1.9.2 and create patches for those gems which misbehave. *That* is the way to move forward.
just noticed this today.
But pg is a different story. pg-0.10.1 does not seem to work with Ruby
1.9.2 for us.
Best
Zeno
Luis Lavena
>
> I need to know where and when the application breaks. Simple as that.
Test::Unit
RSpec
Cucumber
All those tools helps you on that.
> Thank you for your help. And if the App works on Ruby 1.8.6 and Ruby
> 1.9.1 but then breaks on Ruby 1.9.2 I think this is strange and
> inconsistent for Ruby.
Not again!, please stop!
The Ruby-Core thread won my first mute of Gmail, please don't turn
this conversation into a second on.
1.9.0 = YARV, API break with 1.8.x
1.9.1 = development, API breaks with 1.8.x codebase due the
introduction of YARV in 1.9.0, improvements
1.9.2 = Stabilization of 1.9.1 codebase, improvements, for sure is not
the same as 1.8.x
>
> But pg is a different story. pg-0.10.1 does not seem to work with Ruby
> 1.9.2 for us.
>
ruby-pg != pg gem.
You need to read A LOT MORE, change your application MORE than email
every 5 minutes the list on every problem you can simply fix reading
the code.
Zeno R.R. Davatz
So where is your pg gem that works with Ruby 1.9.2? Can you send me a
link please.
I know of these two gems and they are not the same:
1. http://rubygems.org/gems/pg
2. http://rubygems.org/gems/ruby-pg
Now which one works with Ruby 1.9.2? Thank you for your Feedback.
Best
Zeno
Zeno R.R. Davatz
ruby 1.9.1p430 (2010-08-16 revision 28998) [i386-mingw32]
pg does not build on Ruby 1.9.1 on Windows. It _does_ build on Linux.
I guess you tell me to upgrade to Ruby 1.9.2 but there the pg gem
stops working again, as I can prove on Linux when our App tries to
start. pg gem 0.10.1 does work on Linux with Ruby 1.9.1 but does not
work Linux with Ruby 1.9.2
gem install pg
Building native extensions. This could take a while...
Zeno
Jon
"It ain't so much the things you don't know that get you in trouble. It's the things you know that just ain't so." - Artimus Ward
"...there is such a distance between how one lives and how one should live that he who lets go that which is done for that which ought to be done learns his ruin rather than his preservation." - Niccolo Machiavelli
It appears your desire for how things should be doesn't match the current reality. Fighting this "reality" can be a bit like fighting gravity, a la Don Quixote.
I challenge you to view the current Ruby "reality" as really just another business opportunity.
You do the hard work to deliver the "consistency", "stability", whatever required by your customers wading through the jungle-of-issues and selectively picking the right combination of technology, versions, features, service, etc. If people can't easily duplicate what you've done and truly value it enough to pay for it, you're off to a good start.
The risk of course is getting distracted and spending precious time away from where you add real value.
As others have replied, the pragmatic path for your 1.9 Windows success starts with 1.9.2 and Chuck's advice to "Test with 1.9.2 and create patches for those gems which misbehave."
Jon
---
blog: http://jonforums.github.com/
twitter: @jonforums
Luis Lavena
I know my english is not good, but do you really read my answers? I
replied on Ruby-Core that pg != ruby-pg and ruby-pg has not been
updated in YEARS
Considering 1.9.2 is fairly new/stable, can you burn one braincell and
think which one I'm talking about?
No? Still?
pg:
https://rubygems.org/gems/pg
And it works on Ruby 1.9.2-p136:
C:\Users\Luis\Projects\_sandbox>ruby -v
ruby 1.9.2p136 (2010-12-25) [i386-mingw32]
C:\Users\Luis\Projects\_sandbox>subst X: "C:\Program Files (x86)\PostgreSQL\8.3"
C:\Users\Luis\Projects\_sandbox>gem install pg -- --with-pg-dir=X:
Temporarily enhancing PATH to include DevKit...
Building native extensions. This could take a while...
Successfully installed pg-0.10.1
1 gem installed
C:\Users\Luis\Projects\_sandbox>set PATH=%PATH%;X:\bin
(need libpq.dll in the PATH)
C:\Users\Luis\Projects\_sandbox>irb
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'pg'
=> true
irb(main):003:0> conn = PGconn.open(:dbname => 'test', :user =>
'postgres', :password => '')
=> #<PGconn:0x2c9a198>
irb(main):004:0> res = conn.exec('SELECT 1 + 2')
=> #<PGresult:0x2bc0698>
irb(main):005:0> res.getvalue(0,0)
=> "3"
See? It works.
Now, I don't care if 'pg' gem do not build on Ruby 1.8.5, 1.8.6 or
whatever, Is the gem author responsibility to tell you 'No, don't use
1.9.1' like we have been trying to tell you several times.
And no, I give a damn it works on Linux. As I mentioned before Ruby
1.9.1 has bugs in relation to MinGW that you clearly ignored from my
previous answer, it seems obvious you read what you want and quote
responses as you please ignoring facts.
And no again, I give a damn what you call "compatibility".
I'm starting to sound as a broken record on this discussion and
feeling stupid. I've been questioning my communication skills and my
english usage, but seems clearly is not that the problem.
This is the last response you're going to get from me in LONG time.
Zeno R.R. Davatz
Dear Jon
Good to know. Thank you for the replies.
Best
Zeno
Zeno R.R. Davatz
Loading the pg gem into irb does not quite simulate our software. I
will keep you posted about pg and Ruby 1.9.2.
I care about Ruby on all Platforms.
Best
Zeno
Zeno R.R. Davatz
Your irb-Proof works but in our production environment we seem to use
more functionalities of the pg-gem. Thanks anyway for your help.
The problem with the pg gem that we have is that the following
_method_ does not work when we initialize our database:
@pg_conn.exec_prepared(stmt_name, parameters)
Now if you can forward that to the authors of pg gem that would be
helpful.
This is the error we get on Ruby 1.9.2, if we trace it back in our
source code:
company_name« existiert bereits (DBI::ProgrammingError)
from /usr/lib/ruby/gems/1.9.1/gems/dbd-pg-0.3.9/lib/dbd/pg/
statement.rb:37:in `execute'
from /usr/lib/ruby/gems/1.9.1/gems/dbi-0.4.2/lib/dbi/
base_classes/database.rb:96:in `execute'
from /usr/lib/ruby/gems/1.9.1/gems/dbi-0.4.2/lib/dbi/
base_classes/database.rb:114:in `do'
from /usr/lib/ruby/gems/1.9.1/gems/dbi-0.4.2/lib/dbi/handles/
database.rb:106:in `do'
from /usr/lib/ruby/site_ruby/1.9.1/odba/storage.rb:176:in
`create_index'
from /usr/lib/ruby/site_ruby/1.9.1/odba/index.rb:226:in
`initialize'
from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:148:in `new'
from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:148:in `block
in create_index'
from /usr/lib/ruby/site_ruby/1.9.1/odba/storage.rb:558:in
`call'
from /usr/lib/ruby/site_ruby/1.9.1/odba/storage.rb:558:in
`block in transaction'
from /usr/lib/ruby/gems/1.9.1/gems/dbi-0.4.2/lib/dbi/handles/
database.rb:209:in `transaction'
from /usr/lib/ruby/site_ruby/1.9.1/odba/connection_pool.rb:
36:in `block in method_missing'
from /usr/lib/ruby/site_ruby/1.9.1/odba/connection_pool.rb:
26:in `next_connection'
from /usr/lib/ruby/site_ruby/1.9.1/odba/connection_pool.rb:
35:in `method_missing'
from /usr/lib/ruby/site_ruby/1.9.1/odba/storage.rb:554:in
`transaction'
from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:520:in
`transaction'
from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:140:in
`create_index'
from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:131:in `block
in create_deferred_indices'
from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:125:in `each'
from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:125:in
`create_deferred_indices'
from /usr/lib/ruby/site_ruby/1.9.1/odba/cache.rb:437:in
`setup'
from /usr/lib/ruby/site_ruby/1.9.1/oddb/persistence/odba.rb:
35:in `<module:ODDB>'
from /usr/lib/ruby/site_ruby/1.9.1/oddb/persistence/odba.rb:
28:in `<top (required)>'
from /var/www/ramaze.ch.oddb.org/model/init.rb:3:in `require'
from /var/www/ramaze.ch.oddb.org/model/init.rb:3:in `<top
(required)>'
from /var/www/ramaze.ch.oddb.org/app.rb:32:in `require'
from /var/www/ramaze.ch.oddb.org/app.rb:32:in `<top
(required)>'
from start.rb:7:in `require'
from start.rb:7:in `<main>'
I will send this to Ruby-Talk as well as Chuck recommends.
Best
Zeno
Zeno R.R. Davatz
James Cowlishaw
company_name« existiert bereits (DBI::ProgrammingError)
Note that the third attempt to require fails, as the path is matched.D:\test>ruby -vruby 1.9.2p0 (2010-08-18) [i386-mingw32]D:\test>more example.rb
ConstantValue = 10D:\test>irb -r"./example.rb"irb(main):001:0> require 'd:\test\example.rb'd:/test/example.rb:1: warning: already initialized constant ConstantValue=> trueirb(main):002:0> require 'd:\test\example.rb'=> false
James.
Zeno R.R. Davatz
Thank you for your reply.
Our App (not Ramaze that is just the HTML framework) always checks if
the table exists or not. ODBA does this for us.
You can ignore these. ODBA tries to set up the database on every
startup. The easiest way to do this is to send create table
statements, which fail with an error if the table already exists.
Sadly, even though the Error can be rescued, the postgres library
writes these messages to stderr. We get the same error with Ruby 1.8.6
and Ruby 1.9.1 - that error is not the problem. The App works with
these warnings no problem with 1.8.6 and 1.9.1
The error is somewhere different in subtle change the way Ruby 1.9.2
deals with the Block Argument Scope (as far as our trace goes at the
moment):
It seems this is related to dbi (0.4.5) and the way Ruby 1.9.2 handles
the block-Argument-scope vs Ruby 1.9.1. dbi uses this.
see the red lines here:
http://dev.ywesee.com/wiki.php/Masa/20110124-setup-ramaze#dbi_while
Best
Zeno
PS: Trying to install pg-0.10.1 with Ruby 1.9.2 on windows Vista
results in (0.8.0 and 0.9.0 of pg gem installed just fine) the
following. Postgresql is in my Path configured correctly.
C:/Ruby192/bin/ruby.exe extconf.rb
Using config values from C:\Program Files\PostgreSQL\8.4\bin/
pg_config.exe
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers. Check the mkmf.log file for more
details. You may need configuration options.
Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=C:/Ruby192/bin/ruby
--with-pg
--without-pg
--with-pg-dir
--without-pg-dir
--with-pg-include
--without-pg-include=${pg-dir}/include
--with-pg-lib
--without-pg-lib=${pg-dir}/lib
--with-pg-config
--without-pg-config
--with-pg_config
--without-pg_config
extconf.rb:13:in ``': No such file or directory - C:\Program Files
\PostgreSQL\8.4\bin/pg_config.exe --includedir (Errno::ENOENT)
from extconf.rb:13:in `<main>'
Zeno R.R. Davatz
Ok just FYI we solved the problem. It again was in dbi. What we had to
do is force the Array in dbi, as so:
/usr/lib64/ruby/gems/1.9.1/gems/dbi-0.4.5/lib/dbi/handles/statement.rb
we changed
#fetched_rows.push(row)
to
fetched_rows.push(row.to_a)
This works for us in Ruy 1.9.1 _and_ Ruby 1.9.2
We do not have a clue so far why this works in Ruby 1.9.2 and in Ruby
1.9.1 but it does work for us.
Thanks for all your help so far and let us know if you know why this
is needed for Ruby 1.9.2 to work.
Best
Zeno