Mail Archives: djgpp/2013/11/25/10:27:35
On 11/25/2013 01:56 AM, Juan Manuel Guerrero wrote:
> I have tried to compile djgpp repository code using FreeDOS 1.1 with
> DOSLFN 0.41c. FreeDOS is installed on a virtual machine with 64MB.
> csdpmi7 is used. All djgpp packages used are from the /beta directory.
> This means they have been compiled using djdev204.
>
> I have used the identical djgpp installation on a second virtual machine
> but this time with MSDOS 6.22 (64MB and csdpmi7) and DOSLFN 0.41c, the
> repository code can be compiled flawlessly.
>
> Some of the used djgpp ports are gcc473, gpp473, bnu2232, mak40 and whatever
> else is required. I have added the -save-temps to the compiler options.
> As soon as I remove this option the build is performed flawlessly.
> I have also tried DOSLFN 0.40 with FreeDOS. If I enable -save-temps, the
> build fails in the same way than it does with DOSLFN 0.41c.
>
> The buil fails with the following error message:
>
> [snip]
> C:/DJGPP-2.04/BIN/make.exe -C ansi/locale
> gcc ... -c lconv.c
> gcc ... -c mbcurmax.c
> gcc ... -c mblen.c
> gcc ... -c mbstowcs.c
> gcc ... -c mbtowc.c
> gcc ... -c setlocal.c
> cc1.exe: error: setlocal.i is shorter than expected [-Werror]
> cc1.exe: all warnings being treated as errors
> ../../../makefile.inc:89: recipe for target 'setlocal.o' failed
> make.exe[3]: *** [setlocal.o] Error 1
> makefile.sub:2: recipe for target 'all_subs' failed
> make.exe[2]: *** [all_subs] Error 2
> ../makefile.lib:6: recipe for target 'all' failed
> make.exe[1]: *** [all] Error 2
> makefile:38: recipe for target 'subs' failed
> make.exe: *** [subs] Error 2
>
> After the build stops I can restart the build until it stops with the same
> error again and so on until I am through.
> Am I missing something? If more info is needed, please let me know.
Never saw anything like that. But I have not tried FreeDOS 1.1 with DOSLFN.
The problem is that static procedure read_file_guts() see libcpp/files.c
finds that the length of file determined using stat() is different from actual number
of bytes read from file in binary mode (see open_file() in the same source file). I have had
to modify files.c to discard final ^z if present, but this discarding is only
done after size check, so it does not matter.
The difference between 2 cases is that with -save-temps there is one more
process spawned:
- cc1.exe (or cc1plus.exe) is invoked at first with command line option -E
to generate pre-processed file
- after that the same executable is invoked once more to actually compile
the pre-processed file (the file seems to still be read using libcpp even if
no preprocesing is done. That is reasonable as there is no reason to
re-implement reading file as it is already be present in libcpp)
Without -save-temps all is done in the same invokation of cc1.exe or cc1plus.exe
and no temporary files are written
I do not know what is causing these problems. Perhaps some debugging is needed.
One may also try to extract determination of file size and actual reading into
a smaller test example for investigating the problem
Andris
- Raw text -