[nos-bbs] JNOS (any NOS) and Fedora Core 5 - the bottom line.

[Tim Gorman]

Maiko,

This same problem exists with Suse 10.1. I downloaded the base setup for 10.1 
and put it on an old Compaq I acquired. When I try to complile jnos I get an 
error in ksubr.c (I think that is the routine) complaining about some JB_?? 
defines. (something about jmp_buf anyway).

I tried doing an old install of Suse 8.2 but the base install has a problem 
with something that keeps jnos from running. The 8.2 load I have it running 
on has had the kernel updated many times. I tried getting by with a very 
small load but I may have to do a load that allows me to do a software update 
from Suse (if they still have 8.2 online).

I think I can get my hands on an old load of Suse 9.1. I'm going to try it 
next.

It seems like it is always something, right?

Keep up the good work. This isn't an urgent thing for me so enjoy your family 
life rather than being buried in this.

tim ab0wr

On Sunday 28 May 2006 21:52, maiko at pcs.mb.ca wrote:
> Greetings all,
>
> For the fun of it - I had time to pass at work - I took a look
> at compiling JNOS for Fedora Core 5 a few days ago, and I did
> some research on the results.
>
> The bottom line is that the jmp_buf mechanism will no longer be
> able to be used, and will have to be replaced with the context
> mechanism instead. In other words, setjmp/longjmp will have to
> be replaced with setcontext/getcontext, or something along that
> line. This may not be as difficult as it seems, since I see old
> references to the 'context' method in the code. It was specific
> to the SUN platform. I've been able to compile a version using
> this method, but have yet to get it to run with out a crash.
>
> In FC5 and other systems that use the particular GLIBC, the
> pointer returned by the longjmp() call is apparently mangled
> now (for security, buffer overflow hack protection, etc), so
> the value initially set by the setjmp() call, will return as
> a completely differently value when longjmp() is called, and
> of course a crash will result.
>
> There is apparently some ASM code that one can imbed in the
> source to get around this, and continue using setjmp/longjmp,
> but it looks very tricky, and is very platform dependent. The
> only example I found (so far) is not very clear to follow :-(
>
> Regards,
>
> Maiko Langelaar / VE4KLM
>
>
>
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs