Prof A Olowofoyeku (The African Chief) a écrit:

On 14 Feb 2003 at 12:01, Maurice Lombardi wrote:

...

Prof. A Olowofoyeku (The African Chief) a écrit:

...

You can obtain the binary of the Mingw version of GPC 20030209 (based on the "Mingw special" gcc-3.2.2 sources) from the Mingw web site:

If you want a link, here it is (it overlows the line, so you will need to join it all together manually):

http://prdownloads.sourceforge.net/mingw/gpc-20030209.i386-pc-mingw32- 1.tar.gz?download

PS: the sources are also there (inclusive of the gcc-3.2.2 patch that I used).

Tried it on W98. There is still this problem of /\ ...

What problem is this?

I have first downloaded your binaries, and installed them in my mingw tree (installed also gcc-3.2.2 from sourceforge). When trying to compile some pascal programs gpc answers that it cannot find as.exe, with a full path written with forward slashes. I then tried to compile gpc from your sources in W98, and it dies with similar message when xgpc wants to compile the first pascal program in the rts.

...

I have made something stupid. Compiled it with MSYS-1.0.8 (1.0.9 had a bug) and latest mingw tools from sourceforge, with your sources, except replacing in xm-mingw2.h #ifdef GPC by #ifdef TARGET_W9x (like in 2.95.x) and compiled with

../gcc-3.2.2-20030208-1/configure --verbose --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=pascal --disable-win32-registry --disable-shared --enable-sjlj-exceptions

make "CFLAGS=-O2" "BOOT_CFLAGS='-O2 -DTARGET_W9x'" "PFLAGS=-gstabs" "LDFLAGS=-s" bootstrap

This succeeded. I installed only gpc, not gcc The result is strange because gcc --print-search-dirs answers with forward slahes while

Correct (remember, you only installed gpc - so the original gcc binaries remain, and they would be using forward slashes).

...

gpc --print-search-dirs answers with backward slashes.

Correct.

...

But the test suite as well as some demo programs (notably crtdemo.pas which compiles also C code, compiled both within MSYS or in a bare DOS box) gives no error ... I do not understand ...

