Re: [code] Troubles compiling and running TextAdept under Debian

From: Mitchell <>
Date: Fri, 30 Nov 2012 23:33:35 -0500 (EST)

Hi Rob,

On Fri, 30 Nov 2012, Rob Kendrick wrote:

> On Thu, Nov 29, 2012 at 09:57:33PM -0500, Mitchell wrote:
>> LuaJIT does not seem to be building. A couple guys at the Lua
>> conference figured out that it was because "uname -i" doesn't return
>> the proper value on Debian.
> (Oops; misconfigured mail client used wrong From: header on previous
> attempt.)
> Previously, I have been able to build stock LuaJIT fine on this system;
> is this some extra layer that's been put in TextAdept's build system?
> What happens if I try to build it on a system that isn't supported by
> LuaJIT?

I don't know, but maybe something similar. Textadept is supported on i386
and x86_64 so it should ultimately build on those arches without fail.

> Incidentally, I'm not sure what the "proper" value for -i should be;
> it's not defined by POSIX2001 (only mnrsv are), an -m is defined as:
> "Write the name of the hardware type on which the system is
> running to standard output."
> (Line 36395, IEEE 1003.1, POSIX, Shell and Utilities, issue 6.)
> The standard is also pretty vague about what "hardware type" might mean.

Thanks for spending more time looking into that. I did my own research
and, again with help from attendees at the Lua conference, committed a
change to detect flags from gcc rather than relying on 'uname'.

>>> Unfortunately, that produces the following error (in a GTK window):
>>> "cannot open /home/rjek/bzr/textadapt/textadept 2
>>> keyboard<0015>TPPS/core/init.lua: No such file or directory"
>>> Where <0015> is the glyph for the unprintable Unicode point.
>>> It then quits.
>> I cannot reproduce this. I moved textadept to a new directory with a
>> <0015> unicode point and tried to run it and didn't get an error.
>> $> mv textadept `echo -ne "ta\x15"`
>> $> cd ta<tab>
>> $> ./textadept # runs with no errors
>> What is the output from "echo $LANG"?
> I was running it from /home/rjek/bzr/textadapt/ (yeah, I know, a typo);
> there was no fruity characters in the path.
> rjek.att.humdrum:~$ echo $LANG
> en_GB.UTF-8

I'm not sure why it would fail then. The error message you specified I
think is emitted from luaL_dofile. The path passed to it is composed of
`/proc/self/exe` and "core/init.lua", so unless `/proc/self/exe` is
inaccurate, I cannot imagine why it would fail.


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Fri 30 Nov 2012 - 23:33:35 EST

This archive was generated by hypermail 2.2.0 : Sat 01 Dec 2012 - 06:27:12 EST