X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Juan Manuel Guerrero Newsgroups: comp.os.msdos.djgpp Subject: Re: ANNOUNCE: DJGPP port of Lua 5.2.0 uploaded. Date: Thu, 22 Dec 2011 07:56:35 -0800 (PST) Organization: http://groups.google.com Lines: 137 Message-ID: <3e0771bb-ed2b-4dfc-a654-75b59a3c65a7@p9g2000vbb.googlegroups.com> References: <201112220014 DOT pBM0ENQt004616 AT delorie DOT com> <74ee1ae2-8a21-4104-95d9-492073150519 AT l29g2000yqf DOT googlegroups DOT com> NNTP-Posting-Host: 46.5.198.95 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1324569500 19912 127.0.0.1 (22 Dec 2011 15:58:20 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: Thu, 22 Dec 2011 15:58:20 +0000 (UTC) Complaints-To: groups-abuse AT google DOT com Injection-Info: p9g2000vbb.googlegroups.com; posting-host=46.5.198.95; posting-account=OsAajgoAAADdKJnkJkmhzqP0jo6I_P_0 User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HUALESNKRC X-HTTP-UserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0,gzip(gfe) Bytes: 6760 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On 22 Dez., 05:06, Rugxulo wrote: > I'm not sure I've ever rebuilt DJGPP's libc, probably weakly tried > once or twice and gave up. Nowadays, I have more experience, so I > should try again. But I'm blindly assuming pure DOS won't work > (easily, if at all), unfortunately. I have compiled libc on plain DOS without difficulties today. I have used VMware with this system parameters: OS: MSDOS 6.22 (no LFN driver installed) RAM: 32 MB Smartdrv cache: 10 MB No RAM disk. I checked out the sources on my linux box and zipped the extracted sources. I used djtar to extract the sources on the virtual dos box. The sources compiled flawlessly. It took around 50 minutes to compile the sources using gcc 4.6.1 and latest binutils. Of course, a working version of lua can also be compiled after libc.a has been installed. Using the checked out sources of libc has alot of benefits. - the library has the 0x71NN call fixed versions of the file functions that use this call. - it has the improved printf version that provides the A specifier. - it has the improved strto[dfld] versions that provides support for conversion of the hex format strings. The last ones used to be provided by libsupp. > > Please also note that you do not need to worry about all this if you use > > gcc 4.4.5 or a previous version to compile the sources. > > I know what you meant, but obviously we don't have 4.4.5 (only 4.4.4), > and even 4.4.6 (or maybe by then 4.4.7) will probably be dropped once > .4.7.x is out in a few months. I don't honestly know which version I > trust the most as they all seem to have regressions. Well I have 4.4.5 ;-) I think I must have downloaded it from Andris' homepage some time ago and then assumed that it was from ftp.delorie.com without double checking this assumption. OFYI, the 4.5.X versions also work. But the 4.6.X versions certainly do not. > > DJGPP specific changes. > > ======================= > > > > - The port will honor the new platform "djgpp". This means, to compile the > > port you must pass djgpp as argument to the Makefile in the top srcdir. > > FYI, last I checked, Lua would compile via (in order of preference) > posix, generic, or ansi. But they do have some hardcoded targets too > ( "bsd"), so it's fine. ;-) With posix, generic and ansi the lua source can be compiled with DJGPP. This is because a lot of effort has been done in DJGPP to provide certain amount of posix functions. I do not know if it would be possible to compile the posix version using openwatcom or other dos compilers. Anyway if you compile the posix version a posix system is assumed and _not_ only a posix compiler. Selecting posix means that your system is XSI compatible. The binaries produced with DJGPP would probably not really work. E.g.: for a posix version it is hardcoded that the temporary directory is /tmp. This is certainly not true for dos/windows systems. The consequence is that every lua program that tries to create a temporary file will fail. In other words, almost all lua programs that do interact with the OS and the underlying file system will probably fail. > BTW, am I wrong or does it ("posix") try using (POSIX?) _setjmp [sic]? > Is that somehow different than default ANSI C setjmp? EDIT: Hmmmm, > sounds complicated: Lua offers 3 ways to handle exceptions. By default, Lua handles errors with exceptions when compiling as C++ code (this means __cplusplus is defined), with _longjmp/_setjmp when asked to use them (this means LUA_USE_POSIX is defined. This is the case for linux, bsd, freebsd, aix, solaris,macos and posix), and with longjmp/setjmp otherwise (ansi, generic). There are also a lot of other things that must be adjusted very carefully when compiling Lua. Lua makes assumptions about where libraries and files will be found when lua runs a program. All these paths are hardcoded and assume a posix file system. E.g.: compiled lua files will be searched in /usr/local/share/lua/N.N and C libraries needed at runtime will be searched in /usr/local/lib/lua/N.N The only exception to this is when _WIN32 is defined during compilation. Also if _WIN32 is defined then backslash will be used as directory separator in any other case slash will be used. In conclusion: building a *working* lua interpreter is not trivial. You can compile the lua binaries out-of-the-box for aix, bsd, freebsd, linux, solaris and macos. If you know that your system is POSIX but no one of the above you are alone but you can try posix. The only not POSIX platform supported by Lua is Windows using MinGW. I assume that it may be possible to compile a working lua interpreter for Windows using cygwin but I have never tried. For any other OS you are *completely* alone. Here the best is to choose ansi. This will guarantee that only ansi functions will be used and no POSIX functionality is assumed; especially no dlopen/dlclose is assumed to be available. In this case no DLL loading by a lua program will be possible. Neitherless still certain posix assumptions will be done like slash as directory separator and the hardcoded library paths, etc. Of course, hardcoded library paths can later be changed by setting environment variables. Again, a flawless compilation of the sources does not imply that the produced binaries will ever work for the target OS. Regards Juan M. Guerrero