sizeof(IV)

2001-09-18 Thread Gibbs Tanton - tgibbs

Are we assuming that sizeof(IV) = sizeof(char*).  If so, we should probably
assert this somewhere in the configure system.

Tanton



Re: bytecode and sizeof(IV)

2001-09-18 Thread Jarkko Hietaniemi

On Tue, Sep 18, 2001 at 10:48:25AM -0400, Andy Dougherty wrote:
 When trying to configure parrot with an IV = 'long long' (64-bit)
 but with int, long, and pointers only 32-bit, I get either 
 
 This isn't Parrot bytecode!
 
 (on SPARC) or a segfault (on i686).

Segfault in alpha even when IVs and pointers are both 8 bytes since
the code tries to dereference the pointers (to read IVs) at four byte
offsets.

 I'd offer a patch, but I'm not sure which end of the process we want to
 change.

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen



Re: bytecode and sizeof(IV)

2001-09-18 Thread Simon Cozens

On Tue, Sep 18, 2001 at 05:52:24PM +0300, Jarkko Hietaniemi wrote:
 Segfault in alpha even when IVs and pointers are both 8 bytes since
 the code tries to dereference the pointers (to read IVs) at four byte
 offsets.

Yep, and the latest pedantic patch doesn't help. Also, I'm seeing
this, which is weird:

ld -ldbm -ldb -lm -liconv   -o test_prog global_setup.o interpreter.o parrot.o 
register.o basic_opcodes.o memory.o bytecode.o string.o strnative.o test_main.o
ld:
Error: Undefined:
exit
_iob
fprintf
fputs
strncmp
_OtsDivide64
printf
time
acos
asin
atan
atan2
cosh
exp
log
log10
pow
sinh
tan
tanh
cos
sin
_OtsRemainder64
malloc
__CFE_print_puts
free
realloc
_OtsMoveMinimum
_OtsZero
_OtsMove
mmap
stat
open
errno
strcmp
*** Exit 1

-- 
The UNIX system is harder to use than a toaster.  -Kaare Christian



RE: bytecode and sizeof(IV)

2001-09-18 Thread Gibbs Tanton - tgibbs

 You probably don't want to use ld as your linker.  You should try cc
instead.

-Original Message-
From: Simon Cozens
To: [EMAIL PROTECTED]
Sent: 9/18/2001 9:46 AM
Subject: Re: bytecode and sizeof(IV)

On Tue, Sep 18, 2001 at 05:52:24PM +0300, Jarkko Hietaniemi wrote:
 Segfault in alpha even when IVs and pointers are both 8 bytes since
 the code tries to dereference the pointers (to read IVs) at four byte
 offsets.

Yep, and the latest pedantic patch doesn't help. Also, I'm seeing
this, which is weird:

ld -ldbm -ldb -lm -liconv   -o test_prog global_setup.o interpreter.o
parrot.o register.o basic_opcodes.o memory.o bytecode.o string.o
strnative.o test_main.o
ld:
Error: Undefined:
exit
_iob
fprintf
fputs
strncmp
_OtsDivide64
printf
time
acos
asin
atan
atan2
cosh
exp
log
log10
pow
sinh
tan
tanh
cos
sin
_OtsRemainder64
malloc
__CFE_print_puts
free
realloc
_OtsMoveMinimum
_OtsZero
_OtsMove
mmap
stat
open
errno
strcmp
*** Exit 1

-- 
The UNIX system is harder to use than a toaster.  -Kaare Christian



Re: bytecode and sizeof(IV)

2001-09-18 Thread Simon Cozens

On Tue, Sep 18, 2001 at 11:10:36AM -0500, Gibbs Tanton - tgibbs wrote:
  You probably don't want to use ld as your linker.  You should try cc
 instead.

Then that's a bug in Configure! :)

-- 
If that makes any sense to you, you have a big problem.
-- C. Durance, Computer Science 234



[PATCH Makefile.in] RE: [doughera@lafayette.edu: Re: bytecode and sizeof(IV)]

2001-09-18 Thread Brent Dax

Easy Makefile.in patch.  I was worried that Win32 might need the linker
(the change to $(LD) was submitted as part of a Win32 compatibility
patch) but that doesn't seem to be the case.  I don't have a MinGW
toolkit installed, however--can someone check that it works there?  It
also works on a BSD box, so I'm applying.

--Brent Dax
[EMAIL PROTECTED]

They *will* pay for what they've done.


--- ..\..\parrot-cvs\parrot\Makefile.in Tue Sep 18 10:54:52 2001
+++ Makefile.in Tue Sep 18 10:53:54 2001
@@ -28,7 +28,7 @@
$(CC) -shared $(C_LIBS) -o $@ $(O_FILES)

 $(TEST_PROG): test_main$(O) $(O_FILES)
-   $(LD) $(C_LIBS) ${ld_debug} ${ld_out}$(TEST_PROG) $(O_FILES)
test_main$(O)
+   $(CC) $(C_LIBS) $(CFLAGS) -o $(TEST_PROG) $(O_FILES)
test_main$(O)

 test_main$(O): $(H_FILES)




Re: [PATCH Makefile.in] RE: [doughera@lafayette.edu: Re: bytecode and sizeof(IV)]

2001-09-18 Thread Mattia Barbon

 Easy Makefile.in patch.  I was worried that Win32 might need the linker
 (the change to $(LD) was submitted as part of a Win32 compatibility
 patch) but that doesn't seem to be the case.  I don't have a MinGW
Fine here

Regards
Mattia




Re: bytecode and sizeof(IV)

2001-09-18 Thread Russ Allbery

Simon Cozens [EMAIL PROTECTED] writes:

 Yep, and the latest pedantic patch doesn't help. Also, I'm seeing
 this, which is weird:

 ld -ldbm -ldb -lm -liconv   -o test_prog global_setup.o interpreter.o parrot.o 
register.o basic_opcodes.o memory.o bytecode.o string.o strnative.o test_main.o

Definitely bugs in Configure there; cc has to be used as the linker or -lc
isn't added (and possibly some of the other crt.o files too), and
libraries have to be after all the object files.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/



RE: bytecode and sizeof(IV)

2001-09-18 Thread Brent Dax

Russ Allbery:
# Simon Cozens [EMAIL PROTECTED] writes:
# 
#  Yep, and the latest pedantic patch doesn't help. Also, I'm seeing
#  this, which is weird:
# 
#  ld -ldbm -ldb -lm -liconv   -o test_prog global_setup.o 
# interpreter.o parrot.o register.o basic_opcodes.o memory.o 
# bytecode.o string.o strnative.o test_main.o
# 
# Definitely bugs in Configure there; cc has to be used as the 
# linker or -lc
# isn't added (and possibly some of the other crt.o files too), and
# libraries have to be after all the object files.

I've already patched Makefile.in to fix this.

--Brent Dax
[EMAIL PROTECTED]

They *will* pay for what they've done.