Hi all

I succeeded in this native building with only one change to gpc sources due to a DOS peculiarity. The problem comes from the following lines contained (at two different locations) in p/Make-lang-2.95.in

CC="`echo $(GCC_FOR_TARGET) | sed -e 's,-B([^/]),-B../../\1,g' -e 's,^([^/][^ ]*),../../\1,'`" \ PC="`echo $(GPC_FOR_TARGET) | sed -e 's,-B([^/]),-B../../\1,g' -e 's,^([^/][^ ]*),../../\1,'`" \

It means that to go the to rts subdirectory it prepends ../.. to G?C_FOR_TARGET if this is a relative, not an absolute directory name. Absolute is recognized by the first character being a slash. However in DOS an absolute pathname starts with a drive letter c:/ In particular GCC_FOR_TARGET is in my case an absolute pathname built through `pwd` in the top makefile, which gives the drive letter. Solutions could be - saying that an absolute pathname has either / as first character or : as second. Can be garbled by a unix relative path starting with d: is this possible in this context? This gives the attached notroot.dif - saying that a relative pathname starts by ./ or ../ This is what occurs for GPC_FOR_TARGET. Can be garbled if the relative path starts with an ordinary character, is this possible in this context? This gives the attached relative.dif. You can incorporate one of these solutions (or a better you may imagine) into the gpc sources, or let the djgpp maintainers to make the patch only for djgpp (and probably other DOS systems). The last solution would mean however the need to modify the patch for each new gpc alpha or beta distribution, so that the first is highly preferred.

The building has been made in a W98 DOS box, LFN=Y, with binutils 2.8.1 and the beta version 2.0.3 of bash for djgpp. I can upload the resulting binary file if you are interested.

For those interested to internals of djgpp. The beta bash version enables (when setting PATH_EXPAND=N) pwd to output /dev/c/ instead of c: to have a more unix-like behavior, which seems to solve the above problem. Bash understands command lines starting with /dev/c/bin/something.exe but DOS (command.com) does not understand ! Now, as explained to me by Eli Zaretskii to solve an other hairy problem, the djgpp port of Make sends command lines to bash only if he thinks that the shell is involved, and to COMMAND.COM otherwise (to save overhead). He recognizes that the shell is needed if the make line includes something which belongs to the shell, which could be a simple ; at the end of the makefile line. I have tried to build with PATH_EXPAND=N, it stops building the rts at the first command line $(GCC_FOR_TARGET) so so When adding a ; at the end of that makefile line, make goes somewhat further, but stops at the next occurrence, which shows that this is indeed the problem. Now is the overhead in make large enough to warrant all these inconveniences?

Hope this helps.