Installing Gwydion Dylan on x86 Linux 
Author Message
 Installing Gwydion Dylan on x86 Linux

I have tried to install Gwydion Dylan on RedHat v5.2 Linux (x86). I
downloaded gwydion-dylan-2.3.1-x86-linux-gcc-libc6.tar.gz and
unarchived it. Since I didn't install it in /usr/local, I set DYLANDIR
to point to the root of the installed directory (the one containing
the directories for bin etc.). Trying to invoke d2c results in the
following error message.

v2.3.1/bin/d2c: error in loading shared libraries
: undefined symbol: __register_frame_info

Adding the library directory (i.e., v2.3.1/lib/dylan/2.3.1/x86-linux-gcc/)
to LD_LIBRARY_PATH does not help. What am I doing wrong?

Mark

--

University of Illinois at Urbana-Champaign
Real-Time Systems Laboratory
--



Fri, 25 Jan 2002 03:00:00 GMT  
 Installing Gwydion Dylan on x86 Linux

Quote:

> I have tried to install Gwydion Dylan on RedHat v5.2 Linux (x86). I
> downloaded gwydion-dylan-2.3.1-x86-linux-gcc-libc6.tar.gz and
> unarchived it. Since I didn't install it in /usr/local, I set DYLANDIR
> to point to the root of the installed directory (the one containing
> the directories for bin etc.). Trying to invoke d2c results in the
> following error message.

> v2.3.1/bin/d2c: error in loading shared libraries
> : undefined symbol: __register_frame_info

There was a bad RPM build of 2.3.1.  I thought it got replaced a few days
later.  I'm not quite sure -- because I ended up just building 2.3.1
myself -- but I think the bad one was dated June 11 and the good one June
14.

You might want to install the 2.2.0 RPM, which I *know* to be good.  In
fact I had to bootstrap from that again a few days ago after I managed to
hose my development version of d2c :-(

-- Bruce



Sat, 26 Jan 2002 03:00:00 GMT  
 Installing Gwydion Dylan on x86 Linux

Quote:

>There was a bad RPM build of 2.3.1.  I thought it got replaced a few days
>later.  I'm not quite sure -- because I ended up just building 2.3.1
>myself -- but I think the bad one was dated June 11 and the good one June
>14.

The RPM I downloaded, from The Federated Software Group, was dated
June 13th. The RPM at berline.ccc.de also has the same date. Perhaps
the RPM is still broken.

Quote:
>You might want to install the 2.2.0 RPM, which I *know* to be good.  In
>fact I had to bootstrap from that again a few days ago after I managed to
>hose my development version of d2c :-(

I downloaded 2.2.0 last night and was able to recompile 2.2.0. I will
try to compile 2.3.1 with it.

Thanks,
Mark

--

University of Illinois at Urbana-Champaign
Real-Time Systems Laboratory
--



Sat, 26 Jan 2002 03:00:00 GMT  
 Installing Gwydion Dylan on x86 Linux

Quote:

>>There was a bad RPM build of 2.3.1.  I thought it got replaced a few days
>>later.  I'm not quite sure -- because I ended up just building 2.3.1
>>myself -- but I think the bad one was dated June 11 and the good one June
>>14.

>The RPM I downloaded, from The Federated Software Group, was dated
>June 13th. The RPM at berline.ccc.de also has the same date. Perhaps
>the RPM is still broken.

Oops! I didn't try the RPMs because I wasn't confident that they were
relocatable. I used the 2.3.1 tarball dated June 8th instead. It seems
to be broken. I am in the process of building 2.3.1 using 2.2.0. Seems
to be going fine.

Mark

--

University of Illinois at Urbana-Champaign
Real-Time Systems Laboratory
--



Sat, 26 Jan 2002 03:00:00 GMT  
 Installing Gwydion Dylan on x86 Linux
I'm having trouble with the PPC binary RPMs for d2c.  Installing either
2.3.1 or 2.2.0 results in d2c always reporting 'wrong number of
arguments, wanted at least 1 but got 0' no matter what the command
line.  This obviously causes the bootstrap build to fail.

I tried bootstrapping using Mindy, but my poor machine was brought to
its knees going that route ;-)

Any suggestions?

        -- Tim Olson



Sat, 26 Jan 2002 03:00:00 GMT  
 Installing Gwydion Dylan on x86 Linux

Quote:

> I'm having trouble with the PPC binary RPMs for d2c.  Installing either
> 2.3.1 or 2.2.0 results in d2c always reporting 'wrong number of
> arguments, wanted at least 1 but got 0' no matter what the command
> line.  This obviously causes the bootstrap build to fail.

Haven't seen that.

What system are you running on, Tim?  2.2.0 worked fine on my G3/266
PowerBook and LinuxPPC R4.

-- Bruce



Sun, 27 Jan 2002 03:00:00 GMT  
 Installing Gwydion Dylan on x86 Linux

Quote:

> > I'm having trouble with the PPC binary RPMs for d2c.  Installing either
> > 2.3.1 or 2.2.0 results in d2c always reporting 'wrong number of
> > arguments, wanted at least 1 but got 0' no matter what the command
> > line.  This obviously causes the bootstrap build to fail.

Bruce Holt replied:

Quote:
> What system are you running on, Tim?  2.2.0 worked fine on my G3/266
> PowerBook and LinuxPPC R4.

Hi, Bruce -- I'm running LinuxPPC R5 on an 8600/300 (604e Mach5).
Here's a backtrace from gdb when running d2c --version (the code first
gets a SIGSEGV in the GC init code, which I assume is intended, then
fails here):

