Re: mingw32 build feedback

Rudy Taraschi <[email protected]> wrote:
> Here's some feedback on building pre0.9.9-43 on MinGW using the latest
> slang.  Native compile using the .g32 makefile:
>
> - make clean rule had an "-rf *o" which I deleted
> - the chkslang line was disabled by an "echo", which I removed
> - the SLRN_CONF_DIR has an slrn (not slrnpull) tag, but it's not used
> in building slrn.exe
> - building slrnpull fails because it needs the SLRN_CONF_DIR flag.
> Question: Will SLRN_CONF_DIR accept "."  or "" to maintain prevous
> behaviour?

It may--- I have to review how it is currently used.

> Personal note: while it was obvious that I needed to tell the Makefile
> where slang was located, why not leave the "two up" path as in all
> previous releases so that slrn can build without tweaking the
> Makefile?

I am not too familiar with how dynamic linking works under windows.  I
had the impression that dlls had to be on the executable path.  Also,
slrn will eventually require an actual installed version of slang once
the interpreter has been better integrated.

> Snag: while everything seems to run fine using an slrnpull spool, this
> new version of slrn on Windows does not want to load Emmanuele Bassi's
> latest identity.sl macro, but has no problem on Slackware.  It fails
> in the first register_hook near the end of the file.  If I remove the
> "1==", everything loads fine.  Other macros with similar register_hook
> calls have no problem, only this one.  slrn does not spit out a
> meaningful error message to narrow down the error, but if you send me
> a patch with some debugging printfs or othe suggestions to get an
> error message, I'll be happy to help you solve the problem since it
> seems to not happen on linux.

Look at my previous post.  There I suggested putting something like

   open_log_file ("slang.log); _traceback = 1;

at the top of the suspect file (identity.sl in this case).

> Lastly, I'm happy to report that the intermittent crash I had with the
> pl2 and pl2.1 informal releases is gone with pre0.9.9-43.  I had
> narrowed it down to a stack problem in mime.c (pointer corruption
> followed by a free), but there seem to have been lots of code changes
> in there, which look like they fixed the problem.

That's good to hear.
Thanks for the feedback,
--John

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/