Mail Archives: djgpp-workers/2001/08/26/07:24:53
> > 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''.
The 2.953 paths do not include any ../ stuff (pre-removed?) while the 3.01
ones do. I'm not sure what long is either, just 3.01 broke it where 2.953
didn't.
> These lists are never passed to the OS: GCC breaks them down and uses
> each directory individually.
Oh yes, looping in the debugger you get to see each one :-)
About 20 search failures before we can find a file.
> > This killed the dos-16 subsystem several times.
>
> Any idea which call kills it? Is it the last one?
Hard to say for sure. I know inside gdb xgcc always made the ntvdm go
away on the third one. The test program usually didn't print anything to
the screen, which would indicate the first 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.
I think we are randomly lucky that the name was 78 characters generated
by GCC build instead of 81 ...
> > 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.
Feeling lucky, eh? :-)
I think we would be better off finding why we get lots of ../ in 3.01 and
didn't get any in 2.953 ... just to be safe...
> > 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'll send it off when I get a chance.
> > I can't test this anymore, since it now doesn't crash like it did yesterday.
>
> So currently compilation works on the XP?
It always did with lfn=y, it now also does with lfn=n (just testing combos).
Yes, XP is looking like a reasonable DJGPP platform, with a few little
wiggles :-)
- Raw text -