-----------
#0  0x166a178 in __kill () at soinit.c:59
#1  0x1669e80 in gsignal () at ../sysdeps/posix/raise.c:27
#2  0x166b69c in abort () at ../sysdeps/generic/abort.c:139
#3  0x1a106b0 in baseZutilsZfind_in_METH ()
#4  0x1a15044 in baseZutilsZinvoke_de{*filter*}_METH_GENERIC ()
#5  0x1b5a480 in dylanZdylan_visceraZgf_call_FUN ()
#6  0x1bd07e4 in dylanZdylan_visceraZdefault_handler_METH_GENERIC_2 ()
#7  0x1b5a480 in dylanZdylan_visceraZgf_call_FUN ()
#8  0x1bcb0ac in dylanZdylan_visceraZsignal_METH_INT_search ()
#9  0x1bcf82c in dylanZdylan_visceraZsignal_METH_GENERIC ()
#10 0x1b5a480 in dylanZdylan_visceraZgf_call_FUN ()
#11 0x1bcb328 in dylanZdylan_visceraZerror_METH_2 ()
#12 0x1bcf694 in
dylanZdylan_visceraZwrong_number_of_arguments_error_METH ()
#13 0x1b5a14c in dylanZdylan_visceraZgf_call_FUN ()
#14 0x1bd4088 in dylanZdylan_visceraZPCTmain_METH ()
#15 0x1800e20 in mainZdylan_visceraZcommand_line_entry_FUN ()
#16 0x1800db8 in inits ()
#17 0x1bdebc0 in real_main ()
#18 0x1800df4 in main ()
#19 0x1800be4 in _start ()
#20 0x178b43c in frame_dummy ()
------------

Looks like gf-call in func.dylan (dylan runtime) fails right at the
beginning:

