Configuring in p/rts fails when host!=build (for example when building native compiler for DJGPP or MINGW under Linux) as newly built xgcc and xgpc cannot be run on build system. In this case we should run corresponding cross-compiler instead.
Included patch is tested only for --build=i686-pc-linux-gnu, --host=i586-mingw32msvc --target=i586-mingw32msvc
Andris
--- gpc-20010924/p/Make-lang.in~1 Mon Sep 24 19:59:48 2001 +++ gpc-20010924/p/Make-lang.in Tue Oct 30 17:57:24 2001 @@ -154,8 +154,12 @@ ADD_RTS_PARENT_DIR = sed -e 's,-B([^/][^:]),-B../../\1,g;s,^([^/][^:]),../../\1,'
# The ' ' is there so, e.g., `-B.' will be replaced by ADD_RTS_PARENT_DIR -RTS_COMPILERS = CC="`echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" \ - PC="`echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" +RTS_COMPILERS = CC="`if test "$(build_canonical)" = "$(host_canonical)" ; then \ + echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR); \ + else echo $(GCC_FOR_TARGET); fi`" \ + PC="`if test "$(build_canonical)" = "$(host_canonical)" ; then \ + echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR);\ + else echo $(GPC_FOR_TARGET); fi`" GPC_GENERATED_SRC = \ $(srcdir)/p/parse.c \
Andris Pavenis wrote:
Configuring in p/rts fails when host!=build (for example when building native compiler for DJGPP or MINGW under Linux) as newly built xgcc and xgpc cannot be run on build system. In this case we should run corresponding cross-compiler instead.
Yes, I regularly do cross-compilations, including canadian cross. I set GCC_FOR_TARGET and GPC_FOR_TARGET on the command line, then it works for me. Since command line settings take precendence in make, this will override the default `GPC_FOR_TARGET = ./xgpc -B./'.
I'm not sure if that's how it's supposed to be done, but AFAICS, GCC_FOR_TARGET is not set automatically when configuring for a cross-build. Or did I miss this somehow (or is this different in gcc-2.95.x -- I'm using gcc-2.8.1)?
Included patch is tested only for --build=i686-pc-linux-gnu, --host=i586-mingw32msvc --target=i586-mingw32msvc
Andris
--- gpc-20010924/p/Make-lang.in~1 Mon Sep 24 19:59:48 2001 +++ gpc-20010924/p/Make-lang.in Tue Oct 30 17:57:24 2001 @@ -154,8 +154,12 @@ ADD_RTS_PARENT_DIR = sed -e 's,-B([^/][^:]),-B../../\1,g;s,^([^/][^:]),../../\1,'
# The ' ' is there so, e.g., `-B.' will be replaced by ADD_RTS_PARENT_DIR -RTS_COMPILERS = CC="`echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" \
PC="`echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`"+RTS_COMPILERS = CC="`if test "$(build_canonical)" = "$(host_canonical)" ; then \
echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR); \else echo $(GCC_FOR_TARGET); fi`" \PC="`if test \"$(build_canonical)\" = \"$(host_canonical)\" ; then \echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR);\else echo $(GPC_FOR_TARGET); fi`"GPC_GENERATED_SRC = \ $(srcdir)/p/parse.c \
I don't quite understand what this patch does. AFAICS, it skips $(ADD_RTS_PARENT_DIR) in a cross-build. But $(ADD_RTS_PARENT_DIR) only adds the necessary ../.. to relative paths (since the configure and make of the RTS change to p/rts), and leaves absolute paths unchanged (at least this is what it's supposed to do, unless there's a mistake in the regex).
So, how should this solve the problem if gpc is `./xgpc -B./'? It would not set GPC_FOR_TARGET to <prefix>/bin/i586-mingw32msvc-gpc, and it would omit the ../../, so it searches for xgpc in the p/rts build directory!?
Since it works for you, I must be missing something ...
Frank
On Wednesday 31 October 2001 05:40, Frank Heckenbach wrote:
Andris Pavenis wrote:
Configuring in p/rts fails when host!=build (for example when building native compiler for DJGPP or MINGW under Linux) as newly built xgcc and xgpc cannot be run on build system. In this case we should run corresponding cross-compiler instead.
Yes, I regularly do cross-compilations, including canadian cross. I set GCC_FOR_TARGET and GPC_FOR_TARGET on the command line, then it works for me. Since command line settings take precendence in make, this will override the default `GPC_FOR_TARGET = ./xgpc -B./'.
I'm not sure if that's how it's supposed to be done, but AFAICS, GCC_FOR_TARGET is not set automatically when configuring for a cross-build. Or did I miss this somehow (or is this different in gcc-2.95.x -- I'm using gcc-2.8.1)?
I used gcc-2.95.3-6 from Mingw website (I merged relative prefix related patches in p/gpc.c). GCC_FOR_TARGET and GPC_FOR_TARGET were set both in environment and command line of top level make. One thing was that I forgot to apply patch for top level Makefile to set GPC_FOR_TARGET and add it to flags to pass to submakes (I have that in my patches for DJGPP, but DJGPP and MINGW both uses patched gcc, so it's easy to forget something)
Included patch is tested only for --build=i686-pc-linux-gnu, --host=i586-mingw32msvc --target=i586-mingw32msvc
Andris
--- gpc-20010924/p/Make-lang.in~1 Mon Sep 24 19:59:48 2001 +++ gpc-20010924/p/Make-lang.in Tue Oct 30 17:57:24 2001 @@ -154,8 +154,12 @@ ADD_RTS_PARENT_DIR = sed -e 's,-B([^/][^:]),-B../../\1,g;s,^([^/][^:]),../../\1,'
# The ' ' is there so, e.g., `-B.' will be replaced by ADD_RTS_PARENT_DIR -RTS_COMPILERS = CC="`echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" \ - PC="`echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" +RTS_COMPILERS = CC="`if test "$(build_canonical)" = "$(host_canonical)" ; then \ + echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR); \
else echo $(GCC_FOR_TARGET); fi`" \PC="`if test \"$(build_canonical)\" ="$(host_canonical)" ; then \ + echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR);\
else echo $(GPC_FOR_TARGET); fi`"GPC_GENERATED_SRC = \ $(srcdir)/p/parse.c \
I don't quite understand what this patch does. AFAICS, it skips $(ADD_RTS_PARENT_DIR) in a cross-build. But $(ADD_RTS_PARENT_DIR) only adds the necessary ../.. to relative paths (since the configure and make of the RTS change to p/rts), and leaves absolute paths unchanged (at least this is what it's supposed to do, unless there's a mistake in the regex).
It skips $(ADD_RTS_PARENT_DIR) for Canadian-cross builds only. In this case we should not try to run newly built compilers as they are intended to be run on host but not the build system.
Anyway perhaps more detailed tests are needed.
So, how should this solve the problem if gpc is `./xgpc -B./'? It would not set GPC_FOR_TARGET to <prefix>/bin/i586-mingw32msvc-gpc, and it would omit the ../../, so it searches for xgpc in the p/rts build directory!?
Since it works for you, I must be missing something ...
I tried to build GPC for MINGW. It seems to work after some hacking. But there seems to be more problems. Do You know somebody messing with building GPC for MINGW earlier? Mailing list archives search didn't work for me, so I'm asking that.
Andris
Andris Pavenis wrote:
Included patch is tested only for --build=i686-pc-linux-gnu, --host=i586-mingw32msvc --target=i586-mingw32msvc
Andris
--- gpc-20010924/p/Make-lang.in~1 Mon Sep 24 19:59:48 2001 +++ gpc-20010924/p/Make-lang.in Tue Oct 30 17:57:24 2001 @@ -154,8 +154,12 @@ ADD_RTS_PARENT_DIR = sed -e 's,-B([^/][^:]),-B../../\1,g;s,^([^/][^:]),../../\1,'
# The ' ' is there so, e.g., `-B.' will be replaced by ADD_RTS_PARENT_DIR -RTS_COMPILERS = CC="`echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" \ - PC="`echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" +RTS_COMPILERS = CC="`if test "$(build_canonical)" = "$(host_canonical)" ; then \ + echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR); \
else echo $(GCC_FOR_TARGET); fi`" \PC="`if test \"$(build_canonical)\" ="$(host_canonical)" ; then \ + echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR);\
else echo $(GPC_FOR_TARGET); fi`"GPC_GENERATED_SRC = \ $(srcdir)/p/parse.c \
I don't quite understand what this patch does. AFAICS, it skips $(ADD_RTS_PARENT_DIR) in a cross-build. But $(ADD_RTS_PARENT_DIR) only adds the necessary ../.. to relative paths (since the configure and make of the RTS change to p/rts), and leaves absolute paths unchanged (at least this is what it's supposed to do, unless there's a mistake in the regex).
It skips $(ADD_RTS_PARENT_DIR) for Canadian-cross builds only. In this case we should not try to run newly built compilers as they are intended to be run on host but not the build system.
As I said, $(ADD_RTS_PARENT_DIR) only adds the necessary ../.. for relative paths, so they still work after the chdir. It doesn't affect whether or not the newly bulit compiler is used (i.e., if it's ./xgpc -B./ before $(ADD_RTS_PARENT_DIR), it's ../.././xgpc -B../.././ after, but if it's /usr/bin/foo-gpc before, it will remain so). So I still don't understand what this patch helps there.
So, how should this solve the problem if gpc is `./xgpc -B./'? It would not set GPC_FOR_TARGET to <prefix>/bin/i586-mingw32msvc-gpc, and it would omit the ../../, so it searches for xgpc in the p/rts build directory!?
Since it works for you, I must be missing something ...
I tried to build GPC for MINGW. It seems to work after some hacking. But there seems to be more problems. Do You know somebody messing with building GPC for MINGW earlier? Mailing list archives search didn't work for me, so I'm asking that.
The Chief did (and does) that, and David Bryan is also trying it.
Frank
On 31 Oct 2001, at 4:40, Frank Heckenbach wrote:
I set GCC_FOR_TARGET and GPC_FOR_TARGET on the command line, then it works for me. Since command line settings take precendence in make, this will override the default `GPC_FOR_TARGET = ./xgpc -B./'.
I'm not sure if that's how it's supposed to be done, but AFAICS, GCC_FOR_TARGET is not set automatically when configuring for a cross-build.
Using GCC 2.95.3, the makefiles appear to be generated in this way:
Host = Build ============
./makefile: GCC_FOR_TARGET = $$r/gcc/xgcc ... ./makefile: GPC_FOR_TARGET = (not defined)
./gcc/makefile: GCC_FOR_TARGET = ./xgcc ... ./gcc/makefile: GPC_FOR_TARGET = ./xgpc ...
Host <> Build =============
./makefile: GCC_FOR_TARGET = ix86-pc-mingw32msvc-gcc ... ./makefile: GPC_FOR_TARGET = (not defined)
./gcc/makefile: GCC_FOR_TARGET = ./xgcc ... ./gcc/makefile: GPC_FOR_TARGET = ./xgpc ...
The result in the Host <> Build case is that the cross-gcc compiler is used to compile C programs in the RTS, but the (hosted) gpc compiler just built is used to compile the Pascal programs. This fails because the gpc just built doesn't run on the build system.
It would appear that in the Host <> Build case, the definition override:
GPC_FOR_TARGET = ix86-pc-mingw32msvc-gpc
...should appear in the top-level makefile.
-- Dave
J. David Bryan wrote:
On 1 Nov 2001, at 7:54, Frank Heckenbach wrote:
The Chief did (and does) that, and David Bryan is also trying it.
||||||||||||||||| "did (and does) it." :-)
OK, I wasn't sure if you'd succeeded yet.
Frank
J. David Bryan wrote:
On 31 Oct 2001, at 4:40, Frank Heckenbach wrote:
I set GCC_FOR_TARGET and GPC_FOR_TARGET on the command line, then it works for me. Since command line settings take precendence in make, this will override the default `GPC_FOR_TARGET = ./xgpc -B./'.
I'm not sure if that's how it's supposed to be done, but AFAICS, GCC_FOR_TARGET is not set automatically when configuring for a cross-build.
Using GCC 2.95.3, the makefiles appear to be generated in this way:
Host = Build
./makefile: GCC_FOR_TARGET = $$r/gcc/xgcc ... ./makefile: GPC_FOR_TARGET = (not defined)
./gcc/makefile: GCC_FOR_TARGET = ./xgcc ... ./gcc/makefile: GPC_FOR_TARGET = ./xgpc ...
Host <> Build
./makefile: GCC_FOR_TARGET = ix86-pc-mingw32msvc-gcc ... ./makefile: GPC_FOR_TARGET = (not defined)
./gcc/makefile: GCC_FOR_TARGET = ./xgcc ... ./gcc/makefile: GPC_FOR_TARGET = ./xgpc ...
The result in the Host <> Build case is that the cross-gcc compiler is used to compile C programs in the RTS, but the (hosted) gpc compiler just built is used to compile the Pascal programs. This fails because the gpc just built doesn't run on the build system.
It would appear that in the Host <> Build case, the definition override:
GPC_FOR_TARGET = ix86-pc-mingw32msvc-gpc
...should appear in the top-level makefile.
AFAICS there are at least 3 ways to solve it:
- Set GPC_FOR_TARGET on the command line. That's what I'm doing, and it works. But it's not optimal since it could be done automatically.
- Convince the GCC people to set GPC_FOR_TARGET in the top level makefile. Someone who is in contact with them (e.g., Peter, not me) could try this.
- Forget about GPC_FOR_TARGET, and use GCC_FOR_TARGET with s/gcc/gpc/ (e.g., ./xgcc -> ./xgpc, /usr/bin/foo-bar-baz-gcc -bqux -> /usr/bin/foo-bar-baz-gpc -bqux). Does anyone see a situation where this would fail? (Though the second one is probably the cleaner solution.)
Frank
On Friday 02 November 2001 03:10, Frank Heckenbach wrote:
It would appear that in the Host <> Build case, the definition override:
GPC_FOR_TARGET = ix86-pc-mingw32msvc-gpc
...should appear in the top-level makefile.
AFAICS there are at least 3 ways to solve it:
- Set GPC_FOR_TARGET on the command line. That's what I'm doing, and it works. But it's not optimal since it could be done automatically.
It did not work for me unless I added GPC_FOR_TARGET to the flags to pass to submakes (my experience with building gcc-2.95.X together with GPC for DJGPP) as far as I remember
Convince the GCC people to set GPC_FOR_TARGET in the top level makefile. Someone who is in contact with them (e.g., Peter, not me) could try this.
Forget about GPC_FOR_TARGET, and use GCC_FOR_TARGET with s/gcc/gpc/ (e.g., ./xgcc -> ./xgpc, /usr/bin/foo-bar-baz-gcc -bqux -> /usr/bin/foo-bar-baz-gpc -bqux). Does anyone see a situation where this would fail? (Though the second one is probably the cleaner solution.)
If it's possible, then I would prefer this way (at least for now while GPC is still a separate package) as it would not require to do anything with top level Makefile. Perhaps it is necessary to test this way to see whether it's not breaking anything.
Andris
Andris Pavenis wrote:
- Forget about GPC_FOR_TARGET, and use GCC_FOR_TARGET with s/gcc/gpc/ (e.g., ./xgcc -> ./xgpc, /usr/bin/foo-bar-baz-gcc -bqux -> /usr/bin/foo-bar-baz-gpc -bqux). Does anyone see a situation where this would fail? (Though the second one is probably the cleaner solution.)
If it's possible, then I would prefer this way (at least for now while GPC is still a separate package) as it would not require to do anything with top level Makefile. Perhaps it is necessary to test this way to see whether it's not breaking anything.
OK, I'm doing this now. After the next release, you might want to test if it works for you.
Frank
Andris Pavenis wrote:
On Friday 02 November 2001 03:10, Frank Heckenbach wrote:
It would appear that in the Host <> Build case, the definition override:
GPC_FOR_TARGET = ix86-pc-mingw32msvc-gpc
...should appear in the top-level makefile.
AFAICS there are at least 3 ways to solve it:
- Set GPC_FOR_TARGET on the command line. That's what I'm doing, and it works. But it's not optimal since it could be done automatically.
It did not work for me unless I added GPC_FOR_TARGET to the flags to pass to submakes (my experience with building gcc-2.95.X together with GPC for DJGPP) as far as I remember
Convince the GCC people to set GPC_FOR_TARGET in the top level makefile. Someone who is in contact with them (e.g., Peter, not me) could try this.
Forget about GPC_FOR_TARGET, and use GCC_FOR_TARGET with s/gcc/gpc/ (e.g., ./xgcc -> ./xgpc, /usr/bin/foo-bar-baz-gcc -bqux -> /usr/bin/foo-bar-baz-gpc -bqux). Does anyone see a situation where this would fail? (Though the second one is probably the cleaner solution.)
If it's possible, then I would prefer this way (at least for now while GPC is still a separate package) as it would not require to do anything with top level Makefile. Perhaps it is necessary to test this way to see whether it's not breaking anything.
I've tried this on a couple of systems now, and didn't find a reliable way to do it.
The problem is that the prefix directory may contain `gpc' and or `gcc' (e.g., some people might build the whole stuff in a `gpc' directory, and with gcc-2.95.x it's always in a `gcc' subdirectory). These must not be changed, of course -- neither in the (possible) path to xgcc, not in the (possible) `-B' option.
Replacing only the executable name seems quite hard to do, assuming only a "stupid" (i.e., non-GNU ;-) sed. (I've had bad experiences with other seds, e.g. the Solaris one doesn't even support full regular expressions.)
So, if you have any good suggestion how to do it, let me know. Until then, I'll undo the change, and GPC_FOR_TARGET will have to be set otherwise.
Frank
-
Andris Pavenis -
Frank Heckenbach -
J. David Bryan