Building luatex on i386-darwin
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). 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 Darwin; and even though it should be easy to fix for any person wanting to build luatex on such a machine (in my case I simply installed the GNU coreutils), I think it's advisable to replace it with an equivalent (the manpage for GNU cp mentions -a is simply a shorthand for -dpR, but then -d isn't recognized by Darwin's cp either so I don't know what to recommand). The two occurrences are found in src/texk/web2c/luatexdir/luatexlib.mk, lines 127 and 137, respectively. I don't think it is necessary to send a patch for such a small change; it's only a matter of replacing the offending switch with an appropriate set of options in two places. 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 of linkers and of binary formats, so I decided to simply drop that option (which is only used in the very last phase, when linking luatex together), and it worked... but when it will come to distribute luatex you may well want to find a real solution. This option is used in src/texk/web2c/luatexdir/luatex.mk, at line 32 as I speak. 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. 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. Yours, Arthur
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
Taco Hoekwater wrote:
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?
what is autoloading? i'd say: just make static binaries and remove those runtime lib dependencies
Great! We should set up a test file (yet another todo)
\directlua0{tex.sprint("Hello World!")} ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hans Hagen wrote:
Taco Hoekwater wrote:
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?
what is autoloading?
runtime loading of .so and .dll lua extensions Taco
Taco Hoekwater wrote:
Hans Hagen wrote:
Taco Hoekwater wrote:
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?
what is autoloading?
runtime loading of .so and .dll lua extensions
i hate that since for users there are many ways to screw that up Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
i hate that since for users there are many ways to screw that up
I concurr. And I think dynamic linking has never been the trend in the TeX world anyway (apart from XeTeX, which is yet another story); for example I have never seen a libkpathsea.so, but only static libraries which are sometimes installed in $SELFAUTOPARENT/lib or so (but never used, I guess). Even for things like ttf2tfm which are closely related to freetype or to some other "big" library, the binaries seem to be statically linked. Arthur
Arthur Reutenauer wrote:
i hate that since for users there are many ways to screw that up
I concurr. And I think dynamic linking has never been the trend in the TeX world anyway (apart from XeTeX, which is yet another story); for example I have never seen a libkpathsea.so, but only static libraries which are sometimes installed in $SELFAUTOPARENT/lib or so (but never used, I guess). Even for things like ttf2tfm which are closely related to freetype or to some other "big" library, the binaries seem to be statically linked.
FYI: This bit of code in luatex is not about actually linking a library dynamically vs. statically, but loading the whole library runtime, like perl and ruby do with some of the larger extensions (e.g. Tk.so) Since we all seem to dislike the idea, I'll remove support for that soon. Greetings, Taco
Arthur Reutenauer wrote:
\directlua0{tex.sprint("Hello World!")}
That was some test file ;-) It works as expected (I mean, it prints Hello World! on the page).
whow, so what do you expect from this: \directlua0{tex.sprint(string.reverse("Hello World!"))} or even: \beginR\directlua0{tex.sprint(string.reverse("Hello World!"))}\endR Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
(Sorry about the two emails sent mistakenly from my address @ens.fr, Taco. I'm still in the process of migrating between two servers).
whow, so what do you expect from this:
You mean, without cheating? I can try and guess.
\directlua0{tex.sprint(string.reverse("Hello World!"))}
I supposed the string is reversed by Lua, and then handed over to TeX to print, so you see it printed backward.
\beginR\directlua0{tex.sprint(string.reverse("Hello World!"))}\endR
Here the string will probably be reversed by Lua as above, and then reversed again by the e-TeX primitive, so you will see it in the right order, though I don't know what happens with the more refined metrics like kerning or ligatures when using \beginR; I guess the ligatures would be broken in a word like "difficult", because LuaTeX would see "tluciffid"... OK, that's a bad example. But unless \beginR does some fine-tuning, I expect the ligature to be broken. Arthur
Arthur Reutenauer wrote:
(Sorry about the two emails sent mistakenly from my address @ens.fr, Taco. I'm still in the process of migrating between two servers).
whow, so what do you expect from this:
You mean, without cheating? I can try and guess.
\directlua0{tex.sprint(string.reverse("Hello World!"))}
I supposed the string is reversed by Lua, and then handed over to TeX to print, so you see it printed backward.
\beginR\directlua0{tex.sprint(string.reverse("Hello World!"))}\endR
Here the string will probably be reversed by Lua as above, and then reversed again by the e-TeX primitive, so you will see it in the right order, though I don't know what happens with the more refined metrics like kerning or ligatures when using \beginR; I guess the ligatures would be broken in a word like "difficult", because LuaTeX would see "tluciffid"... OK, that's a bad example. But unless \beginR does some fine-tuning, I expect the ligature to be broken.
10 points out of 10 i hadn't thought of that; in principle rl typesetting using the etex way is (but taco must correct me if i'm wrong) mostly a reverse flushing to the dvi file, well, i must try it anyhow, you can play a bit with such things in order to get a feeling of lua; the nice things is that it's fully expandable, one can even use nested lua calls Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (4)
-
Arthur Reutenauer -
Arthur Reutenauer -
Hans Hagen -
Taco Hoekwater