I installed the trial version of Allegro on a Powerbook G3 (Wallstree)
that's running Yellow Dog Linux 2.0. I was able to dump out an ANSI
image, but it dies on a segfault when I try to actually do any work with
it.
After contacting Franz, it would appear that this is likely related to
an incompatibility between Allegro and YDL (note---they don't claim to
support it, so I'm not complaining). Before I wipe the machine and try
to install a now out of date version of LinuxPPC, I was wondering if
anybody here has use ACL 6.0 on this hardware and what OS configuration
you're using to do it.
^L
Allegro 6.0 works just fine on LinuxPPC 2000, so if you do decide to
scrape and reinstall, it won't be for naught.
I did once coerce a version of Allegro prior to 6.0 into running on
Yellow Dog, but I've forgotten the details of how I did it. It was
something to do with needing a back version of libc/glibc.
There was a program (supplied with Yellow Dog, with an alpahbet-soup
name) that could patch your executables (main and shared libraries) that
when applied to the appropriate Allegro components made them work. I
was really surprised that it did.
I got the hint on what to try from someone else on this newsgroup, after
posting the error message I got when it crapped out.
--
Remove obvious stuff to e-mail me.
Bob Bane
In article <·················@removeme.gst.com>, Bob Bane
<····@removeme.gst.com> wrote:
> I got the hint on what to try from someone else on this newsgroup, after
> posting the error message I got when it crapped out.
I poked around a bit on Google groups but didn't find anything relevant
and had limited success fighting with RPM to make two versions of
glibc---each of which wants to call itself libc.so.6---co-exist on the
same machine.
Do Linux distributors care about any program that isn't written in C and
shipped as source?
^L
[ Louis Theran ]
> I poked around a bit on Google groups but didn't find anything relevant
> and had limited success fighting with RPM to make two versions of
> glibc---each of which wants to call itself libc.so.6---co-exist on the
> same machine.
Package systems are fine, as long as one don't want to do anything
special. I'd try to get glibc as a tar archive (building from source
should be doable too if you can't get precompiled), and possibly put
it some special place and use $LD_LIBRARY_PATH in a wrapper script.
> Do Linux distributors care about any program that isn't written in C
> and shipped as source?
That's a rhetorical question, isn't it?
Martin
--
"An ideal world is left as an exercise to the reader."
-Paul Graham, On Lisp
Martin Thornquist <············@ifi.uio.no> writes:
> [ Louis Theran ]
>
> > Do Linux distributors care about any program that isn't written in C
> > and shipped as source?
>
> That's a rhetorical question, isn't it?
I don't take it as such. And I suspect that with respect to signal
handling, the answer is "no". Linux, both on x86 and on ppc, have
been absolutely terrible about compliance with any signal-delivery
standard at all, which has been the majority of the cause of our
inability to operate on any but the specific linux systems with which
we have tested our product. Some of the kernels do not deliver signals
with a three-argument signal-handler, but with zero, one or two arguments
depending on the whim of the kernel. Other systems are consistent
about which argument provides the context, but is not consistent about
whether the sigcontext, ucontext, or some other structure is being
provided. In some cases, I have tried to establish heuristics, looking
at what might be reasonable possibilities for contexts, but it is not
easy to get it right over a wide range of kernal/libc versions.
I would love to see linux move to a standards compliance in the area
of signal handling (such as Posix). I think that they are starting
to finally move in that direction, but of course in a non-upward-
compatible way. Meanwhile, our lisp can only run on those systems
on which we have specifically configured the signal-handling to work.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig wrote:
> Martin Thornquist <············@ifi.uio.no> writes:
>
>
>>[ Louis Theran ]
>>
>>
>>>Do Linux distributors care about any program that isn't written in C
>>>and shipped as source?
>>>
>>That's a rhetorical question, isn't it?
>>
>
> I don't take it as such. And I suspect that with respect to signal
> handling, the answer is "no". Linux, both on x86 and on ppc, have
> been absolutely terrible about compliance with any signal-delivery
> standard at all, which has been the majority of the cause of our
> inability to operate on any but the specific linux systems with which
> we have tested our product. Some of the kernels do not deliver signals
> with a three-argument signal-handler, but with zero, one or two arguments
> depending on the whim of the kernel. Other systems are consistent
> about which argument provides the context, but is not consistent about
> whether the sigcontext, ucontext, or some other structure is being
> provided. In some cases, I have tried to establish heuristics, looking
> at what might be reasonable possibilities for contexts, but it is not
> easy to get it right over a wide range of kernal/libc versions.
Unix has had a long tradition of shipping programs as source. GNU/Linux
has an even stronger one. Given the Free Software and Open Source
movements created it I don't see that changing. I believe that most
distributions use glibc which has been pretty consistant. Signal
handling has alway been a problem for Unix its no surprise Linux has
similar problems.
By the way the installer program and most of the utilities Red Hat
writes are in Python. I use Python and find it about as expressive
as LISP. It doesn't treat code as data so much of the ablility to
have programs write other programs is lost. I also think LISP is
faster if only because it has decades to be perfected.
> I would love to see linux move to a standards compliance in the area
> of signal handling (such as Posix). I think that they are starting
> to finally move in that direction, but of course in a non-upward-
> compatible way. Meanwhile, our lisp can only run on those systems
> on which we have specifically configured the signal-handling to work.
CLISP, CMUCL and its derivatives seem to move from distribution to
distribution quite well and I use them both. This would seem to apply
to the Red Hat and Debian distribution which cover most of the GNU/Linux
users.
--
Daniel E. Wilson <·······@teleport.com>
If you don't have freedom as a principle, you can never
see a reason not to make an exception.
- Richard M. Stallman
On Sat, 30 Jun 2001, Daniel E. Wilson wrote:
[snip]
> By the way the installer program and most of the utilities Red Hat
> writes are in Python. I use Python and find it about as expressive
> as LISP. It doesn't treat code as data so much of the ablility to
> have programs write other programs is lost. I also think LISP is
> faster if only because it has decades to be perfected.
[snip]
Just FYI, it's also traditionally been the case that the Python VM is
optimized for simplicity and portability and *not* speed. There was a
single-person effort to produce a very high performance via heroic
compiler efforts (e.g., whole world analysis and type inference) called
Viper or Vyper but it bogged down. There wasn't a significant amount of
enthusiasm or (especially finacial) support for it from the Python
community.
How slow is the standard CPython implementation? Well, the move from
1.4.x to 1.5.x produced a 2x increase on benchmarks without a lot of
effort and no major, IIRC, architectural revision (i.e., no method cache,
no JIT). There are a lot of modules and constructs that are light
interfaces to a set of C functions so a common optimization is to try to
get just such C functions in your time-critical inner loop (writing such
if necessary).
It seems worth noting this because Python (the common
implementations) *is* slow and that doesn't seem to be a barrier for
acceptance. (Tcl has generally had slow implementations and that *does*
seem to be some sort of barrier.) I'm sure the easy C integration has been
a riposte to speed complains ("use the right tool!") but it's also true,
I'd wadger, that the *vast* majority of Python programmers don't drop down
to C all that often, and get along fine. Interesting psychology.
Cheers,
Bijan Parsia.
Bijan Parsia wrote:
> On Sat, 30 Jun 2001, Daniel E. Wilson wrote:
> [snip]
>
>>By the way the installer program and most of the utilities Red Hat
>>writes are in Python. I use Python and find it about as expressive
>>as LISP. It doesn't treat code as data so much of the ablility to
>>have programs write other programs is lost. I also think LISP is
>>faster if only because it has decades to be perfected.
>>
> [snip]
>
> It seems worth noting this because Python (the common
> implementations) *is* slow and that doesn't seem to be a barrier for
> acceptance. (Tcl has generally had slow implementations and that *does*
> seem to be some sort of barrier.) I'm sure the easy C integration has been
> a riposte to speed complains ("use the right tool!") but it's also true,
> I'd wadger, that the *vast* majority of Python programmers don't drop down
> to C all that often, and get along fine. Interesting psychology.
It always seemed to me that the Python crowd is willing to sacrifice
some run-time speed for development speed. I have always optimized for
speed after I get a program to work. Knuth was right about premature
optimization.
--
Daniel E. Wilson <·······@teleport.com>
If you don't have freedom as a principle, you can never
see a reason not to make an exception.
- Richard M. Stallman
On Sun, 1 Jul 2001, Daniel E. Wilson wrote:
[snip]
> > seem to be some sort of barrier.) I'm sure the easy C integration has been
> > a riposte to speed complains ("use the right tool!") but it's also true,
> > I'd wadger, that the *vast* majority of Python programmers don't drop down
> > to C all that often, and get along fine. Interesting psychology.
>
> It always seemed to me that the Python crowd is willing to sacrifice
> some run-time speed for development speed.
Well, it's more than "some"! It's "quite a lot" :) Note that they *are*
willing to drop down to C instead of having the compiler/VM
optimized *for the sake* of ease of vm portability/embedding/etc. Of
course, it's a little tougher than that since the VM decision was in one
person's hands, but the crowd seems comfy with it. So, it's a bit more
complicated that just sacrificing some run-time for development
speed. *Whose* development of *what*, comes in.
Note that when I said "interesting psychology" I meant that, unlike lisp,
Python doesn't suffer from the "Python is slow" criticism *even though*
it's largely true of Python. For Python, the "trade off" argument has
seemed to work.
Hmm. More precisely, it seems to have succeeded in fending off bizarre
doom and gloom pronoucements. Do large Python projects get rewritten in
C++ and if so does this mean that Python "failed"? Maybe, maybe not. It
seems more common to accept writing a bunch of prims in C or embedding a
py interpreter in a largely C program that it is for Lisp or
Smalltalk.
It's like the Lisp is too large complaint...which then gets coupled with
"Lisp lacks libraries" and "Java has oodles of libraries". It's not that
these are necessarily incoherent *per se*, but they are odd.
Cheers,
Bijan Parsia.
"Daniel E. Wilson" <·······@teleport.com> writes:
> Duane Rettig wrote:
>
> > Martin Thornquist <············@ifi.uio.no> writes:
> >
>
> >>[ Louis Theran ]
> >>
> >>
> >>>Do Linux distributors care about any program that isn't written in C
> >>>and shipped as source?
> >>>
> >>That's a rhetorical question, isn't it?
> >>
> > I don't take it as such. And I suspect that with respect to signal
>
> > handling, the answer is "no". Linux, both on x86 and on ppc, have
> > been absolutely terrible about compliance with any signal-delivery
> > standard at all, which has been the majority of the cause of our
> > inability to operate on any but the specific linux systems with which
> > we have tested our product. Some of the kernels do not deliver signals
> > with a three-argument signal-handler, but with zero, one or two arguments
> > depending on the whim of the kernel. Other systems are consistent
> > about which argument provides the context, but is not consistent about
> > whether the sigcontext, ucontext, or some other structure is being
> > provided. In some cases, I have tried to establish heuristics, looking
> > at what might be reasonable possibilities for contexts, but it is not
> > easy to get it right over a wide range of kernal/libc versions.
>
>
> Unix has had a long tradition of shipping programs as source. GNU/Linux
> has an even stronger one. Given the Free Software and Open Source
> movements created it I don't see that changing.
Unix also has a strong tradition of maintaining binary compatibility.
Just because source-code is available doesn't mean that it is
necessarily desirable to have to recompile your sources every time
you upgrade to a new version.
> I believe that most
> distributions use glibc which has been pretty consistant. Signal
> handling has alway been a problem for Unix its no surprise Linux has
> similar problems.
This is simply not true. It is true that there have been changes
in signal handling over the years, but for hardware unix vendors,
this usually is accompanied by a supreme effort to make such
changes backward-compatible, or to thoroughly document such changes.
I have seen neither of these efforts in Linux systems.
> > I would love to see linux move to a standards compliance in the area
> > of signal handling (such as Posix). I think that they are starting
> > to finally move in that direction, but of course in a non-upward-
> > compatible way. Meanwhile, our lisp can only run on those systems
> > on which we have specifically configured the signal-handling to work.
>
> CLISP, CMUCL and its derivatives seem to move from distribution to
> distribution quite well and I use them both. This would seem to apply
> to the Red Hat and Debian distribution which cover most of the GNU/Linux
> users.
I wouldn't be a bit surprised at this. I don't know the extent to
which either CLISP or CMUCL use signals, but if they make little use
of them, it would of course explain the greater portability between
system versions of these two implementations. But then some of the
advantages that direct signal handling affords would not be available,
either.
My point is that we don't have this signal compatibility problem with
any other operating systems to the degree we have with Linux. Not
even Windows :-)
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig wrote:
> "Daniel E. Wilson" <·······@teleport.com> writes:
>
> I wouldn't be a bit surprised at this. I don't know the extent to
> which either CLISP or CMUCL use signals, but if they make little use
> of them, it would of course explain the greater portability between
> system versions of these two implementations. But then some of the
> advantages that direct signal handling affords would not be available,
> either.
>
> My point is that we don't have this signal compatibility problem with
> any other operating systems to the degree we have with Linux. Not
> even Windows :-)
Few programs on Unix use signals. When they do that is when I tend to
see lots of conditionals to handle the different proprietary versions
of Unix. It wasn't just signals that tended to be different. Signals
always seemed to me to be something to be used only if there is no
other solution. Avoid if at all possible.
What you seem to be unhappy about is the change from libc5 to glibc. It
was almost as traumatic as the change from a.out to ELF executables. I
am of the opinion that it was a good idea. The nice thing about glibc
is that it moves to different platforms.
You may not have signal compatibility problems with Windows. You just
have to deal with all of the other problems Microsoft introduces with
each new version. My programs have moved from kernel to kernel with
fewer problems than I ever with Windows.
--
Daniel E. Wilson <·······@teleport.com>
If you don't have freedom as a principle, you can never
see a reason not to make an exception.
- Richard M. Stallman
"Daniel E. Wilson" <·······@teleport.com> writes:
> Duane Rettig wrote:
>
> > "Daniel E. Wilson" <·······@teleport.com> writes:
> > I wouldn't be a bit surprised at this. I don't know the extent to
>
> > which either CLISP or CMUCL use signals, but if they make little use
> > of them, it would of course explain the greater portability between
> > system versions of these two implementations. But then some of the
> > advantages that direct signal handling affords would not be available,
> > either.
> > My point is that we don't have this signal compatibility problem with
>
> > any other operating systems to the degree we have with Linux. Not
> > even Windows :-)
>
>
> Few programs on Unix use signals. When they do that is when I tend to
> see lots of conditionals to handle the different proprietary versions
> of Unix. It wasn't just signals that tended to be different. Signals
> always seemed to me to be something to be used only if there is no
> other solution. Avoid if at all possible.
I agree that few programs use signals to the extent that we use them,
and hence the reason for my zeroing in on standards conformance.
Avoidance of a hard thing is not necessary or desirable if the good
that comes out of it outweighs the pain. And Linux is the only operating
system that has given us this much pain in _this_ area.
> What you seem to be unhappy about is the change from libc5 to glibc. It
> was almost as traumatic as the change from a.out to ELF executables.
It was more traumatic. The transition to ELF was easy, because as huge
as the change was, it was _standard_! The signals transition was
more traumatic because there were no standards conformances that were
followed.
> I am of the opinion that it was a good idea.
I agree. However, since there are differences even in glibc versions,
it was problematic for programs which hoped to be portable from version
to version.
> The nice thing about glibc is that it moves to different platforms.
Agreed.
> You may not have signal compatibility problems with Windows. You just
> have to deal with all of the other problems Microsoft introduces with
> each new version. My programs have moved from kernel to kernel with
> fewer problems than I ever with Windows.
Please don't misunderstand my railing against Linux signal interfaces
as hatred of Linux in general. I greatly prefer Linux to Windows myself.
However, Linux has had this one problem which has always been a wart,
on an otherwise very nice system.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> I wouldn't be a bit surprised at this. I don't know the extent to
> which either CLISP or CMUCL use signals, but if they make little use
> of them, it would of course explain the greater portability between
> system versions of these two implementations. But then some of the
> advantages that direct signal handling affords would not be available,
> either.
CMUCL uses signals a lot. And I had to explain to many people why
incorrect signal handling was an error. Like:
- The FPU control word in a SIGFPU is not correct.
+ So, you're going to core dump anyway. Not?
- No I'm going to fix my code and restart the function.
+ <blank stare>
We've had a lot of problems going from glibc 2.0 to glibc 2.1. People
claim binary compatibility. Except for functions they don't like. An
no 'warning periods', no that is for woosies, no we just crash the
programs! Also the binutils people know this 'oh there was a bug in
the parser of as that we fixed. This fix will change the meaning of
code that worked correctly in the past. Should we add a warning
message about this? No, only gcc uses as, not?'
Grrr.
I want to use glibc as sparsely as possible, using direct kernel traps
for all essential work and using the dynamic loader for all the
fluff. That way at least I can expect cmucl to be able to recompile
itself if we ever go to glibc 2.3. The bloody kernel is still
compatible with very old code. It will print warning messages for 1
stable revision (2 years about) and then they will think about
removing the code. Sigh.
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org
"God, root, what is difference?" - Pitr|
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/
"Daniel E. Wilson" <·······@teleport.com> writes:
> By the way the installer program and most of the utilities Red Hat
> writes are in Python. I use Python and find it about as expressive
> as LISP. It doesn't treat code as data so much of the ablility to
> have programs write other programs is lost. I also think LISP is
> faster if only because it has decades to be perfected.
Because of the programmability of Lisp, I'd venture to say that Lisp is as
expressive as the programmer is capable of making it to be. When people
make comments about Lisp, often it's more of a reflection on their command
of the language, rather than about the language per se. So when you said
you found certain language about as expressive as Lisp, it probably means
your undertanding of language design is about as good as that of the
designer(s) of that language (which I presume is very good; certainly much
better than mine). However, I suspect you'll find a language can be much
more expressive if you stick with Lisp a little bit longer.
- huaiyuan
"Daniel E. Wilson" <·······@teleport.com> writes:
> CLISP, CMUCL and its derivatives seem to move from distribution to
> distribution quite well and I use them both. This would seem to apply
> to the Red Hat and Debian distribution which cover most of the GNU/Linux
> users.
CMU CL has had its fair share of problems coping with both lacking ABI
stability of glibc itself (at least 2.1 binaries seem now to work on
glibc 2.2 distributions, something which didn't work for 2.0 -> 2.1),
and with changes in memory mappings/allocations introduced by newer
kernels (whitness the memory_overcommit and more than 1GB RAM patch
problems).
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Duane Rettig <·····@franz.com> writes:
> we have tested our product. Some of the kernels do not deliver signals
> with a three-argument signal-handler, but with zero, one or two arguments
> depending on the whim of the kernel. Other systems are consistent
Huh? I've always had:
static void sigsegv_handler(HANDLER_ARGS)
{
os_vm_address_t addr;
#ifdef i386
GET_CONTEXT
#endif
In the Linux-os.c file with the magic:
#if (LINUX_VERSION_CODE >= linuxversion(2,1,0)) || (__GNU_LIBRARY__ >= 6)
#define HANDLER_ARGS int signal, struct sigcontext contextstruct
#define GET_CONTEXT int code=0; struct sigcontext *context=&contextstruct;
#else
#define HANDLER_ARGS int signal, struct sigcontext_struct contextstruct
#define GET_CONTEXT int code=0; struct sigcontext_struct *context=&contextstruct;
#endif
This has worked quite a long time. What kernels/distributions gave
problems?
> I would love to see linux move to a standards compliance in the area
> of signal handling (such as Posix). I think that they are starting
> to finally move in that direction, but of course in a non-upward-
> compatible way. Meanwhile, our lisp can only run on those systems
> on which we have specifically configured the signal-handling to work.
I've had more problems with 'enterprise' kernels that change the
memory-map available for programs :-(.
In general the glibc people don't care about non-C languages, look at
errno for an example ;-(
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org
"God, root, what is difference?" - Pitr|
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/
Peter Van Eynde <········@debian.org> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > we have tested our product. Some of the kernels do not deliver signals
> > with a three-argument signal-handler, but with zero, one or two arguments
> > depending on the whim of the kernel. Other systems are consistent
>
> Huh? I've always had:
>
> static void sigsegv_handler(HANDLER_ARGS)
> {
> os_vm_address_t addr;
>
> #ifdef i386
> GET_CONTEXT
> #endif
>
> In the Linux-os.c file with the magic:
>
> #if (LINUX_VERSION_CODE >= linuxversion(2,1,0)) || (__GNU_LIBRARY__ >= 6)
> #define HANDLER_ARGS int signal, struct sigcontext contextstruct
> #define GET_CONTEXT int code=0; struct sigcontext *context=&contextstruct;
> #else
> #define HANDLER_ARGS int signal, struct sigcontext_struct contextstruct
> #define GET_CONTEXT int code=0; struct sigcontext_struct *context=&contextstruct;
> #endif
This is a compile-time conditionalization. How do you provide binary
compatibility with such code? Such a compile-time inconsistency is
precisely the problem we deal with.
> This has worked quite a long time. What kernels/distributions gave
> problems?
We have in both x86 and ppc portions of our profiler code the following:
#if defined(__GLIBC__) && (__GLIBC__ == 2) && (__GLIBC_MINOR__ == 1)
which seems to define the break between some of the major kernel
differences. However, we have had to deal with kernels that don't
deliver the signals as they were supposed to (sorry, I don't know
precisely which ones gave the most trouble), and have had to perform
run-time adjustment of the contexts in order for them to match what
was in /usr/include, or to match what had been delivered in older
versions of the kernel.
As a more recent example, The differenc between LinuxPPC R6 and
LinuxPPC 2000 Q4 is very slight, but they have completely different
signal delivery; the former has a uname output that labels it a
2.2.15pre3 kernel, and the latter labels itself as 2.2.18bmacpatch.
Both claim to be __GLIBC__ == 2 and _GLIBC_MINOR__ == 1.
/etc/issue on each give few clues as to their differences:
On LinuxPPC R6:
Red Hat Linux release 6.1 (Cartman)
Kernel 2.2.15pre3 on a ppc
On LinuxPPC 200 Q4:
Linux/PPC 2000 Q4
Packages current to December 25 2000
Kernel 2.2.18bmacpatch on a ppc
I wouldn't want to see differences in signal handling on each of kernels
which are so close to each other.
This is one of the kinds of problems we have in maintaining binary
compatibility between releases on Linux.
> > I would love to see linux move to a standards compliance in the area
> > of signal handling (such as Posix). I think that they are starting
> > to finally move in that direction, but of course in a non-upward-
> > compatible way. Meanwhile, our lisp can only run on those systems
> > on which we have specifically configured the signal-handling to work.
>
> I've had more problems with 'enterprise' kernels that change the
> memory-map available for programs :-(.
Well, of course, mmap on all systems contain the caveat that you should
refrain from asking for a fixed address. That everyone does anyway
should not be a problem, as long as the awareness is there and memory
management is performed at the application level. Thus, I do not
consider this to be the portability problem that signals tend to be.
> In general the glibc people don't care about non-C languages, look at
> errno for an example ;-(
Yes, it's true that the errno codes are not always consistent, but at
least there is a standard runtime function we can run to get the
interpretation of the code: strerror(). There is no such runtime
interface to signals.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
>> #if (LINUX_VERSION_CODE >= linuxversion(2,1,0)) || (__GNU_LIBRARY__ >= 6)
>> #define HANDLER_ARGS int signal, struct sigcontext contextstruct
>> #define GET_CONTEXT int code=0; struct sigcontext *context=&contextstruct;
>> #else
>> #define HANDLER_ARGS int signal, struct sigcontext_struct contextstruct
>> #define GET_CONTEXT int code=0; struct sigcontext_struct *context=&contextstruct;
>> #endif
>
> This is a compile-time conditionalization. How do you provide binary
> compatibility with such code? Such a compile-time inconsistency is
> precisely the problem we deal with.
I have an old version (really old) in one of the archived debian
distributions. The newer one just exits on startup if it feels
something is not right, refering people to the older version :-).
The newest version will even default to lazy-memory allocation to
support those enterprise kernels. Sort-of: the moment you allocate
too much memory, it will crash.
> We have in both x86 and ppc portions of our profiler code the following:
>
> #if defined(__GLIBC__) && (__GLIBC__ == 2) && (__GLIBC_MINOR__ == 1)
>
> which seems to define the break between some of the major kernel
> differences. However, we have had to deal with kernels that don't
> deliver the signals as they were supposed to (sorry, I don't know
> precisely which ones gave the most trouble), and have had to perform
> run-time adjustment of the contexts in order for them to match what
> was in /usr/include, or to match what had been delivered in older
> versions of the kernel.
AFAIK the kernel has been pretty stable from 2.2 onwards on signal
handling. 2.2 is a nice base because previous kernels had issues with
mmap. 2.2 has problems with losing the FPU control word in signal
handles, but that can be overcome with ease. The major problem for
compatibility is glibc. I've come so far as to have a direct kernel
interface for most of my OS-related functions. The only part that
still uses glibc is the C loader/signal handler.
> As a more recent example, The differenc between LinuxPPC R6 and
> LinuxPPC 2000 Q4 is very slight, but they have completely different
> signal delivery; the former has a uname output that labels it a
> 2.2.15pre3 kernel, and the latter labels itself as 2.2.18bmacpatch.
> Both claim to be __GLIBC__ == 2 and _GLIBC_MINOR__ == 1.
What are the libc versions? (like /lib/libc-2.2.3.so or you should be
able to tell from the rpm's used) LinuxPPC is a more movable target
and I've noticed that even the C people had glibc base trouble.
>> In general the glibc people don't care about non-C languages, look at
>> errno for an example ;-(
>
> Yes, it's true that the errno codes are not always consistent, but at
> least there is a standard runtime function we can run to get the
> interpretation of the code: strerror(). There is no such runtime
> interface to signals.
What I meant is that from a normal memory location in glibc 1 (libc5)
it went to a macro that calls a function and dereferences the returned
pointer in glibc2 (libc6). Major problem if you are trying to
determine if your system call worked or not :-(.
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org
"God, root, what is difference?" - Pitr|
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/
Peter Van Eynde <········@debian.org> writes:
> Duane Rettig <·····@franz.com> writes:
>
> >> #if (LINUX_VERSION_CODE >= linuxversion(2,1,0)) || (__GNU_LIBRARY__ >= 6)
> >> #define HANDLER_ARGS int signal, struct sigcontext contextstruct
> >> #define GET_CONTEXT int code=0; struct sigcontext *context=&contextstruct;
> >> #else
> >> #define HANDLER_ARGS int signal, struct sigcontext_struct contextstruct
> >> #define GET_CONTEXT int code=0; struct sigcontext_struct *context=&contextstruct;
> >> #endif
> >
> > This is a compile-time conditionalization. How do you provide binary
> > compatibility with such code? Such a compile-time inconsistency is
> > precisely the problem we deal with.
>
> I have an old version (really old) in one of the archived debian
> distributions. The newer one just exits on startup if it feels
> something is not right, refering people to the older version :-).
Sort of a program-grained runtime decision, eh?
> The newest version will even default to lazy-memory allocation to
> support those enterprise kernels. Sort-of: the moment you allocate
> too much memory, it will crash.
Oops.
> > We have in both x86 and ppc portions of our profiler code the following:
> >
> > #if defined(__GLIBC__) && (__GLIBC__ == 2) && (__GLIBC_MINOR__ == 1)
> >
> > which seems to define the break between some of the major kernel
> > differences. However, we have had to deal with kernels that don't
> > deliver the signals as they were supposed to (sorry, I don't know
> > precisely which ones gave the most trouble), and have had to perform
> > run-time adjustment of the contexts in order for them to match what
> > was in /usr/include, or to match what had been delivered in older
> > versions of the kernel.
>
> AFAIK the kernel has been pretty stable from 2.2 onwards on signal
> handling. 2.2 is a nice base because previous kernels had issues with
> mmap. 2.2 has problems with losing the FPU control word in signal
> handles, but that can be overcome with ease. The major problem for
> compatibility is glibc. I've come so far as to have a direct kernel
> interface for most of my OS-related functions. The only part that
> still uses glibc is the C loader/signal handler.
Yes, I am heartened by the movement _toward_ a standard signal interface.
It is just that transition (and the compatibility problems that it causes
for customers) that is painful.
> > As a more recent example, The differenc between LinuxPPC R6 and
> > LinuxPPC 2000 Q4 is very slight, but they have completely different
> > signal delivery; the former has a uname output that labels it a
> > 2.2.15pre3 kernel, and the latter labels itself as 2.2.18bmacpatch.
> > Both claim to be __GLIBC__ == 2 and _GLIBC_MINOR__ == 1.
>
> What are the libc versions? (like /lib/libc-2.2.3.so or you should be
> able to tell from the rpm's used) LinuxPPC is a more movable target
> and I've noticed that even the C people had glibc base trouble.
Both the LinuxPPC R6 and LinuxPPC2000 Q4 have libc.2.1.3.so
> >> In general the glibc people don't care about non-C languages, look at
> >> errno for an example ;-(
> >
> > Yes, it's true that the errno codes are not always consistent, but at
> > least there is a standard runtime function we can run to get the
> > interpretation of the code: strerror(). There is no such runtime
> > interface to signals.
>
> What I meant is that from a normal memory location in glibc 1 (libc5)
> it went to a macro that calls a function and dereferences the returned
> pointer in glibc2 (libc6). Major problem if you are trying to
> determine if your system call worked or not :-(.
Ah, yes, the errno-per-thread problem. Actually, this is not a Linux-only
issue; every threads-based program must deal with the question of whether
they can trust the current value of errno; some systems have started adding
a function call, or a macro, as you say, for source compatibility, to get
the thread-specific errno value from "the right place" (wherever it is).
This is just something we have to learn to deal with.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Ah, yes, the errno-per-thread problem. Actually, this is not a Linux-only
> issue; every threads-based program must deal with the question of whether
> they can trust the current value of errno; some systems have started adding
> a function call, or a macro, as you say, for source compatibility, to get
> the thread-specific errno value from "the right place" (wherever it is).
Which is fine, but for the point that (in Linux) they don't document
what this function is. So you either look at the header file and pray
that they don't ever rename __errno_location(), or you wrap it in a C
function of your own whose name you do know.
(Option 1 is acceptable if you ship binary, because it's going to
break anyway if they rename that function. CMUCL otoh is source and
it would at least be _nice_ if it could be rebuilt when the ABI changes)
What's silly about the whole thing is that the syscalls themselves
return errors directly as negative numbers[*], and it's the C library
glue which hides it in a variable. If there was a supported interface
to the syscalls that just returned the error number as sent by the
kernel, we wouldn't have to muck about with making a second ffi call
at all. I doubt it's ever going to be time-critical, but it should be
unnecessary and I do think it's ugly.
[*] This is true on x86, at least. I don't know for certain about PPC
although I imagine it works the same way
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> What's silly about the whole thing is that the syscalls themselves
> return errors directly as negative numbers[*], and it's the C library
> glue which hides it in a variable. If there was a supported interface
> to the syscalls that just returned the error number as sent by the
> kernel, we wouldn't have to muck about with making a second ffi call
> at all. I doubt it's ever going to be time-critical, but it should be
> unnecessary and I do think it's ugly.
It's already done. Bar some issues that I hacked using without-gc it's
clean (I hacked it because I needed a quick fix and to test new VOP's
I need at least a month. Couldn't wait that long). All system calls
get generated by a little macro, and we have sane error handling
(except that it should get turned into a exception, but the higher
interface isn't prepared for this yet). See src/code/unix-syscall.lisp
and src/compiler/x86/syscall-linux.lisp (this defines the VOP's).
> [*] This is true on x86, at least. I don't know for certain about PPC
> although I imagine it works the same way
You can see it include/asm-ppc/unistd.h for instance. The part
#define __syscall_return(type) \
return (__sc_err & 0x10000000 ? errno = __sc_ret, __sc_ret = -1 : 0), \
(type) __sc_ret
seems to suggest it does work like that.
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org
"God, root, what is difference?" - Pitr|
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/
Long time ago, I tried ACL 6.0 on my Powerbook G3 233 (Wallstreet) that
running Linuxppc. Simply I couldn't implemented ACL, and still I don't
know why. If you fail to implement it like me, then you could try
OPEN-MCL for linuxppc.
http://openmcl.clozure.com/
It is very primitive, but worthy to try.
Good luck.
Sungwoo
>>>>> "Louis" == Louis Theran <······@cs.umass.edu> writes:
Louis> I installed the trial version of Allegro on a Powerbook G3
Louis> (Wallstree) that's running Yellow Dog Linux 2.0. I was able to
Louis> dump out an ANSI image, but it dies on a segfault when I try to
Louis> actually do any work with it.
We had some problems with ACL that sounds somewhat similar. We are
running the Enterprise edition of ACL 6 on a PPC running Debian Linux.
Our problem was that we could start up (at least on the distributed
images) and get a prompt and do various stuff, but in a number of
cases, such as when generating a type error, the system would
segfault.
This persisted across both ACL 5 and 6, trial versions or commercial
ones. We also tried downgrading the libc version (a very difficult
thing to do - we (or rather I :-) busted the system in the process so
we had to reinstall from scratch).
We were on the bank of getting seriously desperate, when I happened to
notice that Devian Linux commes with a number of precompiled
kernels. We had all along been running the default kernel supplied by
the installation process. I then tried installing a kernel image
package with the name:
kernel-image-2.2.15-pmac
Note the "pmac" extension.
After that was done, all our problems disappeared, so you may want to
check out what different sort of kernels YDL supports (or switch to
Debian, the One True Linux Distribution (IMHO)).
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)