Mail Archives: djgpp-workers/2001/08/26/07:14:39
On Sat, 25 Aug 2001, Charles Sandmann wrote:
> > > I changed d:\djgpp\bin in specs to c:\djgpp\bin and I can now compile with
> > > lfn=n ...
> >
> > What specs did you mean here?
>
> \djgpp\lib\gcc-lib\djgpp\3.01\specs
> in the md_exec_prefix: section
Right, that d:/djgpp/bin should not be there. I believe Andris suggested
how to solve this, so it will probably be fixed when GCC 3.0.1 is released.
> install: $DJDIR/lib/gcc-lib/djgpp/2.953/
> programs: c:/djgpp/lib/gcc-lib/djgpp/2.953/;c:/djgpp/lib/gcc-lib/djgpp/;c:/djgpp/lib/gcc-lib/djgpp/2.953/$DJDIR/djgpp/bin/djgpp/2.953/;c:/djgpp/lib/gcc-lib/djgpp/2.953/$DJDIR/djgpp/bin/;c:/djgpp/bin/djgpp/2.953/;c:/djgpp/bin/
> libraries: c:/djgpp/lib/djgpp/2.953/;c:/djgpp/lib/;c:/djgpp/lib/gcc-lib/djgpp/2.953/;c:/djgpp/lib/gcc-lib/djgpp/2.953/$DJDIR/djgpp/lib/djgpp/2.953/;c:/djgpp/lib/gcc-lib/djgpp/2.953/$DJDIR/djgpp/lib/;c:/djgpp/bin/djgpp/2.953/;c:/djgpp/bin/;c:/djgpp/lib/djgpp/2.953/;c:/djgpp/lib/
>
> install: c:/djgpp/lib/gcc-lib/djgpp/3.01/
> programs: =c:/djgpp/lib/gcc-lib/djgpp/3.01/;c:/djgpp/lib/gcc-lib/djgpp/3.01/;c:/djgpp/lib/gcc-lib/djgpp/;/usr/lib/gcc/djgpp/3.01/;/usr/lib/gcc/djgpp/;c:/djgpp/lib/gcc-lib/djgpp/3.01/../../../../djgpp/bin/djgpp/3.01/;c:/djgpp/lib/gcc-lib/djgpp/3.01/../../../../djgpp/bin/;d:/djgpp/bin/djgpp/3.01/;d:/djgpp/bin/
> libraries: =c:/djgpp/lib/djgpp/3.01/;c:/djgpp/lib/;c:/djgpp/lib/gcc-lib/djgpp/3.01/;/usr/lib/gcc/djgpp/3.01/;c:/djgpp/lib/gcc-lib/djgpp/3.01/../../../../djgpp/lib/djgpp/3.01/;c:/djgpp/lib/gcc-lib/djgpp/3.01/../../../../djgpp/lib/;d:/djgpp/bin/djgpp/3.01/;d:/djgpp/bin/;c:/djgpp/lib/djgpp/3.01/;c:/djgpp/lib/;c:/djgpp/lib/gcc-lib/djgpp/3.01/../../../djgpp/3.01/;c:/djgpp/lib/gcc-lib/djgpp/3.01/../../../;/lib/djgpp/3.01/;/lib/;/usr/lib/djgpp/3.01/;/usr/lib/
>
> The 2.953 version doesn't have any long paths, the 3.01 version does.
I still don't know how long is ``long''.
> I hope
> that doesn't cause anyone problems - the 3.01 library path line is 456 chars
> long.
These lists are never passed to the OS: GCC breaks them down and uses
each directory individually.
> This killed the dos-16 subsystem several times.
Any idea which call kills it? Is it the last one?
> > How long is ``very long''? DOS is supposed to be able to handle file
> > names up to 80 characters, with some functions limited to just 64.
>
> One of the names above is 78 characters.
Still on the right side of the limit, I think. But since it's not
consistently crashes on these names, I don't think we can draw any
conclusions.
> > Another known DOS limit is 8 levels of subdirectories: some system
> > calls fail if the file name is in a subdirectory more than 8 levels
> > deep. The above file name doesn't exceed this limit, unless they
> > count them before canonicalization (with function 60h of Int 21h),
> > which should remove all the "../" parts for the file name.
>
> With the ..'s included there are 16 in the first path. Maybe it
> doesn't like this.
If it canonicalizes the name before doing anything else (like DOS did),
it shouldn't see all those extra levels.
> > Can you find out what is the limit in this case that NTVDM doesn't
> > like?
>
> It does not seem to be reliable (sometimes fails, sometimes does not).
> The combination of the 3 stat calls at least killed it several times
> in the example program.
So this sounds like a bug, not some consistent behavior. It's hard to
know whether we blow some system limit if the behavior is inconsistent.
Perhaps your MS contact can help: they do have access to the sources.
> I can't test this anymore, since it now doesn't crash like it did yesterday.
So currently compilation works on the XP?
- Raw text -