RE: Glasgow Haskell on different versions of Linux
On 09 June 2004 20:09, Christian Maeder wrote: I wrote: since version 6.2 we have 2 binary distributions for (generic) linux: for glibc 2.2 and glibc 2.3 Maybe this is no longer necessary. I've produced an installation (under glibc 2.2) that runs under glibc 2.2 and glibc 2.3. I've now also successfully installed ghc-6.2.1 from source under glibc 2.3 that works under glibc 2.2, too. As also Volker Stolz suggested I've changed, after calling ./configure, a line in mk/config.h from #define HAVE_CTYPE_H 1 to /* #undef HAVE_CTYPE_H */ I'll try the same trick under glibc 2.3 later. Yes, that basically did it. Thus the glibc 2.3 version (without ctype.h) should be sufficient as binary distribution in the future. We want to support glibc 2.2. However, given that it is no longer the predominant flavour of glibc around, we don't want to put a lot of effort into supporting it, or to compromise our support for glibc 2.3. Trying to avoid ctype.h seems pretty fragile. I don't understand why undefining HAVE_CTYPE_H makes things work, and whether it will break anything else. Avoid ctype.h is yet another global invariant, and I've learned to avoid those where possible. This strikes me as simply not the right way to go. We can't be sure that there aren't other binary incompatibilies between glibc 2.2 and 2.3. The right way is just to have separate installations for the two systems. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow Haskell on different versions of Linux
In local.glasgow-haskell-users, you wrote: Christian Maeder wrote: What is ctype.h good for? A good question. Its only use seems to be in ghc/rts/RtsFlags.c where it is used for functions like isdigit and isspace for decoding the RTS flags. Maybe it should be retired altogether. I'm rather puzzled how this works if ctype.h isn't there at all, as it seems to. The functions are C89, so they should be present *somewhere* in libc anywhere. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME Neu! Ändern Sie den Anfangstag Ihrer Woche ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow Haskell on different versions of Linux
Volker Stolz wrote: What is ctype.h good for? A good question. Its only use seems to be in ghc/rts/RtsFlags.c where it is used for functions like isdigit and isspace for decoding the RTS flags. Maybe it should be retired altogether. I'm rather puzzled how this works if ctype.h isn't there at all, as it seems to. The functions are C89, so they should be present *somewhere* in libc anywhere. Actually, in GNU libc, isspace, isdigit etc are usually macros which read a flag word from the __ctype_b array then and it with the corresponding attribute mask. extern __const unsigned short int *__ctype_b; /* Characteristics. */ ... #define __isctype(c, type) \ (__ctype_b[(int) (c)] (unsigned short int) type) ... # define isdigit(c) __isctype((c), _ISdigit) ... # define isspace(c) __isctype((c), _ISspace) However, glibc does export functions with those names, and you can disable the macros by defining the __NO_CTYPE macro, with the result that the binary depends upon isspace, isdigit etc rather than __ctype_b. I don't have glibc 2.3 here, but presumably __ctype_b has changed in an incompatible manner (maybe there are more than 16 flags in 2.3, in which case an unsigned short would no longer be sufficient). -- Glynn Clements [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow Haskell on different versions of Linux
Volker Stolz wrote (snipped): The functions are C89, so they should be present *somewhere* in libc anywhere. Yes, you're right. Normally isspace and friends are used as macros, but ANSI C requires them to be also available as functions so they must be exported that way. Therefore if you don't import ctype.h, what happens is that (isspace) is implicitly assumed to be a function of type Int - Int, which (in this case) happens to work. The reason for the incompatibility is (see comments in ctype.h) something to do with locales now being thread specific. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow Haskell on different versions of Linux
I wrote: since version 6.2 we have 2 binary distributions for (generic) linux: for glibc 2.2 and glibc 2.3 Maybe this is no longer necessary. I've produced an installation (under glibc 2.2) that runs under glibc 2.2 and glibc 2.3. I've now also successfully installed ghc-6.2.1 from source under glibc 2.3 that works under glibc 2.2, too. As also Volker Stolz suggested I've changed, after calling ./configure, a line in mk/config.h from #define HAVE_CTYPE_H 1 to /* #undef HAVE_CTYPE_H */ I'll try the same trick under glibc 2.3 later. Yes, that basically did it. Thus the glibc 2.3 version (without ctype.h) should be sufficient as binary distribution in the future. Christian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Glasgow Haskell on different versions of Linux
Dear Haskellers, since version 6.2 we have 2 binary distributions for (generic) linux: for glibc 2.2 and glibc 2.3 Unfortunately our network has machines with both of this glibc versions. The problem seems to be related with the inclusion of ctype.h. Is it possible to produce a GHC binary for glibc 2.3 that does not depend on ctype.h? I think such a binary (produced under glibc 2.3) would be executable also under linux with glibc 2.2 Currently ctype.h triggers the error under glibc 2.2 (if the glibc 2.3 binarias are used): /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by lib/i386-unknown-linux/ghc-6.2.1) and prevents linking under glibc 2.3 (if the glibc 2.2 release is used) Cheers Christian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow Haskell on different versions of Linux
2004-06-08T14:17:22 Christian Maeder: since version 6.2 we have 2 binary distributions for (generic) linux: for glibc 2.2 and glibc 2.3 If it were possible to construct and ship a statically-linked ghc, that might be ideal; it should be portable across a wide range of Linuxes, regardless of what libc they have installed. Would even work on my Linux, which has no glibc at all, only uClibc (and so far I've been unsuccessful in my attempts to boostrap ghc in, boo-hoo). -Bennett pgpFGZqWmds5N.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow Haskell on different versions of Linux
Christian Maeder wrote: since version 6.2 we have 2 binary distributions for (generic) linux: for glibc 2.2 and glibc 2.3 Maybe this is no longer necessary. I've produced an installation (under glibc 2.2) that runs under glibc 2.2 and glibc 2.3. As also Volker Stolz suggested I've changed, after calling ./configure, a line in mk/config.h from #define HAVE_CTYPE_H 1 to /* #undef HAVE_CTYPE_H */ I'll try the same trick under glibc 2.3 later. Christian P.S. What is ctype.h good for? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow Haskell on different versions of Linux
Christian Maeder wrote: What is ctype.h good for? A good question. Its only use seems to be in ghc/rts/RtsFlags.c where it is used for functions like isdigit and isspace for decoding the RTS flags. Maybe it should be retired altogether. I'm rather puzzled how this works if ctype.h isn't there at all, as it seems to. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