Were you expecting problems? If so, what problems were you expecting? There should be no error. The error would appear in GPC if you did not use "-DTARGET_W9x", because the GPC driver would have problems with the forward slash. The gcc driver will not have such problems, as a result of recent changes in it (which may or may not have been mirrored in the GPC driver - I didn't bother checking), which would compensate for either forward or back slashes.

Apparently they have not been mirrored. In fact I do not know what is made in the drivers, what in the real compilers, and what the latters are supposed to received from the formers.

Maurice

Prof A Olowofoyeku (The African Chief) wrote:

On 14 Feb 2003 at 15:29, Maurice Lombardi wrote:

[...]

...

...

What problem is this?

I have first downloaded your binaries, and installed them in my mingw tree (installed also gcc-3.2.2 from sourceforge). When trying to compile some pascal programs gpc answers that it cannot find as.exe, with a full path written with forward slashes. I then tried to compile gpc from your sources in W98, and it dies with similar message when xgpc wants to compile the first pascal program in the rts.

Yes, I have found the problem. It seems that "GPC" is never defined for xm-mingw32.h during compilation. So the condition "#ifdef GPC" is never satisfied. I wouldn't have thought that one needed to pass "-DGPC" at the command line - Frank, am I missing something?

`-DGPC' is used for the GPC specific changes, so the C compiler is not affected by them. Each patched source file is compiled twice -- for gcc without and for gpc with `-DGPC'. Therefore, `-DGPC' should not be given at the command line.

So what would have to be done here is to figure out all source files affected by this change (which include xm-mingw32.h directly or indirectly) and have them compiled again with `-DGPC' from the Makefile. Actually, I wonder which ones these are since gpc.c is compiled with `-DGPC', anyway, so it must be something else!?

...

...

...

I have made something stupid. Compiled it with MSYS-1.0.8 (1.0.9 had a bug) and latest mingw tools from sourceforge, with your sources, except replacing in xm-mingw2.h #ifdef GPC by #ifdef TARGET_W9x (like in 2.95.x)

This seems to be the solution (i.e., replacing #ifdef GPC by #ifdef TARGET_W9x).

That would be easier to do, but it breaks the principle that the GPC patches don't affect the C compiler. You can do so in your private patches, but I wouldn't like to include this in the "official" patches.

You synched with the FSF sources, I presume. The Mingw special sources contain their own patches, and that is where this is dealt with.

Well, then things are obvious, and kludging around with the machine file is not the right thing to do.

If the gcc.c patch is in the special mingw patches, then the gpc.c patch should also be there. (If the maintainers of the mingw patch won't accept it, you might have to make a mingw-gpc-special patch for now.) I don't want to "sync" gpc.c with inofficial gcc.c changes (which makes it harder to keep it up to date). Of course, the best solution would be to get the patch integrated in GCC. (I guess this might require some cleanups -- the #ifdef __MINGW32__ stuff doesn't seem so nice since platform specific stuff should generally go into the machine files. But that's for the GCC people to decide ...)

Frank

On 15 Feb 2003 at 2:56, Frank Heckenbach wrote:

Prof A Olowofoyeku (The African Chief) wrote:

...

Were you expecting problems? If so, what problems were you expecting? There should be no error. The error would appear in GPC if you did not use "-DTARGET_W9x", because the GPC driver would have problems with the forward slash. The gcc driver will not have such problems, as a result of recent changes in it (which may or may not have been mirrored in the GPC driver - I didn't bother checking), which would compensate for either forward or back slashes.

I synched gpc.c with gcc.c from gcc-3.2.1 (except for automake and other GPC specific things which should have no influence on these issues). So if it works with gcc-3.2.1, but not with GPC, I suggest further debugging before we patch the machine file.

You synched with the FSF sources, I presume. The Mingw special sources contain their own patches, and that is where this is dealt with. The attached diff applies those patches to the GPC driver. If used, then we don't have to patch the machine file. Either way, a specific Mingw patch has to be applied. The question is whether it is best incorporated into gpc.c once and for all, or patched into the machine file every time one builds a new version of GPC. I would probably favour the former (i.e., incorporate it into gpc.c now) and forget patching the machine file.

Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

*** gcc/p/gpc.c.orig Wed Jan 29 05:01:54 2003 --- gcc/p/gpc.c Sat Feb 15 07:52:42 2003 *************** add_prefix (pprefix, prefix, component, *** 2988,2993 **** --- 2988,3011 ---- (*prev) = pl; }

+ #if defined (__MINGW32__) + static char * + canon_filename (char *fname) + { + char* p = fname; + + while (*p) + { + if (*p == '/') + *p = '\'; + p++; + } + return fname; + } + #else + #define canon_filename(f) f + #endif + /* Execute the command specified by the arguments on the current line of spec. When using pipes, this includes several piped-together commands with `|' between them. *************** execute () *** 3026,3032 **** string = find_a_file (&exec_prefixes, commands[0].prog, X_OK, 0);

if (string) ! commands[0].argv[0] = string;

for (n_commands = 1, i = 0; i < argbuf_index; i++) if (strcmp (argbuf[i], "|") == 0) --- 3044,3050 ---- string = find_a_file (&exec_prefixes, commands[0].prog, X_OK, 0);

if (string) ! commands[0].argv[0] = canon_filename(string);

for (n_commands = 1, i = 0; i < argbuf_index; i++) if (strcmp (argbuf[i], "|") == 0) *************** execute () *** 3040,3046 **** string = find_a_file (&exec_prefixes, commands[n_commands].prog, X_OK, 0); if (string) ! commands[n_commands].argv[0] = string; n_commands++; }

--- 3058,3064 ---- string = find_a_file (&exec_prefixes, commands[n_commands].prog, X_OK, 0); if (string) ! commands[n_commands].argv[0] = canon_filename(string); n_commands++; }