Hi Arthur, Arthur Reutenauer wrote:
Hello luatex team,
I'm sure you will be delighted to know that luatex compiles fine on Intel-based Macs (MacBook with Intel Core Duo processor running MacOS 10.4 Tiger), but for two culprits (I used the latest SVN trunk, version 159 committed this afternoon; with the snapshot from late October there was one more error).
Great news, thanks for posting!
The first one is really ridiculous: there are two places where a Makefile uses the '-a' switch to cp, which appears not to be legal on
That's just laziness on my part. The subsytems in question have subdirectories, so I have to write down the mkdir and cp * commands explicitly. Not a big problem at all, and very simple to fix.
The other one is more worrying; it's also a portability issue, this time in the linking phase: apparently the native linker doesn't know about the -E switch (which for GNU ld is an equivalent for --export-dynamic, so it has nothing to do with gcc's -E). I know nothing
This is for the -ldl that is is in $(luatexlibsldextra), and was added to allow dynamic linking of compiled code (esp. luazip). Since luazip is already in the binary now and this is a potential security & portability nightmare also, it may be safer to remove the autoloading completely. Hans, Hartmut, everybody, WDYT?
Finally, at the same moment, the linker complained about multiple definitions of the symbol _scandir (in /usr/lib/libm.dylib --that is the system's libm-- and luatex0.o), but again, I decided not to bother.
I should rename that function or add it to the 'zprefixed' ones (the scandir in luatex0.c is the 'scan a direction specifier' from Aleph).
Anyway, the binary worked as expected, as far as I could tell: it was able to produce a plain format (I didn't try with latex.ltx); it could output PDF or DVI as desired; and the new primitives were there, although in this latter case I wasn't sure about what to test.
Great! We should set up a test file (yet another todo) Greetings, Taco