Xref:	news2.mv.net comp.os.msdos.djgpp:1721
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Bug in DJGPP under Windows 95 with workaround
Date:	Wed, 6 Mar 1996 13:50:12 +0200
Organization:	NetVision LTD.
Lines:	43
Message-ID:	<Pine.SUN.3.91.960306132740.25914C-100000@is>
References:	<9603041806 DOT AA22554 AT is DOT elta DOT co DOT il>
NNTP-Posting-Host:	is.elta.co.il
Mime-Version:	1.0
In-Reply-To:	<9603041806.AA22554@is.elta.co.il>
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

On Mon, 4 Mar 1996 alexlehm AT rbg DOT informatik DOT th-darmstadt DOT de wrote:

> : Until this bug is corrected, to work around it, you will need to set LFN=n
> : from your autoexec.bat or from the DOS command line.
> 
> Really? I just tried to build libtiff with djgpp and I had to set LFN=y
> explicitly (since I unpacked the files with WinZip 6.0), so I'm pretty sure
> the LFN=n is honored. At least in make, maybe gcc doesn't (make complained

Not necessarily.

Short explanation: the effect depends on the command-line arguments passed
to a program, on whether you set LFN=n or LFN=y, and on whether you need
LFN in a program called from DOS command line or from another DJGPP
program (like gcc invoked by Make). 

Ready for a long explanation?  Here goes: the function which finds out
whether LFN should be supported (`_use_lfn') isn't called directly by the
start-up code; instead, various file-related library functions call it. 
`_use_lfn' actually remembers the LFN support flag from the first time it
was called and for successive calls just returns that cached result
without checking.  Functions that call `_use_lfn' are findfirst/findnext,
stat and _open (there are others, but they are probably irrelevant to our
case).  If your command-line arguments include wildcards, then findfirst
and findnext will call `_use_lfn' first; if not, it will be called when
the start-up code opens the DJGPP.ENV file.  In both cases, this is done
*before* the LFN setting on DJGPP.ENV is seen; so, unless neither the
program has set _CRT0_FLAG_NO_LFN flag in _crt0_startup_flags nor LFN is
set from DOS command line, `_use_lfn' will under Win95 *always* default to
LFN=y, because it just calls an appropriate DOS function to see if LFN is 
supported by the OS. 

However, child programs spawned by a DJGPP parent will have LFN=n (or
LFN=y, whichever the case might be) in the environment *before* they start
(this is done by spawnXX/system library functions, so that the child will
inherit the environment of the parent), which overrides the behavior
described above.

Additionally, you might see other kinds of bugs if you use one of the 
beta releases of the library or programs linked against beta versions of 
the library, because the code for `_use_lfn' changed in the latest 
versions.

- Raw text -