Hi
While porting to an opteron 64bit computer, we noticed one
of our .so file was aborting. The problem was fixed by
adding a simple #include <re.h> to the .c file.
My question is, why is it required to include this file for opteron,
but not for the 32bit x86 machines. Without the include statement, I get
the error below on the 64 bit machine, but not on 32bit x86
or 64bit Solaris.
uname -a
Linux op2 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:32:58 EDT 2003 x86_64
x86_64 x86_64 GNU/Linux
make
gcc -fPIC -O2 -g -pipe -Wall -fPIC -I.
-I/usr/lib64/ruby/1.8/x86_64-linux-gnu
-I/usr/lib64/ruby/1.8/x86_64-linux-gnu -I. -c netlistparser.c
netlistparser.c: In function `Init_netlistparser':
netlistparser.c:113: warning: implicit declaration of function
`rb_reg_regcomp'
gcc -shared -L"/usr/lib64" -o netlistparser.so netlistparser.o -lruby
-ldl -lcrypt -lm -lc
···
--
Jim Freeze
A candidate is a person who gets money from the rich and votes from the
poor to protect them from each other.
Almost certainly the actual function definition doesn't match with the
defaults used by the compiler in the absence of a prototype. I don't
have access to the ruby source here but my guess is that
rb_reg_regcomp actually uses/returns a 64-bit value but the compiler
assumed a 32-bit value. When you execute the .so, rb_reg_regcomp puts
a 64-bit value on the stack but the caller only takes a 32-bit value
off. Boom. Adding the include file makes the prototype available to
the compiler.
···
On Thu, 10 Jun 2004 01:13:00 +0900, Jim Freeze <jim@freeze.org> wrote:
Hi
While porting to an opteron 64bit computer, we noticed one
of our .so file was aborting. The problem was fixed by
adding a simple #include <re.h> to the .c file.
My question is, why is it required to include this file for opteron,
but not for the 32bit x86 machines. Without the include statement, I get
the error below on the 64 bit machine, but not on 32bit x86
or 64bit Solaris.
uname -a
Linux op2 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:32:58 EDT 2003 x86_64
x86_64 x86_64 GNU/Linux
make
gcc -fPIC -O2 -g -pipe -Wall -fPIC -I.
-I/usr/lib64/ruby/1.8/x86_64-linux-gnu
-I/usr/lib64/ruby/1.8/x86_64-linux-gnu -I. -c netlistparser.c
netlistparser.c: In function `Init_netlistparser':
netlistparser.c:113: warning: implicit declaration of function
`rb_reg_regcomp'
gcc -shared -L"/usr/lib64" -o netlistparser.so netlistparser.o -lruby
-ldl -lcrypt -lm -lc
Should this be fixed in ruby.h?
···
On Thursday, 10 June 2004 at 3:08:40 +0900, Tim Hunter wrote:
On Thu, 10 Jun 2004 01:13:00 +0900, Jim Freeze <jim@freeze.org> wrote:
>Hi
>
> gcc -fPIC -O2 -g -pipe -Wall -fPIC -I.
> -I/usr/lib64/ruby/1.8/x86_64-linux-gnu
> -I/usr/lib64/ruby/1.8/x86_64-linux-gnu -I. -c netlistparser.c
> netlistparser.c: In function `Init_netlistparser':
> netlistparser.c:113: warning: implicit declaration of function
> `rb_reg_regcomp'
> gcc -shared -L"/usr/lib64" -o netlistparser.so netlistparser.o -lruby
> -ldl -lcrypt -lm -lc
Almost certainly the actual function definition doesn't match with the
defaults used by the compiler in the absence of a prototype. I don't
have access to the ruby source here but my guess is that
rb_reg_regcomp actually uses/returns a 64-bit value but the compiler
assumed a 32-bit value. When you execute the .so, rb_reg_regcomp puts
a 64-bit value on the stack but the caller only takes a 32-bit value
off. Boom. Adding the include file makes the prototype available to
the compiler.
--
Jim Freeze
Ours is a world of nuclear giants and ethical infants.
-- General Omar N. Bradley
Offhand, it seems to me that nothing is broken (except for the C language
itself, of course :-). Now that I have access to the Ruby sources, I see
that VALUE is a typedef for a long. I guess longs are 64 bits on the
Opteron. Without a prototype or other declaration in scope, the compiler
assumes that rb_reg_regcomp returns an int. Including the right header
file is the fix.
Of course the final decision is nobu's.
···
On Thu, 10 Jun 2004 03:58:55 +0900, Jim Freeze wrote:
Should this be fixed in ruby.h?
Hi,
At Thu, 10 Jun 2004 08:43:39 +0900,
Tim Hunter wrote in [ruby-talk:103007]:
> Should this be fixed in ruby.h?
Offhand, it seems to me that nothing is broken (except for the C language
itself, of course :-). Now that I have access to the Ruby sources, I see
that VALUE is a typedef for a long. I guess longs are 64 bits on the
Opteron. Without a prototype or other declaration in scope, the compiler
assumes that rb_reg_regcomp returns an int. Including the right header
file is the fix.
IMHO, It would be the only reasonable solution. If you use
regexp engine stuffs you should include re.h, I guess, since
ruby.h doesn't cover them.
Of course the final decision is nobu's.
Not me.
···
--
Nobu Nakada
Hi,
At Thu, 10 Jun 2004 08:43:39 +0900,
Tim Hunter wrote in [ruby-talk:103007]:
> Should this be fixed in ruby.h?
Offhand, it seems to me that nothing is broken (except for the C language
itself, of course :-). Now that I have access to the Ruby sources, I see
that VALUE is a typedef for a long. I guess longs are 64 bits on the
Opteron. Without a prototype or other declaration in scope, the compiler
assumes that rb_reg_regcomp returns an int. Including the right header
file is the fix.
IMHO, It would be the only reasonable solution. If you use
regexp engine stuffs you should include re.h, I guess, since
ruby.h doesn't cover them.
Of course the final decision is nobu's.
Not me.
···
--
Nobu Nakada
I understand the problem now.
Should ruby.h include re.h?
I'm trying to find a solution that works on both 32bit and 64bit
machines without code changes. And it would be best if I didn't
have to have it fail on a 64bit machine to find out.
Also, there is no problem with Solaris. Do the C compilers on sun
assume 32bit longs on the 64bit machines...maybe I should go look.
···
On Thursday, 10 June 2004 at 11:12:00 +0900, Nobuyoshi Nakada wrote:
Hi,
At Thu, 10 Jun 2004 08:43:39 +0900,
Tim Hunter wrote in [ruby-talk:103007]:
> > Should this be fixed in ruby.h?
>
> Offhand, it seems to me that nothing is broken (except for the C language
> itself, of course :-). Now that I have access to the Ruby sources, I see
> that VALUE is a typedef for a long. I guess longs are 64 bits on the
> Opteron. Without a prototype or other declaration in scope, the compiler
> assumes that rb_reg_regcomp returns an int. Including the right header
> file is the fix.
IMHO, It would be the only reasonable solution. If you use
regexp engine stuffs you should include re.h, I guess, since
ruby.h doesn't cover them.
--
Jim Freeze
fortune: cpu time/usefulness ratio too high -- core dumped.
Hi,
At Thu, 10 Jun 2004 13:47:54 +0900,
Jim Freeze wrote in [ruby-talk:103037]:
> > > Should this be fixed in ruby.h?
> >
> > Offhand, it seems to me that nothing is broken (except for the C language
> > itself, of course :-). Now that I have access to the Ruby sources, I see
> > that VALUE is a typedef for a long. I guess longs are 64 bits on the
> > Opteron. Without a prototype or other declaration in scope, the compiler
> > assumes that rb_reg_regcomp returns an int. Including the right header
> > file is the fix.
>
> IMHO, It would be the only reasonable solution. If you use
> regexp engine stuffs you should include re.h, I guess, since
> ruby.h doesn't cover them.
I understand the problem now.
Should ruby.h include re.h?
I don't think so. All sources using ruby.h don't need regexp
stuffs.
I'm trying to find a solution that works on both 32bit and 64bit
machines without code changes. And it would be best if I didn't
have to have it fail on a 64bit machine to find out.
Why without changes? It isn't your own code?
···
--
Nobu Nakada
I'm trying to find a solution that works on both 32bit and 64bit
machines without code changes. And it would be best if I didn't
have to have it fail on a 64bit machine to find out.
Include "re.h" in your source file. It's always the right thing to do.
Also, there is no problem with Solaris. Do the C compilers on sun
assume 32bit longs on the 64bit machines...maybe I should go look.
Some 64-bit machines use 64-bit pointers but longs are 32 bits. Others
make both pointers and longs 64 bits. I don't know which camp Solaris
is in. In all cases including re.h solves the problem.
···
On Thu, 10 Jun 2004 13:47:54 +0900, Jim Freeze <jim@freeze.org> wrote:
No, it's my code. I just find it a little disconcerting that the missing
include did not even generate a warning for the 32bit compile, but
it is required for the 64bit compile.
···
On Thursday, 10 June 2004 at 14:06:20 +0900, nobu.nokada@softhome.net wrote:
Hi,
At Thu, 10 Jun 2004 13:47:54 +0900,
Jim Freeze wrote in [ruby-talk:103037]:
> > > > Should this be fixed in ruby.h?
> > >
> I understand the problem now.
> Should ruby.h include re.h?
I don't think so. All sources using ruby.h don't need regexp
stuffs.
> I'm trying to find a solution that works on both 32bit and 64bit
> machines without code changes. And it would be best if I didn't
> have to have it fail on a 64bit machine to find out.
Why without changes? It isn't your own code?
--
Jim Freeze
This fortune is inoperative. Please try another.
Quoteing jim@freeze.org, on Thu, Jun 10, 2004 at 03:21:59PM +0900:
···
On Thursday, 10 June 2004 at 14:06:20 +0900, nobu.nokada@softhome.net wrote:
> > I'm trying to find a solution that works on both 32bit and 64bit
> > machines without code changes. And it would be best if I didn't
> > have to have it fail on a 64bit machine to find out.
>
> Why without changes? It isn't your own code?
No, it's my code. I just find it a little disconcerting that the missing
include did not even generate a warning for the 32bit compile, but
it is required for the 64bit compile.
What compiler are you using? Are you sure you have the warning levels
cranked high? Default build options on many compilers won't tell you
about this kind of stuff.
Sam
Quoteing jim@freeze.org, on Thu, Jun 10, 2004 at 03:21:59PM +0900:
> > > I'm trying to find a solution that works on both 32bit and 64bit
> > > machines without code changes. And it would be best if I didn't
> > > have to have it fail on a 64bit machine to find out.
> >
> > Why without changes? It isn't your own code?
>
> No, it's my code. I just find it a little disconcerting that the missing
> include did not even generate a warning for the 32bit compile, but
> it is required for the 64bit compile.
What compiler are you using? Are you sure you have the warning levels
cranked high? Default build options on many compilers won't tell you
about this kind of stuff.
gcc
The warnings are whatever is generated by mkmf/create_makefile by default.
./a.out
sizeof(char) 1 bytes 8 bits
sizeof(short) 2 bytes 16 bits
sizeof(int) 4 bytes 32 bits
sizeof(void *) 4 bytes 32 bits
sizeof(float) 4 bytes 32 bits
sizeof(double) 8 bytes 64 bits
sizeof(long) 4 bytes 32 bits
sizeof(long long)8 bytes 64 bits
uname -a
SunOS juno 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-5_10
Apparently, our 64bit suns are using a 32bit compiler
and hence the 32bit pointers.
./a.out
sizeof(char) 1 bytes 8 bits
sizeof(short) 2 bytes 16 bits
sizeof(int) 4 bytes 32 bits
sizeof(void *) 8 bytes 64 bits
sizeof(float) 4 bytes 32 bits
sizeof(double) 8 bytes 64 bits
sizeof(long) 8 bytes 64 bits
sizeof(long long)8 bytes 64 bits
uname -a
Linux op2 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:32:58 EDT 2003 x86_64
x86_64 x86_64 GNU/Linux
···
On Thursday, 10 June 2004 at 23:30:31 +0900, Sam Roberts wrote:
> On Thursday, 10 June 2004 at 14:06:20 +0900, nobu.nokada@softhome.net wrote:
--
Jim Freeze
A [golf] ball sliced or hooked into the rough shall be lifted and
placed in the fairway at a point equal to the distance it carried or
rolled into the rough. Such veering right or left frequently results
from friction between the face of the club and the cover of the ball
and the player should not be penalized for the erratic behavior of the
ball resulting from such uncontrollable physical
phenomena.
-- Donald A. Metz
Quoteing jim@freeze.org, on Fri, Jun 11, 2004 at 02:20:12AM +0900:
> What compiler are you using? Are you sure you have the warning levels
> cranked high? Default build options on many compilers won't tell you
> about this kind of stuff.
>
gcc
The warnings are whatever is generated by mkmf/create_makefile by default.
There's a chance that they do not include -Wall. I'd suggest always
using this flag, at least during development.
Sam