On 20 Feb 2005 at 21:40, Waldek Hebisch wrote:
Prof A Olowofoyeku wrote:
Program received signal SIGSEGV, Segmentation fault. 0x77c47a64 in strncmp () (gdb) bt #0 0x77c47a64 in strncmp () #1 0x0040f24d in update_path (path=0x0, key=0x4191f7 "GCC") at ../../gcc/prefix.c:256 #2 0x0040284f in add_prefix (pprefix=0x415024, prefix=0x0, component=0x0, priority=1, require_machine_suffix=0, warn=0x0, os_multilib=0) at ../../gcc/p/gpc.c:3207 #3 0x0040898e in process_command (argc=2, argv=0x3d2588) at ../../gcc/p/gpc.c:3888
It seems that someting is wrong already in `process_command' (`prefix' in call to `add_prefix' definitely should be not 0). Could you try the following patch and post the results.
[....] gcc_exec_prefix is null standard_bindir_prefix=d:/mingw/bin/ standard_libexec_prefix=/usr/local/libexec/gcc/ argv[0]=d:\src\mingw\gcc-3.2.3\build\gcc\xgpc.exe gcc_exec_prefix=d:\src\mingw\gcc-3.2.3\build\gcc..\lib/gcc-lib/ gcc_libexec_prefix is null
Now I understand the problem. Normally with gcc-3.2.3 or gcc-3.3.x `gcc_libexec_prefix' is unused, and `standard_libexec_prefix' has default value. If you pass `--prefix=d:/mingw/' option to configure `standard_libexec_prefix' is bogus. `standard_libexec_prefix' is passed to `make_relative_prefix'. On Linux `make_relative_prefix' just gives bogus value of `gcc_libexec_prefix', but with Windows paths one gets null pointer (and crash). The following should fix the problem.
diff -u p.bb/gpc.c p/gpc.c --- p.bb/gpc.c Sat Feb 12 02:14:47 2005 +++ p/gpc.c Mon Feb 21 01:03:06 2005 @@ -3885,8 +3885,14 @@ }
set_std_prefix (gcc_exec_prefix, len); - add_prefix (&exec_prefixes, gcc_libexec_prefix, "GCC", - PREFIX_PRIORITY_LAST, 0, NULL, 0); +#ifdef GCC_3_4 + if (gcc_libexec_prefix) + add_prefix (&exec_prefixes, gcc_libexec_prefix, "GCC", + PREFIX_PRIORITY_LAST, 0, NULL, 0); + else +#endif + add_prefix (&exec_prefixes, gcc_exec_prefix, "GCC", + PREFIX_PRIORITY_LAST, 0, NULL, 0); add_prefix (&startfile_prefixes, gcc_exec_prefix, "GCC", PREFIX_PRIORITY_LAST, 0, NULL, 0); }