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

Tue May 30 17:35:24 EDT 2006

AAARRG Tim,

You have just both saved me from experimentation and doused my hopes in
SUSE salvation.
SUSE 10 was my target distro to work out of my FC-5 dilemma.
Thank you very much for your report - I think...

I find it interesting that jnos compiled on slackware at an ealier time
can run OK.
--> I use Slackware pre-compiled jnos2.0d successfully with FC-5 &
glibc2.4 (several variants of "d").
It is only when:

      * jnos2.0e on Slackware 9.1 uses gcc3.2.3 
      * also FC-2 with gcc3.2.5
      * You compile on SUSE-10
      * I compile jnos2.0e on FC-5 & gcc4.1

that the engineering change shows up for glibc2.4.
I suspect that glibc2.3.x systems work OK (I don't have one at this
moment).

This of course suggests that jnos"e" version introduced the longjmp into
ksubr.c while at the same time gcc designers were changing longjmp
specifications applied in (recent?) c version releases.
But I'm a newcomer and don't know the version history well enough to
speak to a whole story.
Maiko clearly has done homework with FC-5 and gotten the same problem
definition as I did.

I see some solution options for myself:

     1. Find another (old & cheap?) computer for the jnos2.0e testbed on
        a older Linux with gcc3.x and glib2.3.x
     2. Continue with jnos2.0d until 2.0x solves this issue (Maiko -
        please do not see this as pressure from the user community)
     3. Find a way to support both glib2.3 & glib2.4 on FC-5
        simultaneously

and I am looking toward #3 because it addresses other issues for the
long haul...
Today I have no solution in hand - my doc project slows down if I choose
#2...

Of interest?
see Linux Journal June 2006 etc/rant: "Bottom line - if you're already a
Fedora fan, you'll want Core 5.  If you use anything else, now is not
the time to switch."  Emphasis by me.

I want to echo your sentiments "always something" and "kudos Maiko" and
"isn't urgent".
Seems right to me.

On Mon, 2006-05-29 at 13:52 -0500, Tim Gorman wrote:

> 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
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs

73
de Skip k8rra k

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20060530/20072f09/attachment.html>