<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.10.1">
</HEAD>
<BODY>
AAARRG Tim,<BR>
<BR>
You have just both saved me from experimentation and doused my hopes in SUSE salvation.<BR>
SUSE 10 was my target distro to work out of my FC-5 dilemma.<BR>
Thank you very much for your report - I think...<BR>
<BR>
I find it interesting that jnos compiled on slackware at an ealier time can run OK.<BR>
--> I use Slackware pre-compiled jnos2.0d successfully with FC-5 & glibc2.4 (several variants of "d").<BR>
It is only when:
<>
    <LI>jnos2.0e on Slackware 9.1 uses gcc3.2.3 
    <LI>also FC-2 with gcc3.2.5
    <LI>You compile on SUSE-10
    <LI>I compile jnos2.0e on FC-5 & gcc4.1
</UL>
that the engineering change shows up for glibc2.4.<BR>
I suspect that glibc2.3.x systems work OK (I don't have one at this moment).<BR>
<BR>
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.<BR>
But I'm a newcomer and don't know the version history well enough to speak to a whole story.<BR>
Maiko clearly has done homework with FC-5 and gotten the same problem definition as I did.<BR>
<BR>
I see some solution options for myself:
<OL TYPE=1>
    <LI TYPE=1 VALUE=1>Find another (old & cheap?) computer for the jnos2.0e testbed on a older Linux with gcc3.x and glib2.3.x
    <LI TYPE=1 VALUE=2>Continue with jnos2.0d until 2.0x solves this issue (Maiko - please do <U>not</U> see this as pressure from the user community)
    <LI TYPE=1 VALUE=3>Find a way to support both glib2.3 & glib2.4 on FC-5 simultaneously
</OL>
and I am looking toward #3 because it addresses other issues for the long haul...<BR>
Today I have no solution in hand - my doc project slows down if I choose #2...<BR>
<BR>
Of interest?<BR>
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 <B>not</B> the time to switch."  Emphasis by me.<BR>
<BR>
I want to echo your sentiments "always something" and "kudos Maiko" and "isn't urgent".<BR>
Seems right to me.<BR>
<BR>
On Mon, 2006-05-29 at 13:52 -0500, Tim Gorman wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Maiko,</FONT>

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

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

<FONT COLOR="#000000">I think I can get my hands on an old load of Suse 9.1. I'm going to try it </FONT>
<FONT COLOR="#000000">next.</FONT>

<FONT COLOR="#000000">It seems like it is always something, right?</FONT>

<FONT COLOR="#000000">Keep up the good work. This isn't an urgent thing for me so enjoy your family </FONT>
<FONT COLOR="#000000">life rather than being buried in this.</FONT>

<FONT COLOR="#000000">tim ab0wr</FONT>

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

<FONT COLOR="#000000">_______________________________________________</FONT>
<FONT COLOR="#000000">nos-bbs mailing list</FONT>
<FONT COLOR="#000000"><A HREF="mailto:nos-bbs@lists.tapr.org">nos-bbs@lists.tapr.org</A></FONT>
<FONT COLOR="#000000"><A HREF="https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs">https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs</A></FONT>
</PRE>
</BLOCKQUOTE>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
73<BR>
de Skip k8rra k<BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>