Xref: news2.mv.net comp.os.msdos.djgpp:1721 From: Eli Zaretskii 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: References: <9603041806 DOT AA22554 AT is DOT elta DOT co DOT il> NNTP-Posting-Host: is.elta.co.il Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.