I installed AMD64 Ubuntu 16.04 LTS on another computer so that I could play. But it turns out that the same problem is in Fedora 24 so I needn't have bothered. Aside: I learned that the best description of my Canadian Bilingual Keyboard is under French(Canada) ; English-something-or-other. I'm still playing with this, but here are my preliminary observations. So here's the fundamental problem. "exp" is kind of like a reserved word in C. It is the exponential function and is declared in math.h. logo.h has #define exp expresn This screws up math.h. [language lawyer mode] The C standard as of N1548 (draft from 2010 December 2) says: 7.1.2 Reserved identifiers ... - All identifiers with external linkage in any of the following subclauses (including the future library directions) and errno are always reserved for use as identifiers with external linkage. 184) ... A following subclause includes a definition of exp. As I understand it, as an identifier with external linkage. As I read that, logo.h is NOT impinging since it is using exp as a macro name, something that gets "washed out" by the preprocessor, long before external linkages are understood. But the definition of exp affects the tricky code in /usr/include/x86_64-linux-gnu/bits/mathcalls.h __MATHCALL_VEC (exp,, (_Mdouble_ __x)); => __MATHCALL_VEC (expresn,, (_Mdouble_ __x)); which then malfunctions. Math.h: /* The file <bits/mathcalls.h> contains the prototypes for all the actual math functions. These macros are used for those prototypes, so we can easily declare each function as both `name' and `__name', and can declare the float versions `namef' and `__namef'. */ #define __SIMD_DECL(function) __CONCAT (__DECL_SIMD_, function) #define __MATHCALL_VEC(function, suffix, args) \ __SIMD_DECL (__MATH_PRECNAME (function, suffix)) \ __MATHCALL (function, suffix, args) and so on. I *think* that this is a bug in glibc (i.e. a "contract violation" of the C Standard), but I'm not 100% sure. Why does ucblogo have this definition? Here's my guess. UCB Logo uses a global variable with the name "exp" pervasively. Then it turned out that this was the (external linkage) name of the exp function. So there was a clash, even though the exp function isn't used by ucblogo. The #define was a simple way of renaming the global variable's external name without editing the source code. An effective hack. Fix? Several, but untested. 1. Brutish of brute force: Replace every #include <math.h> with #undef exp #include <math.h> #define exp expresn 2. Better fix: fix glibc to not take names that don't belong to it. 3. Blame the victim fix: in UCB Logo, replace every "exp" with "expresn" (or some other apt short name). 4. Simpler UCB Logo fix: Move the <> includes before the "" includes. Generally considered good style anyway. There is a chance that logo.h includes things that intentionally modify system headers. In that case, this fix will break these modifications.

| From: Stewart C. Russell via talk <talk@gtalug.org> | So what we have here is a kind of | internal bitrot: the code doesn't change, but the standards of the | language do, so it won't build. Perhaps not in this case. exp(3) has always been in <math.h>. But if a simple declaration in that header looked like this: double exp(); and it got attacked by the logo.h #define to turn it into double expresn(); the resulting error message ought to be a lot clearer. I don't know why there would not have been an error (a clash with the programs's external variable exp / expresn). But glibc started doing odd preprocessor tricks (token pasting I think, but I didn't look closely) and then weird things happen. So the actual behaviour rotted whereas the language status didn't change. I think. | Thank you. I'll definitely try the simpler ones. Don't think the glibc | ones are within my grasp. It turns out that there are other compiler error messages that I haven't sorted through. But since 6.0 is in Fedora, you might have a look at what the source RPM does to patch them up. (Fedora RPMs include an unchanged upstream tar.gz and a bunch of patches and a recipe for building the package. Even if it doesn't directly apply to Ubuntu/debian, it should be quite helpful.) | You'd previously asked why I wasn't using the distro-supplied versions. | True enough: Ubuntu has a packaged UCB Logo 5.5 archive that installs | and runs easily enough. Unfortunately, it's not fit for my purposes. That's sad. 6.0 seems to date back to 2008. Maybe you could package 6.0 for debian or Ubuntu if you figure this out. | Yeah, I should probably do this using Python's turtle module, as it | makes some nice output and is actually maintained. Logo, however, | encourages a much more interactive development style. I have a soft spot for Logo. I've described some of my experience with it on this list. | cs pd repeat 10 [ | rt 54 fd 43.865 | lt 90 fd 45.002 | lt 108 fd 45.002 | lt 90 fd 43.865 | lt 90 | ] pu ht Nice. Reminds me of some things that we came up with when my kids and I were playing with logo. (We were using Atari 8-bit Logo, a product of LCSI, a company with which Seymour Papert was involved.) I had no trouble running it using Fedora's package. Some of those lengths look a bit, uhh, empirical. It's more fun if you don't start with cs and end with ht. Then you can iterate and get interesting effects. cs repeat 6 [load "stewarts-pattern.logo2 fd 30] cs repeat 2 [load "stewarts-pattern.logo2 fd 45.002] cs repeat 3 [load "stewarts-pattern.logo2 rt 10]