scsh-hackers
[Top] [All Lists]

[Scsh-hackers] [ scsh-Bugs-408117 ] dynload problems on newer *BSD

To: noreply@sourceforge.net
Subject: [Scsh-hackers] [ scsh-Bugs-408117 ] dynload problems on newer *BSD
From: nobody <nobody@sourceforge.net>
Date: Mon, 12 Mar 2001 19:24:32 -0800
List-id: Discussion among the implementors <scsh-hackers.lists.sourceforge.net>
Sender: scsh-hackers-admin@lists.sourceforge.net
Bugs #408117, was updated on 2001-03-12 19:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110493&aid=408117&group_id=10493

Category: scheme-48
Group: None
Status: Open
Priority: 5
Submitted By: Brian D. Carlstrom
Assigned to: Brian D. Carlstrom
Summary: dynload problems on newer *BSD

Initial Comment:
From: Alan Bawden <Alan@lcs.mit.edu>
Sender: Alan@lcs.mit.edu
To: shivers@ai.mit.edu
Cc: scsh@martigny.ai.mit.edu, scheme48-
bugs@martigny.ai.mit.edu
Subject: dynload
Date: Fri, 4 Apr 1997 16:31:07 -0500

   Date: 04 Apr 1997 15:44:48 -0500
   From: Olin Shivers <shivers@ai.mit.edu>
   I didn't change cig, but I did scan all the scsh C 
source. Outside of
   userinfo1.c, I found no errorful code, although I 
did armor-plate a few
   other occurrences here and there, as well.

Great!

I forget if I sent this patch to you already.  The way 
dlopen() reports an
error seems to have changed at some point, and FreeBSD 
now does it the way
the rest of the world does.  (It now returns 0 instead 
of -1.)  I wouldn't
be surprised to find that NetBSD now works this way as 
well.  I don't know
if it is worth doing the autoconfig work needed to 
make the old way
continue to work in the older Unix versions.

Hmmm...  This is actually a Scheme48 bug isn't it.  
What's your policy on
that?  Do you want them to fix it first, or are you 
willing to include
Scheme48 fixes in scsh?

I've CC'd this message to scheme48-bugs because I 
don't rememebr if I've
reported this to them either...

--- scsh-0.4.4/dynload.c.orig   Sat Nov  4 16:10:51 
1995
+++ scsh-0.4.4/dynload.c        Thu Jan  9 02:30:20 
1997
@@ -29,7 +29,7 @@

 #include <stdlib.h>
 #include <unistd.h>
-#if defined(__NetBSD__) || defined(__FreeBSD__)
+#if defined(__NetBSD__)
 #include <nlist.h>
 #include <link.h>
 #else
@@ -96,7 +96,7 @@
     return -1;
   };
   newhandle=dlopen(pathname, S48_DLOPEN_MODE);
-#if defined(__NetBSD__) || defined(__FreeBSD__)
+#if defined(__NetBSD__)
   if (newhandle == -1) {
     fprintf(stderr, " dynamic_load of %s can't dlopen 
%s",
            sharedobjname, pathname);






----------------------------------------------------------------------

Comment By: Brian D. Carlstrom
Date: 2001-03-12 19:19

Message:
Logged In: YES 
user_id=27364

From: Alan Bawden <Alan@LCS.MIT.EDU>
Sender: Alan@LCS.MIT.EDU
To: bdc@ai.mit.edu
Subject: dynload
Date: Fri, 4 Apr 1997 16:51:00 -0500

   From: "Brian D. Carlstrom" <bdc@martigny.ai.mit.edu>
   Date: Fri, 4 Apr 1997 13:40:12 -0800
   Reply-To: "Brian D. Carlstrom" <bdc@ai.mit.edu>

   Alan Bawden writes:
    > I forget if I sent this patch to you already.  The 
way dlopen() reports a\
n
    > error seems to have changed at some point, and 
FreeBSD now does it the wa\
y
    > the rest of the world does.  (It now returns 0 
instead of -1.)  I wouldn'\
t   
    > be surprised to find that NetBSD now works this way 
as well.  I don't kno\
w  
    > if it is worth doing the autoconfig work needed to 
make the old way
    > continue to work in the older Unix versions.
   This doesn't help for people running older versions of 
FreeBSD.  I think
   that includes Olin and I. Should we accept either as an 
error? sigh.
   maybe you can give us the #ifdef based on the freebsd 
version number.

Hmm...  The oldest FreeBSD machine I can find is running 
1.1.5.1, and it
seems to return 0 there, so I can't tell you when it 
happened.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110493&aid=408117&group_id=10493


<Prev in Thread] Current Thread [Next in Thread>