Mail Archives: djgpp/2011/12/22/11:15:29
On 22 Dez., 05:06, Rugxulo <rugx DOT DOT DOT AT gmail DOT com> 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
- Raw text -