bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ZILE 2.3.9 (weak but successful attempt at DJGPP 2.04 compile)


From: Rugxulo
Subject: Re: ZILE 2.3.9 (weak but successful attempt at DJGPP 2.04 compile)
Date: Fri, 10 Jul 2009 11:31:18 -0500

Hi,

On Fri, Jul 10, 2009 at 5:52 AM, Reuben Thomas<address@hidden> wrote:
>
>> I haven't tested too hard, but it seems C-x C-v
>> (find-alternate-file) is still buggy, seems to either very slightly
>> corrupt the on-screen display and/or crash.
>
> Can you be more precise? I can't make it crash, and the only bug I can
> see is that if I use it from the *scratch* buffer, then it fails to
> append a slash to the end of the path. I certainly don't see any
> screen corruption. (I'll fix that, anyway.)

The screen corruption doesn't always happen, only rarely. It just
doesn't work at all. I guess I really should optionally e-mail you an
.EXE to see for yourself. (A very minimal FreeDOS boot disk image
would be extremely small, and I can make one fairly quickly if you
need it.)

E.g., I just tried it again, and (under Vista at least) it just seems
to immediately and silently exit the program. I should probably test
in real DOS, but I expect similar issues.

>> Well, 2.3.9 was just released. ZILE seems updated often these days.
>
> I try to fix bugs!

Well, in case you didn't notice, I first mentioned 2.3.7, only by
chance stumbled across 2.3.9, I didn't expect such a fast update!  ;-)

>> echo (needs -std=c99 so use a recent GCC, e.g. 3.2.3, preferably newer)
>
> This shouldn't be true. If you find you need -std=c99, please tell me
> where. Zile and gnulib are both written to need only C90.

I swear it's using -std=c99 out of the box for me, don't ask me why.
Maybe a configure thing, who knows.

EDIT: "-std=gnu99" actually!!

>> sed -i -e "/-lcurses/s//-lpdcurses/" -e "/mp_cv_curses=no/s/=no/=yes/"
>
> I'm quite happy to support pdcurses. I see there's a version for X11,
> so I'll download it and get it working myself.

Cool. BTW, there is actually a recent port of Ncurses to DOS, but I
haven't really tested it. I guess I chose the hard way by using
PDcurses, but in my mind, PD should be just as good. I do find it odd
that copying libpdcurses.a to libcurses.a didn't work. I suspect the
curses test is flawed, but who knows, it could be my setup.

>> sed -i "\,libgen\.h,s,^,//," src\completion.c
>> sed -i "\,SIGTSTP,s,^,//," src\funcs.c
>> sed -i "\,SIGBUS,s,^,//," src\main.c
>
> I don't see that I can do much about these, as these are all
> POSIX-specified. (My use of libgen.h isn't erroneous, it's just a
> result of my insisting on POSIX. autoconf is happy to run on non-POSIX
> systems; I am trying to write to standards rather than be portable to
> specific systems.)

But ./configure mentions checking for libgen, and it reports "no", and
yet it still tries to use it. I find that odd.

As for the unsupported signals (well, that DJGPP doesn't or can't
implement) you could #define around 'em with DJGPP / __DJGPP__ or
MSDOS / __MSDOS__. Or is that what you mean when you say you want to
avoid specific hacks?

>> 2). I believe the '\\\\r' is wrong and is turning out as literally
>> "\r" instead of '\r' (CR byte). This affects the Gawk script used by
>> config.status that creates the various Makefiles. If this isn't
>> changed, it won't create them.
>
> If you're right about this, it's a bug in autoconf, which you should
> report. The address@hidden people are friendly!

Well, without this "fix" it doesn't create the files, aborts with an
error. Hence you can't compile as-is. I'll cc them this e-mail (hope
they don't mind the noise, I don't know the proper way).

> Thanks very much for this. As I implied above, I'm not going to fix
> Zile specifically for DJGPP; I think that in the long run that sort of
> portability doesn't help anyone as it means that non-portable systems
> don't get fixed and program maintainers end up writing duplicate buggy
> workarounds. Hence, the issue with libgen.h, the signals and __rdtsc
> should be fixed in DJGPP (even if just as stubs to let the code
> compile).

Very unlikely, DJGPP development has mostly stalled. Sad but true.
:-/   Lack of manpower, I think. It's kinda disappointing, and FreeDOS
(slow but active) is similar. They're still updated though (e.g.
recent bugfix 2038 "stable"), but volunteers are few (and always
terminally busy with "real life").

BTW, the rdtsc thing is very strange. It doesn't happen with my main
DJGPP setup, but when trying to make a minimal DJGPP install (e.g. to
determine what packages are needed to compile) I noticed it. And it's
2.04 specific (since 2.03p2 doesn't include rdtsc in time.h). I don't
actually know why it's doing that, no library functions (that I know
of) use rdtsc, and it's not in the code anywhere, so that's kind of a
mystery to me.   :-/

However, on the bright side, this might? be a good time for me to try
to make a DJGPP package set (my first!) for ZILE, e.g. ZILE239[BS].ZIP
for both /current/ and /beta/ (as normal DJGPP packages are typically
made). Such a thing normally has DJGPP-specific patches included. So
even if you don't include full support for DJGPP, at least it would
exist somewhere.

I actually have also been testing out the latest pretest releases of
GNU Emacs 23.1 (e.g. 23.0.95) for Eli Z., who recently started
maintaining it again for DJGPP. But that won't fit on a floppy (not
even close)!    ;-)

> If you can answer my questions I'll make the fixes I can at my end and
> send you a 2.3.10-pre tarball to test, if that's OK.

I'll help if I can. I still want to look at it some more, e.g. check
more in-depth for dependencies, try older "stable" 2.03p2, etc.

P.S. Also seems that "M-x shell-command" doesn't work (and also very
slightly messes up the screen), but that kind of thing is typically
very hairy. I weakly tried, but I honestly don't even know where in
the sources to look for that. (Hmmm, found a stray "&1" file.)

P.P.S. Is there no way to kill from point to the beginning of a line?
GNU Emacs seems to do so with M-0 C-k (meta zero ctrl 'k'). Consider
that a feature request!   ;-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]