Mail Archives: djgpp/2011/12/23/03:15:20
Hi,
On Dec 22, 9:56 am, Juan Manuel Guerrero <juan DOT guerr DOT DOT DOT AT gmx DOT de> wrote:
> 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.
>
> 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
>
> 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.
I'm surprised it works without LFNs and in such a low amount of RAM.
And BTW, I've never tested VMware, usually prefer others, but one
FreeDOS guy did write this recently (to share files between host and
guest), if it could help you somehow:
http://www.sf.net/projects/vmsmount
> Using the checked out sources of libc has alot of benefits.
I still never finalized that lame-o patch that separated
filetimestamp() into its own file (to save space). Nobody else seemed
to care anyways, esp. since it wasn't crucial, so I forgot about it.
> > > 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)
>
> 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.
Right, now I see it's on his page but not DJ's ftp. Presumably it
wasn't considered important once 4.5.x and 4.6.x were ported.
> OFYI, the 4.5.X versions also work. But the 4.6.X versions certainly
> do not.
I think I weakly tried 4.5.x a while back, and it didn't work. FYI,
the only time I've ever played with DXE was with my weak patch to
paq8f (although I have a better non-DXE patch using CPUID elsewhere):
https://sites.google.com/site/rugxulo/paq8fdxe.zip?attredirects=0
> > FYI, last I checked, Lua would compile via (in order of preference)
> > posix, generic, or ansi.
>
> 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.
POSIX is just too big, though, so even DJGPP doesn't support
everything, esp. not 2008. I don't miss it, honestly, but people don't
write for older standards. :-(
> I do not know if it would be possible to
> compile the posix version using openwatcom or other dos compilers.
Almost definitely not at all with OpenWatcom without major library
additions. It's more or less ANSI C only. Now, maybe EMX or MOSS, but
even those I kinda doubt. Anyways, it's moot, I prefer DJGPP unless I
have a good reason. :-)
> 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.
@echo off
REM voila! :-)
mkdir \tmp
> 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.
I dunno, I checked, and it uses "lua_XXXXXX" or some such. Wouldn't
that be sufficient for "reasonable" use under DOS? Doesn't real DOS
truncate the names anyways?
> > 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).
Do those act differently? (shrug) Dunno.
> 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.
_WIN32 is surprisingly only in two files (and four instances total),
so it's not that bad, thankfully. Hmmm, one of those defines LUA_WIN,
which is used in three files (six instances). Hmmm, and a few other
defines further, slightly confusing, heh.
> Also if _WIN32 is defined then backslash will
> be used as directory separator in any other case slash will be used.
Well, both slashes work in DJGPP, no? But yeah, I see your point.
> 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.
All of those are basically POSIX. So they basically only target POSIX.
Though I thought I read that they explicitly wanted to avoid *nixisms
to cater to more of the wider variety of machines at their university.
I guess that's why it's still compatible with ANSI.
> The only not POSIX platform supported by Lua is Windows using MinGW.
Not too surprisingly.
> I assume that it may be possible to compile a working lua interpreter
> for
> Windows using cygwin but I have never tried.
Presumably, yes, since Cygwin is POSIX-friendly.
> 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.
OpenWatcom + Causeway could allegedly work for .DLLs, but again, OW
has very little POSIX support.
> 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.
Checking env. vars is good. Still, I kinda hate it when software is
either POSIX or Win32 only (e.g. p7zip, CM3) as it always turns into
one big kludge. The irony is that DJGPP is somewhere in the middle.
> Again, a flawless compilation of the sources does not imply that the
> produced
> binaries will ever work for the target OS.
I know, it's not that easy, but obviously the hardest part is getting
started, getting an actual .EXE to debug. Then the next hardest part
is making it work! ;-)
P.S. News:
http://www.freedos.org/
http://sourceforge.net/news/?group_id=5109&id=305286
- Raw text -