define constant gf-call
  = method (self :: <generic-function>, nargs :: <integer>)
      let specializers = self.function-specializers;
      let nfixed = specializers.size;
      if (nfixed ~== nargs)
        if (self.function-rest? | self.function-keywords)
          if (nargs < nfixed)
            wrong-number-of-arguments-error(#f, nfixed, nargs);
          end;

Any ideas?

        -- Tim Olson



Sun, 27 Jan 2002 03:00:00 GMT  
 Installing Gwydion Dylan on x86 Linux

Quote:

> I don't see how it can fail at that point :-(

I'll keep poking around with gdb, but it's hard to get much more info
from it.

Quote:
> Tim, while you're here, can you have a look at the latest version of
> src/d2c/runtime/c-code/{*filter*}oline.c (you might have to look in the cvs at
> < http://www.*-*-*.com/ {*filter*}oline...>)
> and give me the real oil about whether all the sync's and isync's are
> really necessary?  The manuals I have are not in complete agreement on
> this...  Thanks!

They aren't in complete agreement because (unfortunately) the
requirements for code synchronization are implementation-dependent, not
architecturally specified.  Use the 604/750 sequence you have now, which
will work correctly on all processors currently defined (and should work
on future processors).  Yes, the SYNC after the ICBI's is required on
the 604.

        -- Tim Olson



Sun, 27 Jan 2002 03:00:00 GMT  
 Installing Gwydion Dylan on x86 Linux

Quote:

> Has anyone else tried d2c on LinuxPPC R5 (I'm still on R4).  Andreas?

Well, I remember seeing these problems, but I don't remember how I got
rid of them. I suspect it's really an R4 vs R5 issue (and you should
upgrade, R5 is _way_ more stable).

I think I'll upload a R5 binary these days.

Andreas

--
"We show that all proposed quantum bit commitment schemes are insecure because
the sender, Alice, can almost always cheat successfully by using an
Einstein-Podolsky-Rosen type of attack and delaying her measurement until she
opens her commitment." ( http://xxx.lanl.gov/abs/quant-ph/9603004 )



Sun, 27 Jan 2002 03:00:00 GMT  
 Installing Gwydion Dylan on x86 Linux

Quote:


> > Has anyone else tried d2c on LinuxPPC R5 (I'm still on R4).  Andreas?

> Well, I remember seeing these problems, but I don't remember how I got
> rid of them. I suspect it's really an R4 vs R5 issue (and you should
> upgrade, R5 is _way_ more stable).

> I think I'll upload a R5 binary these days.

Yep, looks like an R4 vs R5 libc-start issue.  When I set a breakpoint
on main() in d2c and examine the registers, I see that r3=0 (argc),
which should have been set up by the libc-start code.

Are you folks coding your own "start" code (called before main)?  Here's
what I see on the current d2c, breaking at main:

Breakpoint 1, 0x1800ddc in main ()
(gdb) where
#0  0x1800ddc in main ()
#1  0x1800be4 in _start ()
#2  0x178b43c in frame_dummy ()

Compare that with a simple C program compiled under R5:
(gdb) where
#0  0x180040c in main ()
#1  0x16df7d4 in __libc_start_main () at
../sysdeps/powerpc/elf/libc-start.c:106

        -- Tim Olson



Sun, 27 Jan 2002 03:00:00 GMT  
 Installing Gwydion Dylan on x86 Linux

Quote:

> Are you folks coding your own "start" code (called before main)?  Here's

No. Our entry point is main.

Quote:
> what I see on the current d2c, breaking at main:

> Breakpoint 1, 0x1800ddc in main ()
> (gdb) where
> #0  0x1800ddc in main ()
> #1  0x1800be4 in _start ()
> #2  0x178b43c in frame_dummy ()

> Compare that with a simple C program compiled under R5:
> (gdb) where
> #0  0x180040c in main ()
> #1  0x16df7d4 in __libc_start_main () at
> .../sysdeps/powerpc/elf/libc-start.c:106

Your version of d2c was compiled under R4. It seems that the startup
has changed.

I just discovered a bug in my local tree of d2c, which I can't get rid
of without a full bootstrap. I'll upload a new version tomorrow.

Andreas

--
"We show that all proposed quantum bit commitment schemes are insecure because
the sender, Alice, can almost always cheat successfully by using an
Einstein-Podolsky-Rosen type of attack and delaying her measurement until she
opens her commitment." ( http://xxx.lanl.gov/abs/quant-ph/9603004 )



Sun, 27 Jan 2002 03:00:00 GMT  
 Installing Gwydion Dylan on x86 Linux

Quote:


> > Are you folks coding your own "start" code (called before main)?  Here's

> No. Our entry point is main.

> > what I see on the current d2c, breaking at main:
> I just discovered a bug in my local tree of d2c, which I can't get rid
> of without a full bootstrap. I'll upload a new version tomorrow.

That would be great -- thanks!

        -- Tim Olson



Sun, 27 Jan 2002 03:00:00 GMT  
 Installing Gwydion Dylan on x86 Linux

Quote:
> the code first
> gets a SIGSEGV in the GC init code, which I assume is intended

Yes, just "handle SIGSEGV nostop noprint", or similar.  Or just "cont"...

Quote:
> #12 0x1bcf694 in
> dylanZdylan_visceraZwrong_number_of_arguments_error_METH ()
> #13 0x1b5a14c in dylanZdylan_visceraZgf_call_FUN ()
> #14 0x1bd4088 in dylanZdylan_visceraZPCTmain_METH ()
> #15 0x1800e20 in mainZdylan_visceraZcommand_line_entry_FUN ()
> Looks like gf-call in func.dylan (dylan runtime) fails right at the
> beginning:

Right.  Which means that %main() is calling a generic function wrong, and
the only GF it calls with runtime dispatch is "apply(main, args);"  (all
the argc parsing stuff is optomised to known function calls).

define method %main (argc :: <integer>, argv :: <raw-pointer>) => ();
  let args = make(<vector>, size: argc);
  for (index :: <integer> from 0 below argc)
    let argptr = pointer-deref(#"ptr", argv,
                               index * c-expr(#"int", "sizeof(void *)"));
    args[index] := import-string(argptr);
  end for;
  apply(main, args);
end method %main;

d2c's main() is defined as "define method main (argv0 :: <byte-string>,
#rest args) => ();", as usual, so it's only expecting one arg.  Which
*should* be there.

I don't see how it can fail at that point :-(

Has anyone else tried d2c on LinuxPPC R5 (I'm still on R4).  Andreas?

Tim, while you're here, can you have a look at the latest version of
src/d2c/runtime/c-code/{*filter*}oline.c (you might have to look in the cvs at
< http://www.*-*-*.com/ {*filter*}oline...>)
and give me the real oil about whether all the sync's and isync's are
really necessary?  The manuals I have are not in complete agreement on
this...  Thanks!

-- Bruce



Mon, 28 Jan 2002 03:00:00 GMT  
 Installing Gwydion Dylan on x86 Linux

Quote:

> > and give me the real oil about whether all the sync's and isync's are
> > really necessary?  The manuals I have are not in complete agreement on
> > this...  Thanks!

> They aren't in complete agreement because (unfortunately) the
> requirements for code synchronization are implementation-dependent, not
> architecturally specified.  Use the 604/750 sequence you have now, which
> will work correctly on all processors currently defined (and should work
> on future processors).  Yes, the SYNC after the ICBI's is required on
> the 604.

Ok, thanks.  Good to have you run your eye over it.

For those who don't recognise him, Tim knows a thing or two about PPC
internals, and I'm sure a good deal more than he's allowed to say :-)

-- Bruce



Mon, 28 Jan 2002 03:00:00 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Gwydion Dylan packages for RedHat Linux 5.0

2. Installing Dylan on SuSE Linux 8

3. Gwydion Dylan 2.2.0 Released

4. Where to put gc libs for Gwydion Dylan 2.3.10

5. Gwydion Dylan 2.3.9 Released

6. Gwydion-Dylan 2.3.6 much bigger?

7. Gwydion Dylan Release 2.3.5

8. Gwydion Dylan - MacOS X Carbon Demos

9. Gwydion Dylan 2.3.4 Released

10. Mac-d2c port of Mac application in gwydion dylan archive

11. Gwydion Dylan 2.3.3 released

12. ncurses and Gwydion Dylan

 

 
Powered by phpBB® Forum Software